The End of CI

Today, Continuous Integration (CI) is something that nearly every engineering organization does. However, I predict that in the future, nobody will do it.

CI is the process of integrating different changes from each developer into the main development branch. CI is often triggered by creating a pull request to merge a branch into main. Therein lies the problem.

First, CI rarely knows what has changed, so everything needs to be rebuilt and retested. We found solutions: recreate the dependency graph in specialized CI scripts or painstakingly use a verbose declarative build system. Unfortunately, neither is tenable for most engineering organizations.

Next, CI is a post-commit workflow. How often have you or a coworker pushed an empty commit to "re-trigger" the CI? As I wrote in Your Integration Tests are Too Long, developers become reliant on CI and won't run the tests until merge time.

Workflows are shifting left.

Continuous integration is anything but continuous. Changes might be integrated once a day, or more likely, once a feature is ready. Tight feedback loops are the lifeblood of engineering organizations, and developers want to integrate early and often. Running tests pre-commit is one answer. Yet, roadblocks today need to be fixed, like tests that don't fit on your laptop.

The reason why it's so hard to see a world without CI is how blinded we've become with version control workflows. Today, a developer would be crazy to suggest anything other than git and trunk-based development for a project. But all technology evolves, and git is already showing its weaknesses. Fork-and-pull isn't the final form of development workflows.

I predict the answer is something even more continuous than continuous integration. It might look like real-time integration of your changes, collaborative editing, or smarter build systems that produce near-live feedback. I, for one, hope that we aren't using Jenkins in 2025.