You cannot ship quality once a month!

Photo by Greg Rakozy on Unsplash

You cannot ship quality once a month!

Introduction

In the world of software engineering, Continuous Delivery (CD) serves as a cornerstone for delivering software that is reliable, robust, and fast. However, to truly capitalize on what CD has to offer, it's imperative to understand its underlying principles and how different workflows like GitFlow and GitHub Flow can either aid or hinder the CD process.

Core Principles of Continuous Delivery

CD stands on the following key principles:

  1. Build Quality In: Quality should be inherent at every stage of development.

  2. Work in Small Batches: Small, frequent changes are preferred over large, infrequent ones.

  3. Computers Perform Repetitive Tasks, People Solve Problems: Automation is key for repetitive tasks, while humans handle complexities.

  4. Relentlessly Pursue Continuous Improvement: Always strive to improve the development process.

  5. Everyone is Responsible: Collective responsibility for the success of the software is crucial.

The Problem of the "Bogus CD"

Many organizations claim to practice CD but diverge from its fundamental principles.

Continuous Delivery, is not when teams release 100s of features once a month..

This pseudo-adoption often leads to inefficient practices and overlooks the true potential of CD.

GitFlow vs GitHub Flow

GitFlow

GitFlow is a branching model that incorporates different branches for features, releases, and hotfixes. It's a rigid workflow that requires developers to follow specific steps for each kind of change.

Pros:

  • Clear separation of concerns

  • Easy to manage hotfixes

Cons:

  • Complex and rigid structure

  • Inherent delays due to multiple branches

  • Promotes infrequent releases

GitHub Flow

GitHub Flow simplifies the process. Generally, there is one 'main' branch, and all work is done through short-lived feature branches that get merged back into the main branch after review.

Pros:

  • Simple and easy to understand

  • Promotes frequent releases

  • Compatible with the principles of CD

Cons:

  • Might require sophisticated testing setups for large projects

  • Less explicit structure can be confusing for some teams

Why GitFlow is the Enemy of CD

GitFlow, with its complex branching strategy and emphasis on staged releases, often conflicts with the core principles of CD for several reasons:

It is against Fast, Frequent Releases

GitFlow's multi-branch setup adds overhead and complexity, making rapid and frequent releases more challenging. CD, on the other hand, thrives on quick iterations.

Complexity Over Simplicity

The very nature of GitFlow introduces multiple points of potential failure and delays, contradicting CD’s emphasis on simplicity and efficiency.

Impedes Emergency Releases

In a real-world emergency requiring an immediate release, GitFlow's structured approach can slow down the delivery, defeating the principle of being always releasable in CD.

Emphasizing Small and Frequent Releases

Working in small batches aligns perfectly with CD. It reduces risk, speeds up the feedback loop, makes troubleshooting easier, improves quality, and provides the flexibility to handle unplanned changes.

The Ultimate Goal: Main Branch Development

While GitHub Flow takes a significant step towards aligning with CD, Trunk Based Development (TBD) takes this alignment to the next level. In TBD, all developers work in short-lived branches or directly in the trunk, which ensures that code changes are integrated into the main codebase quickly, usually several times a day.

The Stratospheric Advantages

Rapid Integration

Frequent integrations mean that merge conflicts are less likely, and if they do occur, they are trivial to resolve.

Lower Risk

The risk associated with each release diminishes as changes are smaller and more frequent.

Instant Feedback

Developers receive immediate feedback from automated tests, making it easier to identify and rectify issues promptly.

Promotes Strong Engineering Practices

TBD encourages best practices like feature flagging, allowing teams to hide incomplete features from users while still integrating the code changes.

Drives Excellence

When implemented correctly, TBD can be the epitome of software craftsmanship, reflecting a team's commitment to quality and excellence.

The Starry Path

For teams that can truly adopt TBD, they're not just shooting for the moon; they're aiming for the stars. The practice inherently drives teams to mature rapidly, fostering a culture of discipline, skill, and collaborative problem-solving. It's not just about speed; it's about doing things right and efficiently.

Conclusion

While both GitFlow and GitHub Flow have their merits and downsides, GitHub Flow is inherently more aligned with the principles of Continuous Delivery. The practice of CD goes beyond mere tooling to become an engineering discipline that requires deep understanding and commitment. Trunk Based Development can be seen as the zenith of engineering practices. It not only aligns but elevates the principles of CD, paving the way for unprecedented levels of efficiency, quality, and team collaboration. For teams that can fully adapt to this model, the sky is no longer the limit; the endless expanse of space is their new frontier, filled with the stars of excellence, quality, and continual progress. By choosing a workflow that aligns with CD, teams can not only improve the quality of their products but also enjoy a more streamlined and efficient development process.

Did you find this article valuable?

Support Adrian Kodja by becoming a sponsor. Any amount is appreciated!