Continuous integration is a software development practice that involves automatically building and testing a project whenever any new code change is committed to the source code repository by the developers.
Continuous integration is a valuable feedback mechanism, alerting developers to potential integration issues or regressions as early as possible. Continuous integration relies strongly on a robust and comprehensive set of automated tests. Practices need to be followed to make continuous integration effective:
- Commit code to a single source repository
- Automate the build
- Make your build self-testing
- Everyone commits to mainline everyday
- Every commit should build the mainline on an integration machine
- Broken build must be fixed immediately
- Keep the build fast
- Test in a clone of the production environment
- Make it easy for anyone to get the latest executable
- Everyone can see what is happening
- Automate deployment
Continuous delivery is an extension of continuous integration, where every build is a potential release. Whenever a developer puts new code into the source code repository, a build server complies a new release candidate version.
If this release candidate passes a series of automated quality checks (unit tests, automated acceptance tests, automated performance tests, code quality metrics, and so on), it can be pushed into production as soon as business stakeholders give their go-ahead.
Continuous deployment is similar to continuous delivery, but there is no manual approval stage. Any release candidate that passes the automated quality checks will automatically be deployed into production.
The deployment process itself is often automated using tools like Chef, Puppet, or Octopus Deploy.
Both continuous delivery and continuous deployment encourages a much more streamlined, efficient deployment process. And both require a very high degree of confidence in the application’s automated test suites.
- BDD in Action – John Ferguson Smart