Published September 29, 2022
by Doug Klugh

Precursor of CI Theatre

Avoid this anti-pattern by managing your code directly on the trunk of your source code repository as opposed to separate (feature) branches.  Branching your code will isolate feature enhancements and defect fixes from other development within your team, which will lengthen the feedback cycle, shift quality assurance to the right, and make code merges more difficult and more costly — all of which are the complete opposite of what a DevOps team should be doing.  While teams often rely on branching to support concurrent feature development, encapsulating those features within feature toggles enables Trunk-Based Development, which further enables Continuous Integration (CI).  Remember...  continuous integration is frequent integration.

The more frequently we integrate our code with everyone else's, the sooner we will discover and recover from integration issues.  The longer that discovery takes, the more difficult and costly it will take to recover.  And lengthening the learning cycle will impede our ability to prevent those problems from reoccurring in the future.

Does your team struggle with code merges?  Then do it more often.  Infrequent code merges means large code merges — making them more difficult, time consuming, and expensive.  Merging your code frequently (multiple time each day) means they will be smaller, with fewer merge conflicts.  And if your code breaks the production build, then you will realize that much sooner, making it easier to fix.

A mature DevOps team will always move quality assurance as close to the source as possible.  Ensuring that decisions are made where the work is performed will not only enhance quality, but will reduce cycle time and promote effective learning.  Problems are always best discovered and resolved where the work is being done, by the people creating the artifacts.

Related Posts