So you’ve decided to switch from one branching model to another. Did GitFlow catch your eye? Is it time to tackle feature flags with trunk-based development? No matter which model you choose, switching from one to another can be complicated. Here are 4 pitfalls we’ve seen that we hope you can avoid when you decide to implement a new model.

Pitfall 1: What we’ve got here is… failure to communicate.

A key piece will be trial and error so it is important that your team communicates and documents new knowledge. Start small, learn from mistakes, and share those learnings. Take the smallest repository you have and start there. You might be motivated to tackle your big legacy repository in order to clean things up more quickly, but that will shoot you in the foot later. Perfect the change on a practice repository, one that has fairly simple code supported by a small team. It’s helpful if your repository has high test coverage, but if not then take some time to add some basic tests. Build, Measure, Learn. Everything should be small: commits, pull requests, tasks, and classes. This will allow your team to make mistakes, update your procedures and documentation, and improve the overall flow. Next, they communicate that to the rest of the team and work on more challenging repositories.

Pitfall 2: I find your lack of faith disturbing

Confidence is of the utmost importance when using a new branching model. The team should have clear, living, up-to-date documentation about the branching model and how it is used within the company. Since the team relies on the branching model to prevent bad code from entering production, they need to know that they are doing it correctly. For instance, with trunk-based development, they need a total mind shift to focus on keeping the trunk stable and deployable. Knowing what to do when the build fails should be documented. Do they need to alert anyone in that case? By having a documented crisis plan in place, they will feel more confident in the new approach.

Pitfall 3: You think that kind of automation is easy?

When it comes to testing, it should be automatic. This is generally achieved via a combination of end-to-end tests and unit tests. Ensure your codebase has enough tests supporting it. The pipeline itself should also be automated. Remove the chance for human error. The pipeline should check for stability and deployability. Bonus, this is a great foundation for expanding the functionality of your build pipeline and doing things like implementing automatic security patches and code formatting.

Pitfall 4: Do you feel alone right now?

The engineering team needs to be supported at all levels of the company. Mistakes might occur when updating a procedure as important as this. If some issues occur on the way to a better future, the team needs to feel safe that they won’t be blamed when trying to make an improvement. By securing buy-in throughout the organization, the psychological safety of the team will be protected. It might seem that you are adopting a new way of engineering to release software, but instead, you are adopting a new mindset, one that must permeate through the entire organization. True agility comes from the entire company pushing responsibility down to the lowest levels and creating space for teams to learn and adapt in order to solve the problems they encounter. This is known as Direct Responsible Individual. But this only works if the teams are given responsibility along with the means to handle that responsibility. The budget, team, space to try and fail, along with other resources must be present. By taking on this challenge, not only will you avoid the pitfalls I’ve mentioned above, but you’ll be able to handle pretty much everything else. So what are you waiting for?