Introduction
The terms “Continuous Integration”, “Fail Fast” and “Agile” are more and more becoming part of today’s developers discussions. Old development practices such as Waterfall are no longer valid to fullfill the needs of flexibility, modularity and performance of current and future projects.
In this context, here’s an overview of what Continuous Build and Continous Integration are, and why they are useful. The presentation slides also detail best practices, and common mistakes to avoid when integrating these principles in a development team’s workflow.
CB, CI, CD
The Continuous Build (CB) principle is based on the Unit Tests the developers write. The idea is that those tests will be executed and verified every time a new change is brought to the code base ; this way, if anything breaks, the team is alerted immediately and don’t waste countless hours of debugging. This is also part of the “Fail-Fast” practice.
Continuous Integration goes one step further ; when all Unit Tests have passed, the system needs to ensure that the whole projects still works (i.e all of its modules still behave as expected). This is important, because a project that builds is not equal to a project that works.
Continuous Deployment has 2 objectives : verify the project still correctly interfaces with the infrastructure, like web services or external ressources, and ensure that the deloyment itself (typically migrating from an environment to an other) is streamlined and standardised in its execution.
Finally, Continuous Delivery allows the management and testing team members to always have a stable version at hand, which can be shown and demoed to a client.
Why do we need it ?
Those principles offer development teams the possibility to increase the quality and value of the whole development process ; small bugs are detected and fixed early, tests are documented and there’s no surprise when the time comes to promote the changes to production.