I remember officially switching my professional career from being a Linux system administrator to a Python software engineer. It was ten years ago when I decided that rebooting servers was dull. Watching the software engineering team working next to me, seeing them doing
git commit -a -m 'friday night commit' && git push after a week-long coding session without a line of tests, gave me the confidence I needed to fulfill my destiny.
I couldn't do worse.
It was 2011, and the software industry was seeing a new trend rising. Steadily, we began to hear more about terms like continuous integration and continuous deployment. The name Jenkins kept coming to my ears. Travis CI was set up. CircleCI was founded.
The rise of the CI began.
A Decade of Testing
Years later, it is interesting to see where that trend brought the industry. It evolved the engineering practice for the better, and nobody wants to go back to where we came from.
For any project, the standard ten years ago was to have a few unit tests you could run on your desktop computer. The developer would check essential pieces of the code.
Nothing would be automated. You could pull the latest version of the software, run the tests locally and observe that the newest commit broke the program without anyone noticing.
Slowly, the CI movement transformed build-bots into testing engines that would run an entire test suite after a developer pushed code. At least this time, we would know someone broke the code.
The pull request model that GitHub brought to the table allowed us to improve the model further. Testing could be done on each change before merging them, making sure it was not easy to break the main branch without being aware of it.
Year after year, software engineering teams worldwide consolidated their testing and brought confidence into their development efforts. They would run coverage tools to expand their testing quality, protecting every code path. They would build whole stacks of integration testing, increasing their testing quantity.
Having a large amount of automated testing run before any change is pushed on production systems is now the gold standard. Having talked with tens of engineering teams those last months, we also know not every team is equal. Some squads are stuck running their tests manually, while others have a fully automated workflow that guarantees nothing is broken.
I doubt there's any need to clarify the impulse behind the surge of testing and continuous integration we've seen. Just in case, understand that a high return over investment drives CI adoption.
Having your software engineering team rolling back blindly to previous versions, spending hours tracking the source of an issue is a waste. Not only does it cost time, but it also drains your engineering team's energy. Having the two steps forward, one step back dance ruins any project.
The same applies to deployments, which are also becoming fully automated once code has landed. Using manual procedures is a source of errors and frustration while streamlining the process allows a team to deploy multiple times per day.
The Next Decade
The trend around automating the software development workflow will continue its progression in the next ten years. The interests from automation compound at a high rate and give software companies a competitive advantage and better margins than their contenders.
CI usage will increase, and many companies still lagging years behind will have to catch up or disappear.
The most advanced companies in this field are already showing what the future will look like. The best software engineering teams are fastening their seat belts. They are increasing their productivity by securing, even more, their workflow, allowing them never to have to look back. They are empowering their developers with new tools to avoid whole classes of issues or fix them earlier in the development process.
The Big Tech and other large software companies already have dedicated developer efficiency teams building the next-generation tools to boost their software engineering team.
Not every company can afford this. They don't have the expertise nor want the burden of maintaining their automation stack.
Mergify thrives in this space, bridging the gaps between automation, continuous integration, and developer efficiency. We are gathering the knowledge from thousands of the best engineering teams and building what we think is going to be a game-changer in this area.
If you thought the continuous integration dust has settled, you will be surprised.
What We Predict
It is now obvious to us that merge queues are the next best thing to happen. Major software companies are now using those queues to make their code merge safer and control their pipeline. It is the next logical step for quality assurance after continuous integration and testing. We're seeing the trend growing every month, with new engineering squads jumping on the wagon. With the most complete merge queue solution out there, Mergify is currently in a good place to see this trend happening.
Full automation, such as automatic merge will also gain traction. GitHub started to caught up on this trend last year with their release of the auto-merge feature. While a nice first step, it's actually far from being flexible enough for most teams. Many teams are knocking on Mergify's door to bring this feature to the next level with a finer-grained control — and it works.
That think those are the first steps of a change that will transform the industry practice. We hope to be right: stay tuned for our prediction retrospective in 2031. 😉