Nov 3, 2024 • 8 min
So we implemented Continuous Integration. It gives us the confidence to deliver – great! Though, we are in a suboptimal situation. We do not yet have all the benefits that Continuous Integration should provide. How can we get the most out of it? Which additional practices are we missing and should we acquire? How can we raise the bar?
Nov 1, 2024 • 6 min
We read about Continuous Integration. The practice appeals to us. We understand its value and benefits, especially as it unlocks our ability to release confidently anytime. But, where to start? Many teams believe Continuous Integration is just a tooling problem, declaring they practice Continuous Integration. Although, they often do not. Hence, they miss out on the benefits that come along with it. It takes more than only tooling. So, again, where should we start? After all, there are still 20 practices to implement. Which ones to pick first?
Oct 29, 2024 • 5 min
One key principle for continuous improvement is feedback. To create feedback loops, we need to relay information. In the case of Continuous Integration, this requires Broadcasting the Codebase’s Health. But feedback alone is not enough. Teams have to act upon feedback, and for this, teams have to be empowered.
Oct 19, 2024 • 5 min
When tests occasionally fail because they are flaky, we can not rely on the tests any more to identify a good release candidate. At that point, we lose the codebase health monitoring. The benefits of Continuous Integration fall flat. On-demand production releases are jeopardised.
Oct 17, 2024 • 3 min
One precondition of being in a state of Continuous Integration is to fix a broken build within ten minutes. As long as the build is broken, the team cannot perform on-demand production releases. This irrevocably incapacitates the organisation to make money.
Oct 15, 2024 • 4 min
Continuous Integration is a practice that ensures always working software on mainline and gives us feedback within minutes as whether a change broke the application or not. To guarantee that the mainline is in a releasable state at all times, we need to verify every single commit. Therefore, every push to a remote mainline triggers an automated build and execution of all the automated tests.
Sep 16, 2024 • 4 min
As long as we have not pushed our local commits to the remote Mainline, the integration did not happen. We do not know whether our changes broke the application or not. No communication regarding our local changes happened with the rest of the team. Admittedly, the rest of the team is blind to our local changes. We are not working as a team but in isolation. Consequently, it is critical to push our local commits at least once a day into the remote Mainline to achieve Continuous Integration.
Sep 15, 2024 • 6 min
To accomplish Agree as a Team to Never Break the Build we have to Run a Local Build and Commit Only on Green. To know we can Commit on Green after Running the Local Build, we must Make the Build Self-Testing. Agree as a Team to Never Break the Build is a cornerstone of Continuous Integration. As a consequence, Making the Build Self-Testing is a necessary condition to realise Continuous Integration.
Dec 30, 2023 • 7 min
Months ago, I made the observation that engineers seem to enjoy administrative tasks seeing how much affection they show for the Pull Request. Malik reacted to this with “Show me a different process that guarantees a green mainline”. Manifestly, the answer to that is: Agree as a Team to Never Break the Build. To this, Malik replied: “‘agreeing to never break the build’ is like agreeing to never produce a bug… It’s nonsensical, why not prevent the issue in the first place instead of playing a blame game where the developer is bound to fail at some point?”. In all honesty, I appreciate Malik. We do not often agree online. But we are somehow aligned on the outcomes, i.e. have a green mainline. We just use different techniques to get there. Having said that, I decidedly disagree with Malik.
Mar 12, 2023 • 5 min
Recently, as a reaction to the Practices that make Continuous Integration, someone suggested on LinkedIn the Pull Request based approach without formal reviews could supersede Agree as a Team to Never Break the Build. The benefit would be it removes the need to rely on team agreements to avoid broken builds. Now they would be guaranteed by the Pull Request build. As attractive as this looks, it ignores everything that emanates from Agree as a Team to Never Break the Build.
Sep 28, 2022 • 16 min
In part 1 - Team Working for Continuous Integration we looked into the team practices that make Continuous Integration. In part 2 - Coding for Continuous Integration we explored the engineering practices for Continuous Integration. In this last part, we investigate the required practices for a team to succeed with Continuous Integration, i.e. which are the building practices and how to improve builds to support the team practices - especially Agree as a Team to Never Break the Build - and the coding practices - in particular Make Changes in Small Increments and Commit Frequently.
Sep 25, 2022 • 17 min
In part 1 - Team Working for Continuous Integration we looked at all the necessary practices to achieve team work around Continuous Integration. Now, we investigate the critical engineering practices individuals, pairs or ensembles should adopt to attain Continuous Integration as a team.
Sep 17, 2022 • 10 min
This first part of this series investigates the practices that enable teamwork that in turn enable Continuous Integration. Continuous Integration is a Team Practice. We achieve it as a team and not as a set of individuals. Most of the time, practices are defined for individuals. When most team members apply them, the team does well. However, with Continuous Integration, most team members have to implement other practices before the team can say they practice Continuous Integration.
Oct 2, 2018 • 17 min
In this post, Leena interviews Thierry de Pauw, a Software Engineer who coaches on Continuous Delivery and other Software Engineering Practices. His focus is helping teams to improve the flow of software delivery.