Source Control & Delivery¶
Good engineering discipline doesn't depend on any particular platform. Our standards for source control, CI/CD, and work management are platform-agnostic — they apply whether we're working in Azure DevOps, GitHub, GitLab, or anything else a client uses.
That said, Azure DevOps (ADO) is our internal default. We use it for CDS's own work and bring it to engagements where the client has no existing preference. If a client is already on a different platform, we work within that ecosystem rather than asking them to change.
Source control¶
We follow trunk-based development across all engagements:
main(ormaster) is the primary branch and is always in a deployable state- Work happens on short-lived feature branches — typically merged within a day or two
- Every merge goes through a pull request with at least one approval
- Branch policies enforce that the build passes before a PR can be merged
Long-lived feature branches are a sign that something has gone wrong — either the work hasn't been broken down small enough, or there's a risk of a painful merge later. We address that at the planning stage, not the branching stage.
CI/CD pipelines¶
Pipelines are defined as code, checked into the repository alongside the application they build. Never configured through a UI that nobody can see or version-control.
Every project has, at minimum:
- A PR pipeline — runs on every pull request: compile, lint, unit tests, and any fast automated checks. A failing PR pipeline blocks the merge.
- A deployment pipeline — triggers on merge to
mainand deploys to the target environment. This is where slower checks run: integration tests, accessibility checks, security scanning.
Pipelines are the enforcement mechanism for quality. If it's important enough to care about, it should be in the pipeline — not a manual checklist.
Work and team management¶
We use a lightweight board-based approach to managing delivery work. The goal is visibility and flow, not process overhead.
A typical board has four columns: Backlog → In Progress → In Review → Done. Work items are small enough that things move through the board within a sprint rather than sitting in one column for weeks. If a ticket has been in progress for more than a few days without moving, that's a signal to the team — not an accepted state.
We run sprints or kanban depending on the nature of the engagement and the client's preference. Sprints work well for structured delivery phases with clear commitments. Kanban works better for support, continuous improvement, or engagements where priorities shift frequently. We don't force a methodology that doesn't fit.
Platform flexibility¶
Our standards above apply regardless of the platform. What changes between platforms is syntax and tooling, not principle.
| Platform | Source control | Pipelines | Boards |
|---|---|---|---|
| Azure DevOps | ADO Repos | ADO Pipelines (YAML) | ADO Boards |
| GitHub | GitHub | GitHub Actions | GitHub Projects |
| GitLab | GitLab | GitLab CI/CD | GitLab Issues |
If a client is on a platform we haven't listed, we'll work within it. The engineering disciplines — trunk-based development, pipeline-as-code, small work items, fast feedback — transfer everywhere.