Skip to main content
Engineering LibreTexts

7.6: Always Have a Running Version

  • Page ID
  • \( \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}}\)

    \( \newcommand{\vectorA}[1]{\vec{#1}}      % arrow\)

    \( \newcommand{\vectorAt}[1]{\vec{\text{#1}}}      % arrow\)

    \( \newcommand{\vectorB}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } \)

    \( \newcommand{\vectorC}[1]{\textbf{#1}} \)

    \( \newcommand{\vectorD}[1]{\overrightarrow{#1}} \)

    \( \newcommand{\vectorDt}[1]{\overrightarrow{\text{#1}}} \)

    \( \newcommand{\vectE}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash{\mathbf {#1}}}} \)

    \( \newcommand{\vecs}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } \)

    \( \newcommand{\vecd}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash {#1}}} \)

    Intent Increase confidence in changes by regularly rebuilding the system.


    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.


    Institute a discipline of integrating new changes and developments on a daily basis.


    • 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.



    • 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.


    • You must continuously integrate changes.


    • 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.


    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.

    This page titled 7.6: Always Have a Running Version is shared under a CC BY-SA license and was authored, remixed, and/or curated by Serge Demeyer, Stéphane Ducasse, Oscar Nierstrasz.

    • Was this article helpful?