|
|
|
Configuration Management |
|
|
|
Written by Bill Galbraith
|
|
Wednesday, 20 July 2005 |
This is another in an occassional series on topics that Antonio requested that I open up, to share some experience, and to get some viewpoints going. Get yourself a fresh cup of Joe, as this is a long one.
Let's start off with the opinions expressed here are my own. If you don't agree, well, you're allowed. If you have some insight into this that you feel would be helpful, please do. That's the purpose of these discussion boards.
Some people view Configuration Control during software development, and afterward, an evil thing. and many just accept it as a necessary evil. Well, it can be either of those, or it can be a helpful product.
Let's cover three examples: One PHB (Pointy-Haired Boss) thought that making a ZIP file once a week or so was good enough. If a latent problem was uncovered, the responsable engineer had to go back through the ZIP files looking for a change that might have caused the problem. File comparison tools had to be used, and hopefully the engineer could decipher what the changes were. I had experience with configuration control systems, and I wanted to set up something that would cover a little finer granularity, more often than once a week. We argued for 45 minutes, not on the subject, but on whether I could even present my ideas to him, other management, and other concerned individuals. It was shot down because he was not open to the idea that something could actually HELP in configuration management.
One job that I worked on had three layers of configuration management. The engineers worked in the engineering load. To change a file, you checked it out, made your change, compiled and tested. If one engineer checked out a file, no one else could change that file until it was checked back in. When a change was complete, you submitted it into the CM system in the engineering load. This then had to be promoted to the TEST load, but only after the proper paperwork was done and a board (or was that 'bored') was held to review the change. Once approved, it was moved into the TEST load, where someone of questionable knowledge checked the load to see if it started and would kinda fly like it used to. If that worked okay, it got moved into the TEST CM system, and promoted into the CM load and it's CM system. There was an entire staff just to handle the paperwork and load updates. On a trainer where building the load took 4 hours, this wasn't a very user-friendly system. Keeping track of where a change was in the process was difficult, and getting your changes in with someone else's changes that had to go in with yours was sometimes difficult. That was further complicated by some people doing documentation changes in your files at the same time, sometimes in a file that you had checked out. That was a three year job that ran 3.5 years LATE, but not solely cuased by the massive CM system.
The third system (Goldilocks' "Just Right") allows the engineers to work with the entire load at their disposal during early development stages, and is increasingly restricted as the program progresses. During the early stages when the load is just taking form, everything is located in the same directory, and whenever a stable load of some significance is reached, all the files are checked into CM, which is basically just saving off a copy of what worked at a particular point in time.
Now, let's talk about a specific tool, and once nice feauture of this tool. Revision Control System, or RCS, is readily available under a lot of operating systems, espcially Unix-based systems (including Linux), and there are ports to DOS, Windoze, and other operating systems. RCS retains the original file, and all the changes made to it. When a user submits a changed file, they give a brief description as to why the file was changed. This information is stored in the RCS system. The reason it was changed can be automatically added into the header of the file, along with the date and engineer who changed it, so that when you are looking at a file, you can tell when and why it was changed, and who changed it. In the future, if there was a latent problem, you can look at the changes to a file and the comments as to why it was changed, which is helpful in discovering the source of the problem (although not guaranteed to solve it).
One very nice feature of RCS that is not always used in the simulation world is the concept of a RELEASE. Building a release is merely marking all the files that make up a load at a given time with a timestamp and description of the load. For instance, during the early development cycle, when you have a stable load that executes but without any aircraft models working, you'd submit everything into RCS and build a release that just says "The load executes, but no simulation models". RCS goes through all the files in it's system, and records the file version numbers of that release. Then, at any point in the future, you can go back to this release and pull out the version of every file that made up that load into a separate directory and build that load to see if the latent problem existed in that load, or to do whatever you'd like as far as testing to uncover the source of the problem. This release still exists in RCS, you've just made a copy to use. When you are done, you can just delete that directory, and RCS is not affected at all. The other releases that you could build are only limited by your imagination, such as "Start of HSI", "Start of In-Plant testing with customer", "Final delivery", "EFIS upgrade", or whatever. Should there be a problem with the EFIS UPGRADE load that makes it unstable, and you just want to go back to the original FINAL DELIVERY load, it's stored in RCS and takes by a couple minutes to recove it, plus whatever time it takes to rebuild the load.
There's a good detour to take right now, just for a moment. What should be under Configuration Control? How about everything required to build a load from scratch. Period. No ifs, ands, or butts. You don't need to save the oject files or the final executable, because you need to be able to rebuild these at any given point. Having these files really doesn't do anything for you as far as telling you what is in them. Keeping the source is all that is required. If a vendor delivers only a library or executable program, you'll just have to live with it in that format, but put it under configuration control of some kind. RCS can handle files such as this, but hopefully your vendor isn't supplying changes to these files several times a week. If they are, put them in RCS, with a complete descriptionson what they claim they are changing. If it is a rare thing to get an update, then maybe you can just keep back-up copies under another name.
Okay, back on the main road: Now, after the initial load is working (but without any software models included), this is porbably a good time to switch to the next level of control. All files are contained in a CM load, which is under RCS control. User's have their own directories that they work in, and the Makefile is structured to look in the local directory first, and then the CM directory, for the files necesary to build the load. This way, Joe has a load that he knows works when he leaves the trainer at the end of his shift, when Mary comes on. When Joe goes back to the trainer on his next shift, he doesn't have to worry about what Mary did in her load, since it doesn't affect his load. He can continue working in his load, even if Mary's load is complete hosed and doesn;t even compile. When Joe has some changes that he needs to incorporate into the real load, he moves these into the engineering load, which is a common area for everyone to work in. You do your integration with other poeple in this load, resolving those interface issues that always crop up. When everyone involved is happy, the affected files are checked into the CM RCS system and a release is built. All engineers are made aware that the change is going to happen before it does, and told afterwards that it has happened. Then, the next time that they rebuild their load, they will have the updated software in their load. Yeah, once in a while that new CM load causes problems in your load, but guess what, you had to resolve those anyway, so better for you to do that locally than to do it in a common area where everyone is hosed until you've finished your changes.
Now, occassionally, there is an engineer or two that require a stable load for a long period of time, maybe weeks, because they are working on a very complex system and they don't want to have to worry about updating their local software every time that CM changes. The CM manager can pull out a release for them and let them build against that software until such time as they are ready to integrate with the most current load. I've seen that situation, and it worked out okay.
Now, occassionally, there is an engineer or two that require a stable load for a long period of time, maybe weeks, because they are working on a very complex system and they don't want to have to worry about updating their local software every time that CM changes. The CM manager can pull out a release for them and let them build against that software until such time as they are ready to integrate with the most current load. I've seen that situation, and it worked out okay.
Now, as the program has progressed, it might be time for tighter control of the software. If Joe were working on version 1.4 of a file, and so was Mary, and Joe checks his changes into CM, and Mary doesn't realize that or just ignoreds it, when she checks her file in, it would overwrite Joe's change, and he gets upset and starts questioning Mary family background. To keep conflicts down between the engineers changing software, you can tighten the screws on RCS one more level. Make the engineers check out the software before they change anything. This ensures that only one engineer is making a change at any given time. The engineer checks out a file into their own directory, changes and compiles as desires, and when finished, still moves the file into the engineering load to integrate the software with other software changes. There are usually few integration problems at this point.
Now, as the program progresses and you are getting down to the short strokes, not really doing design and development but just fixing minor problems, you tighten the screws on RCS down one more notch and make everyone work in the engineering directory, not their own directory. This cuts down on the processing time in order to make a change, since you no longer have to integrate it into the engineering load. Of course, there might be someone that is really lagging behind and really is doing development work. Fine, let them work in their own directory, and make everyone else work in the engineering directory.
Now, if you have noticed (and are still awake), we haven't talked about the RCS system forcing you to do things in a particular way. Software people can be a pain in the butt sometimes (I know, I'm one...okay, both). If you make the configuration control system a pain in the ass to use, they hate using it and will find ways around the controls that you have built in. You are trusting them to build your multi-million dollar simulator, maybe you can trust them to follow a very few rules. For those wild cannons, they are going to cause problems no matter what, so why make the RCS system restrictive for eveyone else also. The system outlines above gives you adequate control of the software without reining in those wild animals that you want to work hard and get things done.
Okay, I'm tired of typing. I hope that this has shed some light, and sparked some interest in the wonderful of CM (yeah, right!) (0) No Comments. Start a discussion... |
|
Last Updated ( Thursday, 23 February 2006 )
|
|
|
