EEVblog Electronics Community Forum
General => General Technical Chat => Topic started by: munkeyman1985 on November 07, 2019, 02:36:55 pm
-
I ran into an interesting problem at work. A test written using NI TestStand need to be moved to a new folder structure because of a revision change. My coworkers confidently jumped on and changed each string one line at a time. There is a better way, and when I found out what was happening I talked them through it.
I now realize I have some simple steps I use to save a lot of time. How can I share that with the rest of the teem. They often just dump things in a folder and every idiot that can access will change it. Would like some way of sharing it while maintaining the integrity of the information. Any suggestions?
-
I ran into an interesting problem at work. A test written using NI TestStand need to be moved to a new folder structure because of a revision change. My coworkers confidently jumped on and changed each string one line at a time. There is a better way, and when I found out what was happening I talked them through it.
I now realize I have some simple steps I use to save a lot of time. How can I share that with the rest of the teem. They often just dump things in a folder and every idiot that can access will change it. Would like some way of sharing it while maintaining the integrity of the information. Any suggestions?
Use source control--e.g. github.com
If you have just a modicum of discipline great benefits shall accrue. Namely, the blame button. ;D
-
In Teststand, you should use relative paths, not absolute.
-
Yes, use version control. For everything. And when your tools don't play well with version control complain to your vendors that their tools are defective. A common cause of this is files with important user editable configuration mixed in the same file as ephemeral or unimportant information (such as recently opened files, window positions, or even just datestamps). Automated deployment tools should then fetch the appropriate code from version control so that you know what version is running in production.
Peer review is annoying but super valuable: people are less likely to commit garbage in the first place if they know someone will look at it, and peer review can catch style issues like using relative vs. absolute paths.
Relative paths or variable expansion can help of course but don't necessarily save you when you re-organize your project.
-
every idiot that can access will change it
It depends.
First, pardon the condesending tone.
Are you just another team member or the team lead/manager/supervisor etc ?
If the former, you do nothing.
If the latter, you must propagate the idiots out of your team.
Anything else is a bandaid that may or may not eventually come back and bite you on the ass.
-
I was in some part hired to make things a little better for the team. It is a good team. If I can make a document of procedures that will save them time I would like to. If I do something to help the majority of the team save hours of work with some procedures, that would be good. You might be right, there is nothing I can do, but this might also be a chance for to learn something new.
-
That is a good idea! I can't use Git hub on this project at all. I will use you idea in the future. Thank you RandallMcRee
-
In Teststand, you should use relative paths, not absolute.
Right!!
-
I would recommend a Git repository for all your projects.
https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow (https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow)
If you are looking for a more secure git server, you can make one yourself using a program like Gitea.
https://gitea.io/en-us/ (https://gitea.io/en-us/)
-
confluence or mediawiki?