CI/CD

Continuous integration / continuous deployment of code into dev, test and production environments

💡

Key objective: get code into each environment you use, dev, test or prod, in an automated way and most importantly repeatable way.

Make use of trunk-based development. Don’t use long-running branches; have developers use branches based on the work that they will be doing over the next day. This way changes become smaller and smaller, easier to review and have an impact upon the existing system as easy to uncover because the impact of the change upon the system is small.

A good CI/CD pipeline begins on the developers machine before the commit happens. Run static analysis, linting, across the changes, make sure it enforces the coding standards your team has decided upon. Make sure the branch name matches the standard you need for integrate with your task management system, and run unit tests again those parts of the application which the code has impacted.

When a new branch is pushed to the version control system make use of the Pull Request (PR) process to require another developer to review the change. Install the dependencies for the project, build it, and run all unit tests, static analysis and security checks. Any failure of these needs to notifiy the developer and prevent the PR from being merged.

To speed up the review process create a review release for the branch, this gives the reviewer the ability to execute the code in a test envrionment without needing them to do it themselves. This also gives the developer the ability to review their work with the project team.

The role of the reviewer is not just about finding bugs or errors in the implementation of the task, but to share knowledge of the evolving system, to provide construstive feedback to developers who are learning about the sytem and to create a shared experience between the team of all aspects of the application being developed.

Once the PR has been approved the developer can merge it into the main branch where a new version is created, it is built, unit tested, deployed to a development environment and end to end tests are run.

The development environment should be a good representation of production and everyone on the project team needs to have access to it.

From here you need to decided if you are going to do Continous Delivery or Continuous Deployment. The differences being that with Continuous Delivery someone needs to manually trigger the deployment of the code to production, while in Continuous Deployment is happens once the all the checks against the development environment have been completed.

There are several different strategies to doing deployments to production such as blue/green or canary. It depeneds upon the type of application being built. The key is that there needs to be an easy way to roll the deployment back to a previously known good state. However, we’ll see in the next section that the use of Feature Flags can greatly reduce the need to rollback the entire release.

Continous Deployment

Deploying when you push to main shouldn’t be a problem. Follow on with these 5 steps to getting to continous deployment and your team will be there in on time.