Release workflows
Every code change passes through the same eight stages, in the same order, with the same evidence. The workflow is the release process model; the tooling that implements it varies by customer.
The standard. A defined release process model that every code change follows, from local checks to post-deployment review.
Tooling
Qbits selects CI/CD tools to fit the customer's stack. Where there is no existing constraint, the default toolchain is:
| Function | Default | Alternatives |
|---|---|---|
| Version control | GitHub | GitLab, Bitbucket |
| Continuous integration | GitHub Actions | Jenkins, GitLab CI |
| Continuous delivery | GitHub Actions | Jenkins, AWS CodePipeline |
| Infrastructure as code | Terraform | CloudFormation, CDK |
| Configuration management | Ansible | Chef, Puppet |
| Static analysis (SAST) | SonarQube | Snyk, CodeQL |
| Dynamic analysis (DAST) | OWASP ZAP | Burp, Invicti |
| Load and performance | Artillery | k6, JMeter |
| Container registry | Amazon ECR | Docker Hub, GHCR |
Tools with large communities are preferred because the customer inherits a sustained stream of updates and security patches rather than depending on a single vendor's support window.
The eight stages
Local development Formatting, linting, unit tests, local build and a pre-commit secret scan. Nothing untested or non-compliant is pushed.
Source The change is a reviewed pull request against a protected branch. Required checks must pass before merge.
Automated test Unit tests re-run, static analysis, dependency and secret scanning, compliance checks. A failure returns the change to development with feedback.
Build Compile and package into a deployable artefact — container image, binary, or AMI. Dependencies are pinned. The artefact is stored in a registry and tagged immutably.
Deploy to staging The artefact — not a rebuild — is deployed to an environment that matches production. Health checks and smoke tests run automatically.
Manual test Load testing at expected peak, performance benchmarking against targets, resilience testing, and dynamic security testing from an external perspective.
Deploy to production Progressive deployment with health-gated traffic shifting. Rollback is triggered by metrics, not by someone noticing.
Post-deployment review Compare observed performance against forecast, review errors and alerts, record what should change in the next release.
Stage detail
1. Local development
| Check | Tool | Blocking |
|---|---|---|
| Format | Language formatter | Yes, via pre-commit |
| Lint | Language linter | Yes |
| Unit tests | Test framework | Yes |
| Local build | Build tool | Yes |
| Secret scan | gitleaks / trufflehog | Yes |
| SAST | SonarQube (local or IDE) | Advisory |
2. Source
The pull request is the unit of change. It carries the description, the linked ticket, the test evidence and the review record. Branch protection ensures the checks are not optional.
3. Automated test
Runs on every push and every pull request.
- Unit tests with coverage reporting.
- Static analysis on changed code, and full-project on merge to a protected branch.
- Dependency vulnerability scan (SCA).
- Secret scan across the full history on first adoption, then on every change.
- License compliance where the customer requires it.
4. Build
The build produces one artefact per commit and promotes that artefact through environments. Rebuilding between environments introduces a difference between what was tested and what was deployed.
commit → image:<git-sha> → staging → production
The image is tagged with the commit SHA and, on release, a semantic version. Tags are immutable; a published tag is never reused.
5. Deploy to staging
Staging is production-shaped: same instance classes, same network topology, same managed-service versions. A staging environment that differs from production tests the difference, not the change.
6. Manual test
| Test | Purpose | Pass criterion |
|---|---|---|
| Load | Verify behaviour at expected peak | p95 within target, error rate below threshold |
| Soak | Verify behaviour over sustained load | No memory growth, no connection exhaustion |
| Resilience | Verify behaviour when a dependency fails | Degrades gracefully, recovers automatically |
| DAST | Verify external attack surface | No high or critical findings |
| UAT | Verify business behaviour | Customer sign-off against acceptance criteria |
7. Deploy to production
Strategy is chosen from Deployment strategies. Whatever the strategy, three properties are required:
- Health-gated. Traffic shifts only after the new version passes health checks.
- Observable. The deployment is visible in a dashboard during the change.
- Reversible. Rollback is a defined action with a target time, not an improvisation.
8. Post-deployment review
Within one working day:
- Did error rate, latency and saturation match the forecast?
- Did any alarm fire, and was it actionable?
- Did the deployment take as long as expected?
- What should be automated or removed before the next release?
Metrics
The workflow is measured, not assumed:
| Metric | Definition |
|---|---|
| Deployment frequency | Production deployments per week |
| Lead time for change | Commit to production |
| Change failure rate | Deployments requiring rollback or hotfix |
| Mean time to restore | Incident detection to service restored |
| Pipeline duration | Commit to deployable artefact |
Teaching the model
The release model is transferred, not just operated. For each customer we run a working session that covers:
- The eight stages and the evidence each produces.
- How to design a release model for their own application — artefact strategy, environment topology, promotion gates.
- How to write the pipeline for their stack, using their repository.
- How to read the pipeline when it fails, and how to change the model safely.
The output is a pipeline the customer's team owns and can modify without us.