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.

Shorten the Feedback Cycle

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.

Merge Frequently

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.

Shift Left

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

assistant Development Tip

Trunk-Based Development

Embrace continuous delivery by frequently integrating small batches of work directly into the source control trunk (at least once daily).  Short-lived branches can be used to implement pull requests or to isolate release candidates, but should never persist longer than a day.  Utilize Feature Toggles to turn off features that are not yet ready for release.  Pull the Andon Cord and...  Read More

by Doug Klugh , September 2019

assistant Development Tip

Feature Toggles

Decouple feature releases from code deployments by encapsulating features and infrastructure changes inside switchable software modules.  Facilitate continuous delivery by deploying code with isolated features that can be released on-demand, enable A/B testing, support operations with automated circuit breakers and kill switches, and...  Read More

by Doug Klugh , January 2021

assistant Development Tip

CI Theatre

Avoid CI Theatre by applying the fundamental practices of Continuous Integration (CI), along with supporting engineering principles, to achieve a mature DevOps Model for continuous software delivery.  Precursors of CI Theatre include large user stories, difficult code merges, lengthy code reviews, poor test coverage, long-lived branches, siloed code ownership, broken builds for more than several minutes, and...  Read More

by Doug Klugh , October 2019

assistant Development Tip

Shift Left

Escalate the value of software systems by focusing on quality as far left within the Software Development Lifecycle (SDLC) as possible.  By creating quality at the source, we can identify problems as they occur, build new knowledge, and optimize for downstream work centers.  Quick feedback will promote quality and reliability within our value streams.  The sooner we identify defects,...  Read More

by Doug Klugh , July 2020