In his CM: the Next Generation series, Joe Farah gives us a glimpse into the trends that CM experts will need to tackle and master based upon industry trends and future technology challenges.
Configuration management allows us to repeatably build product that can be delivered to the customer. In the hardware world, the "build" process is called "manufacturing" and the deployment is known as "shipping and installation." In the software world, our manufacturing is done through a build process, and our deployment is often automated, perhaps over the internet. However, unlike for hardware development, software teams continually build and rebuild the entire software product during development and can deploy these builds locally for verification. So the build process is not just a manufacturing process, but a development process as well. Deployment, during development, may involve deployment to the workspace area for developer testing, to a central test area, or to lab equipment. After that, there are still deployment considerations for verification, production certification, and finally to customers.
Build is central to CM. It's critical to do it right.
A basic build capability is founded on two key fundamentals: the ability to reproduce the build and the ability to automate the build process. Without these two fundamentals, you're fighting an uphill battle. Reproduction of the build implies that you have a CM system able to capture the build definition. Automation helps to ensure that no manual errors can play into the production. But this is just a basic build capability.
To move up the ladder, there's plenty more to be done. First of all, automation must be made available to all levels of the team, from production down to developer. Each member of the team needs the same assurance that the right stuff is being built: developer, integration, verification, production.
It's one thing to automate the build, but in a continuous or regular integration cycle, there could be a lot of work in deciding what's going into the build, especially in larger projects. So what's the secret to successful regular builds? Make sure you have quality going into the builds. To get a series of quality builds, it's important to make sure of two things: Start with a stable build and ensure the changes going into the build are of high quality.
If you've got a half-baked build to start with, don't open the floodgates for other changes. First, stablize the build through intensive debugging and changes that move the quality forward only. Once you have a stable build, you're in a good position for the second requirement—high-quality changes.
High-quality software changes are a product of many factors:
- Good people
- Good product architecture
- Effective peer reviews
- Feature and integration testing prior to check-in
- Ensuring the changes that go in are approved
Good people are hard to come by, but good processes, with a good mentor, can make average developers very effective. A mix of software experience, application experience, objectivity, and strong design and software engineering skills are desireable.
Good product architecture is key. I remember in my very first job, I had one week to get a code generator debugged and working. I looked at the architecture and it just wasn't there. The only way I could make the deadline was to throw out the existing work and rebuild from scratch; although, with a good bit of help from the existing work that had been done. The tactic was successful. Now, you might not want to throw out your entire flight software or telecom system, but if there are components that are overly complex and lack good architecture, your changes are going to cause problems. Your builds will have bugs that need to be ironed out before restoring a stable build, the first premise for the next build.