Build Engineers

YAML experts who ensure Code Engineers never waste time on build concerns and can focus entirely on feature delivery!

Build Engineers are the specialized practitioners who own the entire build pipeline, from the first line of YAML to the final artifact. In organizations that lack this role, Code Engineers are forced to maintain their own build configurations, leading to inconsistency, tribal knowledge, and the dangerous illusion that developers understand their own build systems. SADMF eliminates this risk by centralizing all build ownership under a dedicated team whose sole purpose is to write, maintain, and enforce the YAML that transforms source code into deployable artifacts. Code Engineers submit requests to the Build Engineers when they need build changes, and the Build Engineers evaluate, prioritize, and implement those changes according to the build roadmap established by the Admiral’s Transformation Office.

The Canonical Build Definition

The Build Engineers are responsible for maintaining the Canonical Build Definition, a single authoritative YAML file (or, more commonly, a hierarchy of 40-60 YAML files) that defines every step of the build process for every application in the organization. The Canonical Build Definition is stored in a dedicated repository managed by the Source Management Team, and changes to it follow the same Fractal-based Development branching pattern as application code. This ensures that build changes receive the same level of scrutiny as feature code, passing through the Code Standards Enforcement Team (CSET) for review and the Change Rejection or Acceptance Party (CRAP) for approval. Build changes that are approved are merged into the Conflict branch by the Source Management Team and included in the next Convoy.

Build Change Requests

The separation between Build Engineers and Code Engineers is a cornerstone of SADMF’s commitment to Systems Thinking. When a Code Engineer updates a dependency, adds a new module, or changes a compilation flag, they do not modify the build configuration themselves. Instead, they file a Build Change Request (BCR) with the Build Engineering team, specifying what they need and why. The Build Engineers then:

  1. Evaluate the BCR against the Canonical Build Definition.
  2. Assess the impact on other applications that share build components.
  3. Schedule the change for implementation.

This process typically adds 3-5 business days to the development cycle, but this delay is a feature, not a flaw: it ensures that build changes are deliberate, documented, and coordinated across the enterprise rather than made impulsively by individual Code Engineers who cannot see the full picture.

Environment Provisioning

Build Engineers also execute the Standardized Environment Provisioning practice, maintaining the 200-step SEPAW checklist that ensures every environment is configured identically. When a Feature Team requires a new environment for testing or development, they submit a request to the Build Engineers, who provision the environment manually according to the checklist. The manual nature of this process is intentional: automated provisioning scripts can contain bugs, but a human following a checklist will catch discrepancies that a script would silently propagate. Each provisioned environment is signed off by the Build Engineer who created it and countersigned by the Development Integrity Assurance Team (DIAT) before it is released for use.

Reporting and Metrics

The Build Engineering team reports to:

Their performance is measured by the Feature Completion Ratio, ensuring that build reliability is tracked as rigorously as feature delivery. Build Engineers who achieve consistently high scores on the DevOps Process Excellence Assessment may be nominated for the SADMF Certified Build Architect credential, recognizing their mastery of YAML and their commitment to centralized build ownership.

See Also