- Private Build: Individual / Task
- Integration Build: Team / Project
- QA/CM Release Build: Organizational / Program
- Customer Release Build: Everybody else (business customer, portfolio investor, etc.)
One way for development to build trust with the CM organization is to engage CM up front and elicit "stories" about what "trust" means to them for handoffs from development to CM. What are their biggest complaints/concerns about "trusting" development? Do they fear development will:
- Break the build if they do their own integration/merging and "commits"
- Hand off a build that is not reproducible and reliable?
- Use/create unstable developmental builds that are inconsistent, incorrect, incomplete, or incoherent?
- Neglect to create named stable baselevels at appropriate times
- Monopolize the build servers/resources and software licenses that CM needs to use
- If developers use the SCM Patterns of Private Build, Task-Level Commit, and passing all the automated tests, will that eliminate the fear of development breaking the build? If not, what else? Do they need a way to be sure that these are actually followed?
- If there is an automated build that development systematically uses to reliably ensure that a sandbox environment and build-time options/flags are "sufficiently comparable" to what CM uses, will that eliminate fears of inconsistency and unreliability of the build and its reproducibility?
- If there are business requirements to be able to support multiple releases or (customer special" variations), many agilists/extremists may not want to hear this, but they must learn to respect it as both a business requirement and a CM concern. Then they must learn the requirements to be met so that a solution can be proposed (which might be different from the solution CM had been assuming should be used)
Once these stories are gathered, fears have been expressed, and needs have been elaborated, then development (with CM's assistance) should develop a systematic mechanism for automating and reliably reproducing such "trustworthy builds" and codelines.
What might be some comparable sorts of concerns and solutions for building trust with V&V, or Systems Engineering?