What is CI?

The conventional meaning of continuous integration (CI) is a system that runs all tests and checks of every branch pushed to a central repositoryWhatisCI . When the tests and checks pass on some designated main branch, that branch is deployed to production.

This enables a common workflow, as outlined in the figure below. This workflow allows developers to create branches with proposed changes and have bin/ci execute those on the CI server to make sure all tests and checks pass. The team can do code reviews as necessary. When both bin/ci and code reviews are good, the change can be merged onto the main branch for deployment. The bin/ci command is run yet again to make sure the merged codebase passes all tests and checks, and if it does, the change is deployed to production.

This is a sustainable workflow, and we daresay it’s not terribly new or controversial. What we want to talk about is how to make sure this process continues to be sustainable.

CI configuration should be explicit and managed

There are two main problems that happen with using CI:

• The first is that the test suite becomes so long that developers start skipping it in order to deploy.
• The second is that when CI fails even though the code is working properly, it can require an unwelcome diversion to fix the CI configuration to make the tests pass.

Both of these problems can be fixed by having an explicit CI configuration, and a commitment to manage it like any other part of the app.

Many services that provide continuous integration for developers have slick, zero-configuration onboarding. Particularly if we’re using Rails, services like Circle CI and CodeShip can automatically set everything up for us and run our tests without any configuration.

This is not sustainable. Eventually, we’ll run into a problem with the implicit configuration and have to debug it. This will be difficult and will happen when we aren’t planning for it. Our experience in this situation is that teams provide a quick-fix solution to unblock themselves and never go back to think deeply about how CI is configured and set up. This ensures the cycle repeats itself whenever it is least convenient for us and our team.

Fortunately, most CI services allow us to configure exactly what we want to happen, including the version of our database, the port it’s running on, and anything else we might need. The CI service providers don’t tell us about this upfront because it can feel daunting. But explicit configuration is sustainable.