Jan 6, 2024 • 1 min
The problem with the current most commonly accepted way of running code reviews using Pull Requests is that they have the nasty habit of blocking the flow of delivery. They introduce a cost of delay. Any delay reduces feedback. Consequently, it drives down quality.
Jan 6, 2024 • 4 min
During this whole article series - On the Evilness of Feature Branching - I have not mentioned a single time anything evil about feature branching. So, where is the evilness? Is it the problems they introduce? Or the reasons teams use them for? Or the compliance reasons that pushes teams into using feature branches? In all truthfulness, it is none of these. But something else.
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.
Dec 14, 2023 • 5 min
Every time I suggest the adoption of trunk-based development, I always get that one, single, same question asked: What about Code Reviews? How do we do Code Reviews when we do not have branches anymore? Of course, this assumes code reviews can only happen with Pull Requests.
May 2, 2023 • 7 min
The usual way to achieve fast Continuous Code Reviews is through Pair Programming or Ensemble Programming. In this article, I will share a less common approach to Continuous Code Reviews using Non-Blocking Reviews.
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 • 16 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.
Aug 26, 2022 • 1 min
Continuous Integration is by itself already a practice. It is one of the most critical to adopt to enable the fast flow of work through the value stream. However, many teams believe Continuous Integration is just a tooling problem, to then say they practice Continuous Integration.
Jun 14, 2022 • 2 min
Honestly, it feels a bit awkward to still write about Continuous Integration. It has been over 20 years since Kent Beck introduced Continuous Integration in his book Extreme Programming Explained. But, when looking around me, I realise teams and organisations still struggle with adopting Continuous Integration.
Jun 14, 2022 • 5 min
In part 4 of this series - The Problems I dived deep into the problems introduced by feature branching. But, what can we do about this? How can we avoid the problems introduced by feature branching altogether?
May 30, 2022 • 22 min
In part 2 of this series - Why do Teams use Feature Branches? - and part 3 - But Compliance!? I went into all the possible reasons teams mention themselves to why they use feature branches. This time I want to go deeper into the problems introduced by the use of feature branches.
Feb 22, 2022 • 11 min
In part 2 of this series - Why do Teams use Feature Branches? - I examined all the possible reasons teams mention for why they use feature branches. There was, however, one reason, I did not mention that people referenced as the ultimate reason: “We use feature branches and pull requests to comply with regulations”. I would like to explore this and show there are other options to comply that do not have the same drawbacks.
Dec 13, 2021 • 26 min
Why I got interested in micro services? Because from my early days at ThoughtWorks was actually helping people ship software more quickly. I spent lots of time looking at Continuous Integration, Continuous Delivery, cloud automation, infrastructure automation, automated tests, and all these sort of things. And realise that actually it was the architecture of these systems that made it hard to ship software more quickly.
Oct 25, 2021 • 18 min
In part 1 of this series - a Tale of Two Teams - I introduced two quite different teams. One novice team practising trunk-based development, the other experienced but being used by GitFlow. Now I would like to explore why teams use feature branches. What are their reasons? What problems are they trying to solve with long-running branches?
Jul 14, 2021 • 7 min
On the experience of working with two totally different teams: one novice practising trunk-based development, the other very experienced being used by GitFlow.
Apr 26, 2021 • 0 min
Branch creation became very easy with the advent of Distributed Version Control Systems. However, it comes at an unquestionable cost. Long living branches break the flow of the IT delivery process, impacting both stability and throughput.
Mar 23, 2020 • 3 min
There is this commonly accepted, hard-grained belief in the software industry. By dropping a build server in a team, they get Continuous Integration magically for free. This belief is further incentivised by the marketing of build server vendors.
Oct 29, 2016 • 2 min
Feature branching is one of the most commonly accepted practices in the IT industry. It is mainly used to control quality and to control feature delivery. However, many times the inverse is true. Branches break the flow of the IT delivery process, reducing both stability and throughput. Unfortunately, oftentimes teams are not aware of this. They truly think they are doing the right thing.