[Book Review] Continuous Integration
Tagged Under : ci joe, ci server, continuous integration, cruise control, git, github, hudson
Hi everyone,
I really enjoy reading some technical books, it is one way to keep myself up-to-date and become a better developer. Whenever possible I’m going to share with you my reviews. That’s one way to track the good parts I’ve learned as well.
The first one I’m gonna talk to you is about “Continuous Integrations – Improving Software Quality and Reducing Risk”:
I’m not going to delve into the subjects, the main idea is to provide you some information about CI and arouse curiosity in you to read the book 
There are many processes that encompass what we consider be a deployment. And one of them is what we call “build”. A build consist of compilation (if needed), testing, inspection and then deployment itself. It’s just one process to get all the source code and put it together and verify if the sofware itself keeps working as expected.
A good pratice is to perform a build whenever you have a code pushed to the master branch in your repository. This lets you see if any code changes broke something. To apply it in your project, you must configure a “Continuous Integration Server”. If you do a quick search in Google you’ll see that it comes in many flavors: CruiseControl, Hudson, CI Joe and so forth.
Basically these are the steps that a CI Server follow to make a new build:
- Get the latest changes from the main repository.
- Run a build that includes execution of all your tests (unit, acceptance, ..).
- Commit your code changes to the repository.
What if something goes wrong with the build? It’s your responsibility to stop whatever you’re doing to fix the build. You must keep the build in the green, which means passing all the tests and integrating the code sucsessfully.
There is a common mistake that you should avoid whenever it is possible, that is to configure your CI Server in a different machine. Don’t use your development machine to run your integration server. You may be asking yourself “why?”. This avoids a typical scenario: “It Works on My Machine”:
You will prefer to use a separate machine solely for integrating the software. In our development machine we have everything configured and ready to run our own code properly.
Committing code frequently to the version control repository is the only effective way to implement CI, and this means that all developers need to embrace this development practice by grabbing smaller chunks of code and breaking up their tasks into smaller work items.
Build Types
The author says that the build types occur in a three-level hierarchy:
- individual – A developer runs a private build. Which means: get the source code from the repository, do a merge integration its change, and check if everything works;
- the team – The build that integrates the results with all the changes made by the whole team;
- users (the customer) – a release build readies the software for the users.
If you don’t have any idea how continuous integration works at all, I highly recommend reading this book. If you already have a rough idea what it is, and have some question marks above your head, give it a try too. There are many tips teaching you how to improve the way you do continuous integration. I’m pretty sure you will find something that can improves the way you run continuous integration at your company. This book isn’t just a “big picture” about CI.
To finish, I’d like to leave a link here, from Martin Fowler’s blog. I’m pretty sure you will enjoy the reading: http://martinfowler.com/bliki/FeatureBranch.html
Stay tuned for the next reviews. And, remember: “Keep Builds in the ‘Green’”
