7.6: Always Have a Running Version
- Page ID
- 32405
\( \newcommand{\vecs}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } \) \( \newcommand{\vecd}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash {#1}}} \)\(\newcommand{\id}{\mathrm{id}}\) \( \newcommand{\Span}{\mathrm{span}}\) \( \newcommand{\kernel}{\mathrm{null}\,}\) \( \newcommand{\range}{\mathrm{range}\,}\) \( \newcommand{\RealPart}{\mathrm{Re}}\) \( \newcommand{\ImaginaryPart}{\mathrm{Im}}\) \( \newcommand{\Argument}{\mathrm{Arg}}\) \( \newcommand{\norm}[1]{\| #1 \|}\) \( \newcommand{\inner}[2]{\langle #1, #2 \rangle}\) \( \newcommand{\Span}{\mathrm{span}}\) \(\newcommand{\id}{\mathrm{id}}\) \( \newcommand{\Span}{\mathrm{span}}\) \( \newcommand{\kernel}{\mathrm{null}\,}\) \( \newcommand{\range}{\mathrm{range}\,}\) \( \newcommand{\RealPart}{\mathrm{Re}}\) \( \newcommand{\ImaginaryPart}{\mathrm{Im}}\) \( \newcommand{\Argument}{\mathrm{Arg}}\) \( \newcommand{\norm}[1]{\| #1 \|}\) \( \newcommand{\inner}[2]{\langle #1, #2 \rangle}\) \( \newcommand{\Span}{\mathrm{span}}\)\(\newcommand{\AA}{\unicode[.8,0]{x212B}}\)
Intent Increase confidence in changes by regularly rebuilding the system.
Problem
How do you convince your customer that you are on the right path?
This problem is difficult because:
- It can be hard to demo a software system under development, or to discuss problems with users since there is often no stable, running version of the system available.
- Integrating changes from multiple versions of a system can be slow and painful.
Yet, solving this problem is feasible because:
- You don’t have to wait until a component is “finished” before integrating it.
Solution
Institute a discipline of integrating new changes and developments on a daily basis.
Steps
- Have version management and configuration management systems in place.
- Make sure you have regression tests in place for the parts you are working on.
- Institute a discipline of short transactions for checking out system components and checking them back in again. Plan iterations to be as short as possible to allow changes to be integrated into a running system.
Tradeoffs
Pros
- You always have a working version to demo.
- You can always have a working version to run your regression tests.
- You can quickly validate your changes, thereby helping you to Build Confidence.
Cons
- You must continuously integrate changes.
Difficulties
- Large systems may have very long build times. You may need to rearchitect the system first to enable shorter build times.
- It can be hard to break some kinds of large modifications into meaningful updates that can be individually integrated.
Rationale
Many practitioners advocate a process of continuous integration as a way to avoid a risky and painful big-bang integration [Boo94].
Related Patterns
Regression Test After Every Change minimizes the risk of defects creeping in during integration.
Continuous Integration [Boo94] [Bec00] is a proven way to Always Have a Running Version.