Fractal-based Development

This elegant branching pattern provides the structure required for disciplined delivery at scale!
Tags:
Categories:

Named for its self-similar complexity at every level of magnification, this branching pattern ensures that code flows through a series of controlled stages, each managed by a dedicated team, before it is authorized for release. The pattern is required for all teams participating in the DevOps Release Convoy, and deviation from the prescribed branching model is treated as a process violation subject to review by the DevOps Usage & Compliance Head Engineer (DOUCHE). Great insights into effective delivery can be gained from studying the structure, and all Code Engineers are expected to have the branching diagram memorized for the DevOps Process Excellence Assessment.

The branching model operates as follows. All feature branches are created by the Source Management Team (SMT) from the clean Develop branch. Code Engineers are not permitted to create their own branches, as uncontrolled branch creation leads to naming inconsistencies, unauthorized experimentation, and branches that do not conform to the required naming convention (CONVOY-[number]-[feature-id]-[engineer-initials]-[date]). Each feature branch must remain isolated from all other changes until the feature is complete, inspected, and certified. This isolation period typically spans the entire coding phase of the Convoy, ensuring that engineers experience the full benefit of working without interference from other engineers’ changes.

When a Code Engineer has completed their work and obtained a Coding Completion Certificate from their Feature Captain, the SMT is notified that the branch is ready for Conflict Arbitration. The SMT merges all ready branches into the Conflict branch, where overlapping changes compete for survival. Once the strongest changes have been selected and the weaker changes eliminated, the SMT notifies the Quality Authority (QA), who pulls the surviving changes into the Test branch for manual certification. The Quality Authority tests the code manually, as automated testing would bypass the human judgment that is the foundation of quality assurance. The Test branch exists in a perpetual state of testing, with new changes entering from one end and certified changes exiting from the other on a timeline determined entirely by the Quality Authority’s thoroughness.

Once the code has been certified by the Quality Authority, it is forwarded to the Development Integrity Assurance Team (DIAT) on the Validation branch. The DIAT’s role is to validate the work of the Quality Authority itself, ensuring that the testers tested correctly and that no defects were overlooked due to testing errors. This layer of meta-testing is essential because testing, like any human activity, is subject to error, and errors in testing are more dangerous than errors in code because they create a false sense of security. If the DIAT approves the code, it is authorized for inclusion in the next DORC™ to set sail.

Branch Lifecycle: Prescribed Stages

1
Branch Provisioning DEVELOP → FEATURE

The Source Management Team (SMT) creates a uniquely named feature branch from the clean Develop branch. Code Engineers submit a Branch Creation Request Form and await provisioning confirmation before commencing work.

2
Isolated Development FEATURE (isolated)

The Code Engineer works within their isolated branch for the full duration of the Coding Ceremony. No synchronization with other branches is permitted. Upon completion, the engineer obtains a Coding Completion Certificate from their Feature Captain.

3
Conflict Arbitration FEATURE → CONFLICT

All certified feature branches are merged by the SMT into the Conflict branch. Overlapping changes are adjudicated via Conflict Arbitration, where the strongest changes survive. Losing changes are archived for compliance purposes.

4
Manual Quality Certification CONFLICT → TEST

Surviving changes are pulled into the Test branch by the Quality Authority (QA) for manual certification. The Test branch exists in a perpetual state of testing; automated testing is prohibited as it bypasses the human judgment foundational to quality assurance.

5
Meta-Validation TEST → VALIDATION

Certified code is forwarded to the Development Integrity Assurance Team (DIAT) on the Validation branch. The DIAT validates that the Quality Authority tested correctly — a critical meta-testing layer that guards against errors in testing itself.

Release Convoy Authorization VALIDATION → DORC™

DIAT-approved code is authorized for inclusion in the next DevOps Release Convoy (DORC™). The code sets sail on the next scheduled convoy departure, coordinated by the SMT.

The complexity of Fractal-based Development is not a weakness but a feature. Each branch, each hand off, and each approval gate represents an opportunity for oversight, and oversight is the mechanism through which quality is built into the delivery process. Organizations that use simpler branching models – trunk-based development, for example – sacrifice these oversight opportunities in exchange for speed. SADMF recognizes that speed without oversight is recklessness, and recklessness is how organizations end up in the Tribunal. The branching model also provides stable employment for the Source Management Team, whose expertise in managing this structure is irreplaceable and whose headcount is justified by the complexity they maintain.

See Also