Many internal projects are actually enhancing already existing products, so the branching patterns should really be represented as starting from existing state and delivering back a changed (enhanced, we hope) version.
Multiple Parallel Projects as Part of a Product or Release
We then get to the case where there are potentially multiple projects or programs, each of which is delivering particular enhancements. These multiple projects may overlap in some way and both be changing a particular System, which will then need to be integrated
Lifecycle of multiple project development shows multiple projects or programs in development with their code being integrated for a particular release (i.e., 6.10) that occurs during system test. Prior to this point the projects are relatively independent of each other. The individual solutions may be concurrently updating the same application (Y in the example above). Integration and merging of the changes is done at the point of systems integration and test. The diagram omits the detail of the stage 1 (dev) branches. Also omitted are changes that may need to flow back to the projects as a result of problems during integration.
A very common model here is to have regular release cycles (i.e., several per year), where multiple projects are integrated and delivered into live usage as part of a global release.
In the IT Process Institute Change Configuration and Release Performance Study the most important two findings are:
- Release trumps change: Rigorous release build, testing and rollback practices have broad impact on individual performance measures and overall performance. Change tracking and change oversight practices are necessary, but not sufficient, to achieve performance improvement on their own.
- Process discipline matters: There are no change, configuration and release silver bullets. Building a process-focused culture and monitoring and responding to process exceptions predict top-levels of performance more than many of the industry recognized best practices in these areas.
Indeed, the report overview (available for free if you register) says the most important practice is:
- Release scheduling and rollback-In this set of practices, IT organizations develop and maintain a fine-tuned cycle of build and test, and then release only during maintenance windows with tested rollback plans. Data about the root causes of release exceptions is then fed back to systematically improve the process.
To this point, we have been discussing general SCM implications more than Agile in particular, so now let us consider some agile impacts.
Iterative Development - Releasing Frequently
Iterative development is not restricted to agile methods, and yet is a core part of agile development. If you release frequently, you become more skilled by looking for automation and not ignoring the many little details that can otherwise trip you up.
TDD and Test Frameworks
This is becoming increasingly common practice and one of its main benefits is that a good set of automated tests provides a safety net for future changes. They also act as documentation for the , thus making it more likely to be maintained along with the code.
There are still challenges in terms of finding the right level of automated test frameworks. Initial work focused on unit test suites during development. More progress is being made in automating tests later on in the cycle - integration and acceptance tests, as well as unit tests. This can, of course, be particularly challenging for systems that have many external interfaces.