Software CM

[mrbean]

I am at the very early stages of a new development program.  In short, we plan to use TestStand to control/sequence tests written in both CVI and LabVIEW.  At the moment, all of these software packages are loaded on my C-drive.  However, looking ahead, I see a problem when I finally have a product, and our configuration management group wants to archive/reproduce the software.  Given that I haven't started development yet, I need some expert advice.

Our CM group MUST have the capability to capture file versions, etc of everything I (the developer) say went into making the application.  They must also be able to recreate the application by recompiling the software, create executables, create install kits, etc. - thus reproducing what I created.  I need guidance on how to handle this situation.  I know there are more issues than this, but these are some of my questions:

Q.  Do the NI software products have to be installed on a localized server?

Q.  We currently have one license for TestStand, CVI, LabVIEW, DIAdem.  How can I install these on this localize server with the understanding that I will be the only developer using these products - except when CM has to help create a release of software.

Q.  What if we add a second/third developer - do I simply purchase another set of software?

Q.  I need to be able to work from my desk (for general development) or the lab PC (connected to the actual target).  Is this accomplished by having the software live on this server. 

Q.  Does this affect debugging in any way?

I know I'll have more questions

[Dennis_Knutson]

I must say that you're more trusting of your CMs than I am if you give them the ability to recompile software.

I don't know how much of what I do can be applied to you since every CM is different. We have a formal configuration management system. This system manages all product documentation. These are things like bill of materials, fab drawings, etc. Our CMs have access to this for those products that they build. Change orders (ECO's) are also controlled through this system. When an ECO is done on a product, the CM is also notified and immediately knows what needs to be changed. We have also included test software and test change orders into the system. When I modify a TestStand sequence, the updated sequence is placed into the configuration management system, I issue a test change order, then CM then knows that they have to connect to the system and download the new sequence. So far I haven't needed anmore complex installation instruction that says "copy this file to c:\TestSequence\FolderName\FileName.seq, reload sequence in TestStand". My test sequences almost always consist of calls to custom test steps (LabVIEW and CVI DLLs) and I seldom have to change these. It is only the .seq file itself that changes. However, the test steps themselves are part of the configuration management system and changes to those are also controlled with a test change order. Our configuration management system is expensive and requires a lot of support but I would recomend that you look to see how your company manages ECOs now and try to model something similar.

All that I have installed on the testers at the CM are the necessary run-time engines so my licensing needs are much simpler. Someone from NI is can answer your questions on that subject better than I can.

To handle problems that might show up at the CM, VNC (or pcAnywhere, XP's remote login) can be used to connect remotely. I can usually solve most problems just from the TestStand operator interface but major problems might require the temporary installation of a TestStand debug (not full development) license.

[daijoubu]

Dennis:

I think you're mixing up the software development CM (Configuration Management) and the manufacturing CM (Contract Manufacturer).  It sounds to me like mrbean has a CM (Configuration Management) group that needs to be able to recreate his software using what's in the source code control system.  Because of this, the CM (Configuration Management) group needs to be able to run LabVIEW, TestStand, CVI, etc.  He also wants the ability to run these programs from different computers off of a network drive.

This seems to commonly come up when a company implements CMM.

mrbean:

I don't think you will be able to run the NI toolchain off of a network drive.  The TestStand environment is an ActiveX server that require registry settings.  These settings will be in the HKLM branch.  I don't believe this branch is part of a users profile.  I'm sure LabVIEW has similar issues.

[Dennis_Knutson]

Going back and re-reading the original post, I think you're right. To me, that's even scarier. My present configuration management team and others I worked with in the past are non-technical and could not (and would not) recreate any software. They simply file software and documentation that has been re-created by others.

Anyways, mrbean, ignore everything what I originally said.

[mrbean]

daijoubu is more correct in his accessment of our needs.  Given the situation, does anyone have suggestions as to how to implement (let's say) ClearCase as our CM tool to work with 2-3 developers that may share source code?

[daijoubu]

Dennis:

Software CM groups tend to be more software savvy.  They're usually developers or ex-developers that have focussed on the configuration management area.  They may have forgotten a lot of the details or might not be up to speed on the latest libraries but are quite capable of running make or pressing build executable.  In an ideal world, what mrbean is asking for would be handled by a completely automated build process.  One example is CruiseControl.  The system monitors the source code repository for changes.  When a change is detected, it deletes it's local working directory and checks out the latest version.  It then attempts to build a target, runs any test suites, builds a distribution, reports the results to the team, and archives the artifacts (.exes, .msis, etc...) 

[mrbean]

By the way, what does "settings will be in the HKLM branch" mean

[daijoubu]

I'm sorry.  I should have explained it.  HKLM is short for HKEY_LOCAL_MACHINE.  This is the branch of the registry that is intended to hold machine specific settings.  These settings will be common to all users.  HKEY_USERS is intended for user specific settings.  An IT department can set things up so that your HKEY_USERS branch will follow you from machine to machine as part of a roaming profile.  HKEY_LOCAL_MACHINE should not be moved to different machines.

The different branches are visible in regedit.