Principle #1 - Builds should be repeatable

The first of The Five Principles of Software Deployment is that Builds should be repeatable.

This means that for any application that you build and release, you should be able to rebuild that application exactly as it was built at the time of release at any time in the future.

If you keep copies of all applications that you release, why would you need to repeat the build process for one of them? The answer lies in the fact that all software has bugs. And if someone discovers a nasty bug in a version of your application running in production, you may be called upon not only to reproduce that bug, but more importantly to release a version of the application whose only change is the bug fix. The ability to go back and repeat the conditions of the original build is essential in this case.

This is not a hypothetical scenario in my experience. It has happened on a number of systems that I’ve worked on over the years. A good manager will want to minimize risk whenever possible, and applying a spot fix to solve a production problem is one way to do this.

So how do you achieve repeatable builds? The following list provides some guidance on how to add repeatability to your build process.

1. Use version control.
2. Version your tools and dependencies.
3. Label your releases.
4. Automate your build.
5. Create a separate build user.
6. Document your build process.

The items in this list will be covered in greater detail in upcoming posts. In the meantime, let me know if you think anything should be added to this list.