Improving Software Configuration Management? 33
Elvis77 writes "I am managing a project looking at some software to help us with
software change management. There are numerous good applications around for doing this and our purchasing is complete, but I have been amazed during my investigations at how many organizations rely on good manners, good intentions and good luck to manage the configuration management of their organization's software assets, even in light of the Sarbanes-Oxley Act of 2002 (SOX) that affects US companies (I am in Australia). Organizations outside of the USA, without SOX implications, are usually still concerned about the quality of their software. What do my fellow Slashdot readers consider to be the best practices for configuration management?"
Best practices -- (Score:2)
There are way too many to list -- I've been in a number of organizations -- some had a whole 'workflow' process, where all of the managers were informed of any changes to be made a weekly meeting (and because they didn't understand the implications of all of the changes, and didn't let the tech folks under them know, it was basically useless), to ones where it's completely informal.
I'd say the practices depen
Re:Best practices -- (Score:2)
Useless insofar as not getting chewed out is concerned, but it can help you keep your job, or even keep you out of jail. Never doubt the power of good record-keeping to help point the fickle-finger-of-blame in the proper direction. On the other hand, if you're in a job where you are being un
First, try to buy software that logs this for you. (Score:2)
Tripwire+CFEngine (Score:3, Informative)
Start small (Score:4, Interesting)
This first step will lead you to the next - increased communication in the team and good documentation. For documentation I've been please with the ReadySet [tigris.org] project at Tigris.org. Start with the basics and work up from there. Bringing a whole team along for the ride is time consuming, challenging and in the end - absolutely necessary (make it part of their objectives if you can).
Continue from there
Two paths (Score:3, Insightful)
1) Software *development* change mangement. Meaning: tracking things like changes to software code.
2) Software *configuration* change management. Meaning: tracking changes to the configuration of the software. I presume you're talking about this one, but it's not completely clear.
Development change management is well served by tools of varying complexity from ClearCase to Subversion/CVS. Subversion/CVS seem to be very common, as they're free, but I've worked in offices using ClearCase before (not that anyone was terribly happy about it, though).
Configuration change management is much harder, as you're talking about managing the configuration of applications across potentially hundreds of machines. The tools for this vary widely, depending on how hard-core you want to be. They vary from CFengine to full-on provisioning systems (openQMS, for example)...none of them tend to be easy to set up or manage, which makes them less common.
Re:Two paths (Score:1)
I would say that setting up some sort
Use RCS for config files (Score:3, Informative)
ci -u configfile
when you want to edit:
co -l configfile
check it back in:
ci -u configfile
Easy enough.
Re:Use RCS for config files (Score:3, Insightful)
RCS is great for single-server applications or one-off config files, but it doesn't scale really well to large applications.
Re:Use RCS for config files (Score:2)
So use subversion. It's dead easy to set up, there's plenty of tool support. You can
Re:Use RCS for config files (Score:1)
I note, with satisfaction, that you fail to mention any specific benefits of using Subversion, over CVS.
[reordered] There might actually be changes in two files that are related that neither cvs nor rcs is capable of keeping track off.
And SVN would do that better CVS, in some magical way? I cannot see how. If you have to rack out of a change, you either have a tag or a known good date. In either case, you'd 'cvs diff' against it, review the changes, then revert all of them or cherry-p
Re:Use RCS for config files (Score:2)
NetDirector (Score:2)
NetDirector does *NIX service configuration management across multiple servers on multiple Linux distros, Solaris, and BSD. And for SOX, it does change tracking and audit trailing, offers role-based management, change scheduling and rollback - all from a nifty Web-based GUI!
I've seen it in action and it's pretty cool. They have an online demo on their site. Personally, I've always just hand-edited config files (vi is your friend), but for a multiple-server enviro
Re:NetDirector (Score:1)
More than code versioning (Score:3, Insightful)
We supported a government client where issues were managed with word document templates and emails. It was a disaster, with things getting lost and weekly meetings being the only times decisions were made. They were spending a boatload of money developing something that looked suspiciously like a hobbled version of bugzilla, so we recommended and got approval to stand up bugzilla for issue tracking. It's been a big success and has been expanded to handle requirements management as well.
The key was to set up "products" that matched operational areas for a product rather than thinking that a "product" was defined as a single deliverable. We set up the standard "product" as deliverable, with subcomponents which somewhat matched the functional areas where developer responsibilities were broken down. Then we established a "product" which was essentially an area where management issues could be handled, and had subcomponents for tester access control, requirements definition, external coordination issues and the like. So when we went into testing and found an issue that we decided to defer to a subsequent release, it was moved to the admin area and the requirements subcomponent. This kept policy and requirements control out of the hair of the developers and allowed parallel workflows for requirements, design, development and testing.
It's not a perfect tool for all of that, but it's pretty close to "good enough", and the price is right.
What would I add to this mix if I were God? I would wiki the work-in-process user's manual so developers could flag issues that should be addressed in documentation rather than in code. I would probably wiki and/or subversion the test plans, as word documents utterly suck for test plan management. And I'd spend some time with wiki "special pages" and bugzilla customized components to integrate it all -- linking and content sharing between a wiki and bugzilla would bring the solution set into the 90%+ range of requirements matching.
Coders rarely are the problem in software CM. It's the management, architects, functionals and tester coordination that really has the potential to kill a project. But if you can coordinate all of them well, the flow of functional requirement - use case - design - develop - test - debug - requirement generation & traceability comes together cleanly and raises a development process into a portfolio management/enterprise architecture execution process.
Not tools, but process (Score:3, Insightful)
How do you do that? I don't care, and nor does Sarbanes-Oxley. We used to use Access databases at our place (and still do on some projects). Other projects use a tool called Visual Intercept, which I'd recommend people avoid like a rabid maneating tiger. Some projects have even used Excel (heavens preserve us!). Or simply use multiple text files (checked into your version control system of choice), one per customer request. Or Bugzilla or any number of other tools will serve your purpose. Tracking versions of files could involve some hugely complex build system, or it could just involve slapping a label across the files and doing "get all".
But if you don't grok the basic premise that every line in your code must be attributable to a customer request, then no tool you can buy will help you. This is a process you need to follow, not a magic-bullet tool you can install and everything will be fine. Repeat after me - There Is No Quick Fix For Quality.
The most important thing you can do make sure your system works is therefore to review each change before it gets signed off to make sure changes are complete. That doesn't just mean reviewing that files are changed, but that they're all checked in under version control, AND that the change details (however you do it) are fully filled in. Even if there's automated fields to list all files and their versions in, review them anyway - there's bound to be cases where someone says "well I've got one test file listed, so that'll keep the tool happy, never mind about the other 20".
Grab.
Re:Not tools, but process (Score:2, Insightful)
Coming from someone who was a ConfigMgmt person for my company, I faced a lot of these issues. First and formost, get a plan, even a simple one, and get it written down. Then modify it as needed. Also, Label every time you build. Any decent source control tool will allow you to do this. Be consistent with your labels, and be clear with them. This way, when a need to build version x.y.z arises, you can get back to it. Trackability is key.
drop the wooly language (Score:4, Insightful)
Rule Number 1: Process First, Tools Second (Score:1)
It's downright foolish to believe that a tool will solve your problems. But you sound like a
Re:Rule Number 1: Process First, Tools Second (Score:1)
Last year a team of some 35 of us actively worked on a project based on Mozilla. The Mozilla codebase is spread through more than 3500 directories, and $DEITY only knows how many (large) files. If each directory contained an average of 1000 SLOC, that's 3.5 million SLOC. Subversion handled this with no problems whatsoever.
Subversion gets 2 thum
Re:Rule Number 1: Process First, Tools Second (Score:2)
I'm working on a project of around 2.5 million lines of code with about 100 developers, and unfortunately Clearcase (which is what we're stuck with) is nowhere near up to the job - the merge tools die on merging large files, the reporting tools fall apart when the revision counts for a file get into the thousands, and the whole thing is so slow to do
You may have already failed the first test (Score:3, Insightful)
Step 1: Get the best staff you can. "10x" developers do exist, but you should be aiming for a staff of "3x" to "5x" developers of varying experience who work well together. The best developers won't really want to manage other people, but will want to be trusted with significant responsibility (i.e. they don't want to be fed detailed "specs"). Being good team members is at least as important as having top-notch skills.
Step 2: Get out of their way. At this point, you need to make it easier for them to get their jobs done. Most software development processes are about making it harder to do the wrong thing, which inevitably makes it harder to do the right thing. For many managers, software processes are like violence: "If some isn't good enough, more must work better." Don't fall into this trap.
Various things that will help (and not hinder) your developers:
When you get to this point, you'll have read a lot more about software development (your good developers can recommend some fantastic books) and you'll have much more precise questions.
If you don't read at least "The Mythical Man Month" [amazon.com] by Fred Brooks before managing a software team, you will fail and you won't understand why.
Regards,
Ross
Re:You may have already failed the first test (Score:1)
We do have very good and well trusted developers and fairly good processes and systems for bug tracking and so on...
We are a PeopleSoft site and our problem is that the complexities of releasing changes has become an issue for quality, we are concerned about developers overwriting other developer's changes because of the poor release tools we're using rather than the professionalism of the staff. We have a dedicated release team and each week we release our latest updates to t
Excellent website (Score:1)
Dimension - Serena ? (Score:2)
Hi.
I worked in a team trying to adapt XP to their work. I cared especially about nightlies automation. About the process, what I kind of remember ( a bit fuzy though) is: yes do have a theoretical process pretty clear in mind but trying to build the real solution without an "experimenting game" with the developpers is pretty hard. We had regulars meeting in order to change the process we where following. My point: I agree with previous post, start simple, and expend. The tools : ClearCase + a bug/service_
I started with the installer. (Score:1)
I started with FAI - http://www. [uni-koeln.de]
Software Config Mgmt \= Hardware Config Mgmt (Score:1)
Software development is one process in of itself.
The goal of software development is to produce a stable release that is suitable to be installed on a "live" or realworld or production system. In this sense a Software Config Mgmt system keeps track of configuration items which are commonly known
radmind (Score:2)