The manufacturing industry has been occupied with reducing waste and cost while improving quality since man met machine in the Industrial Revolution.  Frederick Winslow Taylor introduced the concepts of time-motion studies, standardization, and best practices in his Principles of Scientific Management (1911).  Automation then leaped ahead when Henry Ford developed his vehicle assembly line system by focusing on strict specifications of parts and tasks, removal of useless components, and simplification of necessary ones.  Ford's tight tolerances made sense for companies operating in relatively infrequent business cycles and selling monolithic products, but change and choice have accelerated over time.  Japanese companies recognized the new constraints and developed these ideas further into methodologies such as 5S and the Toyota Production System (TPS), which are generally recognized as the ancestors of Lean.  This blog is dedicated to applying Lean insights to Information Technology. Some of the topics that will be covered include agile project management, enterprise architecture, software component design, unit testing, continuous integration, and team culture. 

Continuous Integration refers to a Lean set of tools and processes for frequently preparing software for release.  An essential element of Continuous Integration (CI) is the maintenance of a revision control system for the software artifacts.  On large software projects, it is common for servers to be dedicated for hosting the software repository as well as the build process.  The heart of CI is the build process that detects changes to the software repository and then executes code compilation, unit tests, deploys to an environment available to users, and packages the release into a set of files for subsequent shipping.  Another CI requirement is distinct environments for development, testing, and production.  These environments can be available as physical or virtual machines.

Beyond these core CI elements, there are some secondary considerations.  First, it is recommended that engineers both check out the latest code and submit incremental changes on a daily basis to get feedback faster and reduce the risk of conflicting with other system changes.  Written and verbal communication through documented requirements and team scrums are also good ways to complement the daily checkin and checkout; they ensure that the team works together efficiently.  Second, the build should also be executable using a single command.  Enbase is a Microsoft shop and uses the Cruise Control .NET  system and NAnt scripting language to automate its build process.  Another good choice for .NET software is the Microsoft Team Foundation System and MSBuild.  Java, C, and other computer languages use different tools.  Build details are further discussed in a separate blog post.  Third, the build should be fast and its results visible.  A speedy build allows integration problems to be quickly identified and resolved.  Visible results in the form of a web site and email alerts also give an early warning of broken code and incompatible changes.

CI supports Lean software manufacturing in several ways.  It speeds system delivery by reducing the time to release software.  It amplifies learning because engineers are incentivized to upload incremental changes to components that are immediately compiled, tested, and integrated into the system.  It improves team confidence and increases vital feedback because the system is easy to release and make available to users for testing and acceptance.

Is Continuous Integration worth it?  Engineering teams must have the discipline to start up and maintain build infrastructure, but similar to an automobile factory, the productivity and quality benefits strongly outweigh the costs.  So yes, CI is worth the effort.  Enbase would not build software without it.

References

Joel's 12 Steps to Better Code