Putting “Continuous” back into Continuous Integration

As a Scrum coach I work with a lot of teams who build software products and one trend I’ve noticed is the conflation of 2 separate yet linked concepts: Continuous Integration and Continuous Delivery/Deployment. Generally, this is just shortened to CICD and are infrequently separated. I’ll address the CD half in another post, with the focus here being on CI.

Continuous Integration is an overstatement of the eXtreme Programming (XP) rule Integrate Often which advises to communicate code changes to your team frequently. This doesn’t nessesarily mean continuous as this would imply an asymtotic limit of real time. Think of it like the difference between a continuous function and a discrete function.

On the left we have a continuous function, x can take any numerical value while on the right, the discrete function is limited to specific values. It isn’t a stretch therefore to say that the notion of continuous integration is ever satisfied, there will always be a lag between code written and code integrated with the team. The goal therefore is to establish an intent which will never be reached, yet directionally speaking, moves a team adopting this practice towards techniques and reduce the pain associated with integrating at pace.

I encourage you to think about what Continuous Integration means to your team in these terms rather than assuming a build server is what you need.