it is possible that a less than comprehensive test can give you any sort of stability. This only works because developers will be running more comprehensive Unit Tests while they are doing coding, and you also have an Integration Build process that runs a full suite of Unit Tests and a Regression Test . You are making the decision that delayed integration will cause more problems than a slight chance of a build problem. And the integration build and test process ensures that when a problem slips through, you will catch it quickly.
In many cases, the full suite of Unit Tests may be quick enough to run so that developers can, in fact, run comprehensive tests before check-in, but if the comprehensive testing starts to take long enough that developers defer integration, you should consider a simpler pre-check-in test suite.
Figure 3: Supporting an Active Development Line
Agile, Lean, and other Cliché’s
The SCM Patterns support a development environment that adapts to change. Most all development environments are ones where change and uncertainty is the rule. There are two adjectives that describe approaches to development that are focused on change: Agile and Lean. Let’s spend a few minutes reviewing the concepts.
Here are some common objections we encounter, and some answers.
- We can’t integrate frequently ; some of our software is intellectually difficult, and it may well be weeks before code is ready. While the core code may be difficult, it is probably possible to define the interfaces to components so that related systems can move forward, as in Figure 4. If the developer of the really complex system is writing appropriate unit tests that pass, the integration overhead can be minimal.
Figure 4: Testing with Complex Algorithms
- I can’t write tests unit tests . Are you sure? In many cases, “not testable” often indicates a potential problem with the architecture.
- I don’t need to be agile . If you are delivering software that gives value to your customer in a reasonably timely fashion, and with reasonable quality, then you are probably doing everything OK. You may find benefit in working to improve your processes so that things are even better. If you are really are doing an effective job, it is extremely likely that you are open to new techniques.
- We need to define requirements in advance, so this iterative/incremental approach isn’t going to work for us . Ask yourself when the last time you worked on a project where everything you planned up front was accurate. Agile approaches don’t say “Don’t Plan.” Agile approaches simply acknowledge that plans are often incomplete or incorrect.
- Our Developers are doing agile, but Release Engineering needs control . There are two points to here: 1. See the title of this article. 2. You should think of your self as working in a Software Development Organization, not a Release Engineering group, or a Programming group. If one groups needs don’t mesh with the others you’ll have integration issues that will slow things down. Try to understand how to work as a team.
When a process is broken we are often tempted to do something, even if we’re not sure that it is the right thing. By imposing rules and processes we feel like we have control, but more often than not, the control is illusory. And in many cases the solution is very obvious; to solve integration issues you need to integrate code frequently. Most errors occur at boundaries, so many problems are integration problems at the code.
Sometimes doing this will clash with established process or