| At this point, it is worth taking a step back and examining why you want to automate the Software Build and Release Management process. Also, what are the requirements for such a process? What issues and challenges is the process intended to solve? This section looks at just thatthe challenges customers typically face when building and releasing software. The challenges described in this section are those that I have directly encountered (the best kind), observed, or been informed of. What Exactly Is It? Traceability and Completeness One of the biggest challenges that people face in the software development community is maintaining traceability. Traceability is knowing throughout the complete software development life cycle (not just building and releasing) why you are doing what you are doing. Completeness is related to traceabilityit is making sure that the build or release contains all of what was intended. Lack of traceability and completeness manifest themselves in a number of ways in Software Build and Release Management: Not being able to say exactly what is in the build What new features, enhancements, and defects have been addressed? Who requested them, and why? Nothing is worse than a new build (that has had defects fixed) being given to the test team without their being told exactly what the fixes are. I am always amazed how often this happens. Not being able to say how the build was carried out What versions of the code did the build use? What third-party libraries? What compiler options? If testing or the customer finds a problem with the build, can you relate it to the exact environment and versions of the code used so that you can start fixing it? Not being able to say where the build has gone Where is the build being used? What release is being tested? What do your customers have? This kind of information is really important but is not done very well. Knowing who received what and where allows you to be proactive. For example, capturing this type of information allows you to see if a critical problem is found and who else it would affect. Then you can inform them directly rather than waiting for them to find the same problem. This is just good customer service. Incomplete software builds Software components are found to be missing or incompatible. This situation often occurs when separate subsystems or components are delivered by individual teams into a centralized build process. Often extra checking is required to ensure that all components have been delivered and that they are intended to work together. Incomplete releases Supporting documentation or associated artifacts are missing from the release. All too often a good build is let down by its supporting information. For example, distributing a build without any release notes or installation or configuration instructions does not work. This is like being given some self-assembly furniture without the instructions!
One of the hottest topics in IT development today is regulatory compliance, particularly with operational mandates such as Sarbanes-Oxley, Basel II, or 21 CFR Part 11. Maintaining traceability and completeness is one of (if not the) main mechanisms in being able to demonstrate compliance with such mandates. Let's Go Again: Repeatability and Reliability Being able to produce a build is great; being unable to reproduce the same build again and in exactly the same way at some future time is not. Repeatability is about being able to do the same thing over and over; reliability is about its being correct each time. Lack of repeatability and reliability manifest themselves in a number of ways in Software Build and Release Management: Not being able to reconstruct a build carried out previously What happens if a problem is found in a Release Build that went to the customer six months ago? Can you reconstruct the build environment as of six months ago, fix the problem, and ship a patch to the customer? You might get away with this if you always deliver the latest and greatest code to your customers, but at some stage you still need to work retrospectively. Not being able to consistently construct and deploy a release package Is the content of the release package the same each time? When you deploy the release package, is it installed in exactly the same way? After you've spent all that effort developing and testing the code, getting the build to work, and packaging it, not being able to get it to the users who require it seems like madness to me! Having continual problems with the reliability of the build execution When you test a build and find problems, are you sure that the problem is with the code, or could the problem be with how the code was built? You should be able to rely on the build process. Of course, it will not be infalliblecertainly not in its infancy. But over time if a problem occurs during the build, you should be completely confident that the code being delivered into the build is at fault, not the build process itself.
Faster Than a Speeding Bullet: Agility and Speed Building an application is an integration and test exercise in its own right. Agile "implies being effective and maneuverable" [Cockburn01]. Agility is about having a build process in which changes can be integrated quickly or as and when needed. Speed is about the build process being completed in as short a time as possible. Lack of agility and speed manifest themselves in a number of ways in Software Build and Release Management: Not being able to integrate changes quickly If problems occur during development or testing, can the developer responsible fix the problem and immediately be able to initiate or request a new Integration or Release Build? This would be even more important if the testers were blocked and couldn't test any more until they received the new build. Developers waiting for the output of the build Does the build process take so long from beginning to end that you can afford to build only once a week? What happens if that one build fails? Do the developers have to wait another week before they are sure their changes have integrated successfully?
Obviously, you need to find the level of agility and speed that is right for your environment. I call this "finding your project rhythm," and I will return to this concept throughout the book. |
