Version Control and Secure Rollback
Ensuring reversibility and traceability is essential to reduce the impact of failures in production. This document defines the recommended practices for version control, reliable rollback and the preparation of secure releases.
📂 Versioning as a pillar of security
- Use semantic versioning (
vX.Y.Z) with a clear meaning:X= breaking changeY= new functionalityZ= fixes / hotfixes
- Associate each release with:
- Commit hash or Git tag
- Deployment date and time
- Environment and scope
- Release owner
🔗 There must be a 1:1 relationship between version, binary and validation documentation
🔄 Rollback: not an exception, a plan
Rollback must be planned as part of each release.
| Rollback type | Description | Example |
|---|---|---|
| Binary | Revert the artefact to the previous version | Previous Git tag |
| Configuration | Change feature flags / environment variables | Toggle off |
| Database | Revert the migration or use automatic rollback | Flyway, Liquibase |
| Infrastructure | Restore the previous state of resources | Terraform rollback, snapshots |
Requirements:
- Rollback must be automatic or documented
- Tested in staging before go-live
- Linked to rollback events in the logging system
🚫 Anti-patterns to avoid
- Releases without a Git tag or verifiable hash
- Multiple artefacts with the same version number
- Untested / manual rollback
- Migrations with no possible reversal
- Changing production configuration manually and without a record
🌐 Tools and good practices
| Objective | Tool / Practice |
|---|---|
| Git versioning | git tag, git describe, git hash-object |
| Idempotent build | Hash included in the artefact, via the pipeline |
| Infra rollback | Terraform, Helm + helm rollback |
| Reversible migration | Reverse SQL scripts, Flyway undo, Liquibase rollback |
| Release audit | Logging, CI/CD dashboards, audit trail |
🔀 Integration with the application lifecycle
- Define rollback as a formal step in release planning
- Include rollback tests in the QA/staging environments
- Document the rollback in the functional changelog
- Associate releases with tickets, justifications and technical owners
✅ Version control and rollback checklist
- Is there a Git tag for the published version?
- Is the artefact signed and uniquely identified?
- Is there a documented and tested rollback plan?
- Can the migrations be reverted automatically?
- Was the rollback validated before go-live?
- Are the configuration changes versioned?
📊 These points are essential to maintain resilience and confidence in sensitive execution environments.