Continuous Integration
The key to success with CI/CD is to automate and monitor as much as you can practically. A well-tuned CI/CD pipeline will help your organization quickly deliver quality code to your customers.
Continuous Integration is a development practice that ensures your application is always in a “good” state. This means that anything in your master or pre-production branch is in working order and never stays broken for long. In order to achieve this, it is essential to have broad, well-written unit tests so that code can be merged quickly. Optionally you may also have integration tests that ensure the pieces of your application work together properly. Integration tests are more effective when you have a CD pipeline that is deploying your master branch to a development environment and running the integration tests, either manually or automated. You must also have an alerting method in place for when (yes, when, not if) your integration tests fail to catch issues.
Another key aspect of CI is testing any database migrations or config changes before production. Having a development environment that’s similar to your production environment gives you a safe space to test these changes and reduces the likelihood that mistakes will make it to production, but it is recommended to have a staging environment in addition to your production and development environments.
Continuous Delivery
Continuous Delivery is an automated way to deploy your application to an environment. This can involve a number of automated or manual steps, including more integration testing, performance testing, or manual testing. The level of automation involved depends on your needs. Netflix is known for having a completely automated continuous delivery system. Because deployments are automated and can happen at any time, your application should be designed in such a way that it is not affected by temporary outages when a new version is deployed. More on this later.
A basic CD system will have two environments. One developer environment, where new features are tested and integrated. One production environment, where your application is exposed to the Internet.
Simple CI/CD Pipeline
Your CI pipeline is usually triggered when code is checked into an integration branch by a developer. Unit tests are run to ensure basic functionality is correct, and then, binaries are built. The binaries created could be a JAR or Zip file or even a Docker container.
The CD can be triggered after a successful build, or it can be timed. Typically, for dev environments, your CD pipeline will be triggered by every successful build. Deployment to production can be an automatic process or can require manual sign off.
The CD can be triggered after a successful build, or it can be timed. Typically, for dev environments, your CD pipeline will be triggered by every successful build. Deployment to production can be an automatic process or can require manual sign off.
Getting a CI/CD pipeline up and running can take a lot of work. Projects like Jenkins, TeamCity, and Spinnaker can help you setup and manage deployments yourself, but that can be difficult, especially if you’re starting from scratch with Jenkins. If you’re looking for a hosted solution, products like Caylent, Heroku, or Amazon’s Elastic Beanstalk provide easy-to-use solutions.
0 Comments