Home 
CM: The Next Generation NEXT GENERATION CM: Building: Change Management First
CM: The Next Generation NEXT GENERATION CM: Building: Change Management First
|
| Building is considered to be one of the fundamentals of Configuration
Management, even though some might argue that Building isn't really
CM. The reason it is fundamental is that the build/verification cycle
provides proof of reproducibility if done correctly. It forces CM to
be done correctly so that only the objects from the CM repository are
used to reproduce the build. When formal build processes are correct,
they need no information that resides outside of a CM repository. And
when properly done, the build record is created prior to the build
(i.e. a build notice) rather than as a result of the build - that
record being used to drive the build process. A integral Change
Management capability is an essential component of such a build
process.
Types of Builds We can classify builds into three distinct categories: Release, Integration and Developer. They might be loosely categorized as:
A release build is one that is done for a formal or candidate release of the build outside of development. This may be for formal Verification, for Field Trial, Beta Trial, or Production. It differs from the other two builds in that there already exists a snapshot of what is to be built in the CM repository. You specify which snapshot you wish to build and then, using only data from your CM repository, your build tools/process produce the required outputs. Integration Builds An integration build is similar to a release build except for a few distinctions. First of all, part of the integration build task is to assemble the correct objects into a prospective snapshot which will be used for the build process. Secondly, there is generally some latitude for modifying the prospective snapshot prior to freezing it. This might occur, for example, if the build attempt caused compile errors, or perhaps if the built product would not successfully initialize during basic sanity testing. Generally, urgent changes are produced to "fix the build". Different shops have different rules for such latitude within a build cycle. Some will say: leave the initial snapshot and always create a new snapshot for any corrections, especially if there is not good traceability of what changes were required to fix it. I don't generally agree with this as it may cause confusion when a developer comes in the next day and sees four new snapshots, even if they are properly marked with an appropriate status in the repository. And it may make it more difficult to pinpoint a snapshot in the past. My opinion is that a snapshot is frozen when the build team puts its seal of "sanity tested" on it. This does not mean that all sanity tests were passed, but instead, that it is more beneficial to "release" this build to the development environment then to stick with the previous one. And that will be a judgement call at times. A third distinction is that integration builds are generally done on a specific timeline. In fact, in many shops, they are automatically performed in the "middle of the night", that is, nightly builds. Does such a term has a meaning in your global development shop? Some of Neuma's customers do builds in the "middle of the night" at each separate development site. In this way, they may actually be doing multiple integration builds a day. Others focus each site on a particular development stream and so different streams of development are integrated at each of the different sites. A potential fourth distinction might be to say that integration builds might be either incremental or full build operations, whereas the same is not true of a release build. There is some wiggle room here. I might recommend that, at least a couple times a month, full integration builds are performed. This will help to verify the continued correctness of the full build process. Most shops tend to do full builds on a nightly basis. This is dependent on the capabilities provided by the CM tools, as well as on the size of the operation. If the CM tool knows what was built the previous night and knows the impact of all changes going into the current build, there is not a necessity to do a full rebuild. Similarly, if your build process has a reliable way of ensuring, for example, that a "make" operation will always do "the right thing", then a full build is not required every night. On the other hand, for Release builds, there is always a need to verify full reproducibility so that you know that at a point in the future, if necessary, a full build may be generated without problems. Developer Builds A developer build is different from release and integration builds in various ways:
Automation of Integration Builds The process of automating builds has a lot less to do with the build process than with the change process in your shop. However many shops ignore this and automate the builds regardless of the change process. When this happens, the automated build becomes king and change management, as well as configuration management, fall slave to the build process. It is important that a proper change and configuration management process be used from which build automation will flow out rather than vice versa. For example, consider a shop that says: "We're going to use a basic CM tool and automate nightly builds by pulling out the latest checked-in code, including 'make' files, and perform the build operation. We'll then make the resulting build environment available for anyone who needs to make/test changes the next day." The process is easy to implement: pull out the latest code (into the right places) and invoke the top-level make file (which will invoke whatever other ones are required). It's simplicity means that the process will be implemented accurately, so that's good. However, there are numerous other implications and omissions in this statement, and some have far-reaching effects. For example, a developer will not check in any code that is not fully tested for fear of "breaking the build". Good testing is good. Leaving code checked out longer than necessary is not so good. In fact, a rapid add-on to the above process is: "You need approval for checking in any code changes that are not required to fix urgent bugs". In the context of the process, this is reasonable and even good. But overall, code is going to be checked out for even longer periods. When code is checked out longer than necessary, more parallel changes are required. When the developer does not have full control over when they are checked in, even more parallel changes are required. So starts a complex maze of branching and merging and a Configuration Management and labeling strategy begins to grow for management of such branches and merges. Another implication of the above is that the make files checked in are going to be used for the build operation. That's not bad in itself, but does it force a serialization of changes to the make files, and implicitly the corresponding code changes, that is other than optimal. In other words, the structural changes of the product are tied to the code changes of the make file(s). One frequent response is to segment the make file into many little pieces. Now anyone who has worked with make files knows that they can be complex beasts. So now this complexity, along with all of the maintenance of the complexity, is distributed and/or replicated into many files. You could probably identify some other reprocussions from the above nightly build policy. For example, what happens when a build breaks? What happens if the server is down prior to the build and required changes don't make it in? How does a change control board figure into this? What about parallel stream development so that work on the next release can be started? These questions all hinge on the CM Process and Tools used to implement your Change Management Process. CM Requirements for Build Automation To keep Change Management working properly we need to take a different perspective. To effectively run an automated build and effective integration shop there are a number of requirements that must be met by the CM tool and process. Let look at some of these: (1) Change Packages (aka: Updates): Ability to treat code changes as logical changes, rather than as file changes. Let's face it, a designer will fix a problem or implement a feature. The files being changed, as well as the problem(s) or feature(s) being addressed form a logical unit of change. The change must move through the system as a whole, from check-in through all levels of promotion. File-based CM is an old concept and if your tools push you this way, it's time to look around. (2) Snapshot: Ability to snapshot a build record and to easily reproduce the build from the snapshot. A build record must be something that drives the build process rather than a record of a build being performed. Reproducibility is the goal. The snapshot can be in the form of an enumeration of file revisions (including tool/process components), as is done for a typical baseline, or perhaps in terms of an existing baseline plus a set of change packages relative to that baseline. (3) Push: Ability to check-in code without forcing it into the next build(s) - Completed code that's out on a developer's disk is a liability. It's prone to disk crashes; it's prone to becoming out of date; it's likely to go through fewer verification cycles. Completed code belongs in a repository where it can be used by others, simply to review, or as a basis for future changes, without the need to have a parallel change branch. A developer should be able to put a source change into the repository even before dependent changes are checked in. The developer then pushes the change to the "ready" state after confirming it's ready to go into an integration build. (4) Pull: Ability to differentiate between check-in authorization and build acceptance [similar to (1)]. Often, especially at the beginning of a release development effort, any code that has been marked ready is automatically picked up by the nightly integration build. Although this may be sometimes sufficient, it is not sufficient as the release approaches and changes are more selectively pulled into the build for integration. The developer pushes, the integration team pulls. (5) Roll-back: Ability to roll-back changes that "broke the build" in an easy manner. A change breaks the build. The best solution is to put in a new change to fix the broken part of the change. This provides full traceability of the problem. However, sometimes, it's too complex to fix and the best solution becomes "roll-back" of the change so that it is not part of the build. Ideally this is a simple state change on the build. If changes are already stacked on top of this change, it may require "yanking" changes. More complex CM tools/processes use parallel streams for promotion (as opposed to state changes). In such cases, rolling back a change may entail additional steps, some of which may even be required in more than one of the parallel promotion streams. (6) Fix-the-Build: Ability to adjust the snapshot (ie continue to (re)define it) by adding or remvoing changes, until it is frozen [extension of roll-back]. More generally than a roll-back, it must be possible to arbitrarily modify a build record (i.e. notice) so that additional fixes may be added to it or errors in definition of the build record may be corrected. This must be easy to do so that the build can be successfully completed for the team's use. It should only be done on a change-by-change basis - never on a file basis. A change must always be in or out, never partially in. (7) Dependencies: Ability to keep the build definitions in a consistent state for the build operations. As changes are added or swapped out of a build record definition, the CM tool must notify you of violations in dependent changes. For example, if a second change has already been built on the one being pulled, the tool must notify you of this and allow you to take approprate action to ensure a consistent definition results. (8 ) Structure: Ability to associate structure changes with a change. It's no good pushing and pulling changes if the structural changes that go with the change are not also pushed/pulled. For example, if a change moves a data file from one directory to another, or deletes an existing file, these structural changes must be packaged with the source code changes so that everything moves together through the system, whether forward or backwards. (9) Promotion Levels: Ability to support multiple levels of integration, especially in larger projects. Promotion to integration is a single promotion step. In larger projects, there are several levels of integration, especially in task-based development environments where a major task might be sub-divided into smaller tasks which are then integrated prior to integrating the larger task into the "mainline". Larger projects will have more promotion levels. I am often reluctant to use parallel streams for promotion because there is a natural reluctance to running through an additional merge cycle when a new promotion level is added. Instead, I prefer state changes with a process which tends to support a higher percentage of changes moving through the promotion levels in the same order as they are checked-in to the repository. (10) Get: Ability to retrieve files for a build into an integration workspace. Given the definition of a build record, it must always be possible to easily retrieve the files from the repository so that they can be readily and reliably built. This includes support for both incremental and full workspace retrievals. Along side this is the ability to easily identify differences between any snapshot and the contents of a workspace. (11) Stream: Ability to identify changes and do builds for multiple development streams of a product. A stream is a separate codeline targetting a different release of a product. For example, release 1 and release 2 would generally have separate development codelines, with release 2 slightly, or not so slightly, overlapping release 1. A stream is basically a codeline that culminates in a new release. The CM process and tools must support this function. Many processes will use a single "mainline" which switches at some point from release 1 to release 2. I do not recommend this. It introduces a number of arbitrary decision points and more complexity into the development process. For example, the process for making a change to release 2 changes at least twice in the single mainline approach: once when the switch of the mainline to release 2 is completed, and again when the switch for a subsequent release is completed. (12) Product: Ability to identify changes and do builds for multiple, possibly dependent, products. CM tools need to support and clearly identify multiple products. Dependencies between the products need to be identified, both for build purposes and for impact analysis. (13) Compare: Ability to compare any to builds to identify the difference in terms of changes (as opposed to lines of code). For a successful build operation, it must be possible to easily compare any two builds. For example, the build manager should be able to take the new build definition and identify the changes that are being added to the previous definition. It's not so much the code changes that are important as the logical changes - i.e. what is being done. It's the logical changes that will be pushed and pulled in correcting an errant build. It's also necessary to be able to identify problems fixed, features added, etc. so that integration testing can first focus on the correctness of these features prior to regression testing of pre-existing features. Ideally, your CM tool will let you point to any two builds and compare them in such a manner. That's a pretty long list of requirements. Are they comprehensive? I don't think so, but it's a good start. Design your build processes around a solid change management capability and you're well ahead of the game. Start from an inadequate base and you'll be playing catch-up forever. That was OK when we were trying to figure out what CM is. But now that we know, and now that we have a much more solid understanding of Change Management, Change Management: Requests and Changes Change Management has two key components and Build Management must fully support these. On the one side, there's the Change Request; on the other there are Changes (i.e. change packages). Builds are defined in terms of Changes applied to a previous build or baseline definition. This eliminates the tedium of managing file versions and labels. Each Change needs to be targeted to a specific product and to a specific stream of the product. The Change should exist prior to the first checkout operation. The promotion level of a change, typically indicated by its "state", is used to determine which builds it will be part of. Promotion is always done on a Change basis. And Changes must indicate their dependencies on one another, either implicitly through file history, or explicitly through pre-requisite data. The build process must use the dependency information to alert the build team, the CM manager, or even the developer, whenever a promotion operation leaves dependents behind. Change Requests are quite different from Changes and should not be used as a Change container. A Change Request might be implemented in several Changes across several releases. Or multiple Change Requests might be addressed by a Change. The originator, or requestor, of a Change Request communicates the request to the product team, which ensures that it has a proper understanding of the request. Once this handoff occurs and the product team accepts the Change Request, it is treated as a Requirement. The originator will want to know when the request will be/has been implemented and when it will be delivered. The originator is responsible for closing the request - i.e. indicating that the implementation meets the criteria of the request. Builds as the Key Reference Points So, where does the Build come into play? It must be possible to take any build and identify which requests of a particular originator (or group of originators) have been met by that build. On the flip side, that leaves the set that is outstanding. If your CM traceability cannot give you this information, you need to improve your data and processes. Ideally, this information should be available at the click of a button (or at least a simple report request panel). When this loop is closed, your builds are more than just a set of executables. They become the key reference points for communicating with your customers:
Set as favorite
Bookmark
Email this
Hits: 11510 Trackback(0)Comments (2)
|
TrackBack URI for this entry
Subscribe to this comment's feed |
... Nice article. I'm glad you mentioned promotion levels and the importance of being able to support multiple levels across the entire cycle. I've seen shops that have a simple Dev->Test->Release cycle and that's all they need to be effective. I've also worked with large (gov't) shops that have very methodical workflows such as: Dev->ProjectTest->Int->SystemTest->LabTest->FlightTest->Release. In either case, and as you mentioned, it's important that all code move through the same workflow. I'd also like to add that it is critical for downstream levels to have immediate visibility to changes in higher levels. If I introduce a changeset directly in my topmost test level, then all other (child) levels should have the ability to instantly and automatically merge in those changes without requiring per-level, *manual* merge events. Otherwise, you run the risk of introducing regressions because someone 'forgot' to merge to a particular level. Great article. : dave www.accurev.com |
sspectrum
said:
 |
... Excellent Article. In fact Joe has captured and articulated very well the problem areas in the traditional way of managing your build, at the same he has presented nicely the power and benefits of combining the Change Management features and use of a process-centric SCM tool to be the gate keeper for ensuring the integrity and accuracy of your build process. Nice work , Joe !! - Srini www.spectrumscm.com |
Write comment
You must be logged in to post a comment. Please register if you do not have an account yet.
