Continuous Integration is an easy read that anyone directly involved in the software development process could gain a lot from. Even though it doesn’t really introduce anything new, it ties everything most developers have learned over time into a single process, called continuous integration. Here are a few of the things that I really liked about the book.
Automation
Automate everything. Automation limits the ability for bugs to creep into a process and it also makes processes easier to follow. After reading this book, I was really motivated to automate everything and so far it has been a great decision. Some good examples of things that should be automated are:
Tests
Environment setup and teardown, especially databases
Code inspection
Deployment
Databases
Very often, databases are not part of a build process or version control. This allows differences between different environments to potentially cause bugs. Putting database schemas and test data in version control can help prevent this. But, what I like the most, is it documents the setup of the database so potentially any developer could setup a new one.
For example, when a new developer starts, I can show him the NAnt or MSBuild.aspx) task to execute in order to generate a new developer DB. This is much easier than having to guide someone through MySQL, MSSQL, or any other database for the first time.
Transparency
Lastly, the biggest thing I learned from this book is how easily continuous integration can provide project transparency. In my experience, all to often the developers and the rest of an organization get out of touch regarding a project’s status. Continuous integration, combined with more agile development practices, allows a project to be completely transparent throughout an organization, from developers, to QA, to designers, and even senior leadership. No longer does a looming release date bring surprises for those outside the development team.