Security, Infrastructure & OperationsInfrastructure
Change and Configuration Management
Build & release pipeline, branch protection, rollback, and configuration management
Changes to the SSM.ro platform follow a controlled, automated process from commit to production, with the ability to roll back quickly.
Build & Release Pipeline
GitHub (main branch, mandatory PR review)
│ webhook on merge
▼
Heroku Build (slug compile, buildpack)
│
▼
Heroku Release (rolling restart of web + worker dynos)
│
▼
Versioned release with one-click rollbackChange Controls
| Control | Description |
|---|---|
| Branch protection | The main branch is protected on GitHub; any change requires a PR with mandatory review |
| Staging testing | Changes are tested in the staging environment before merging into production |
| Automated build | Merging into main automatically triggers build & release on Heroku |
| Versioned release | Each release is versioned and can be inspected |
| Rollback | Revert to a previous release with one click, in under 30 minutes |
These controls address the risk of deployment failure / code integrity (risk #6 in the Risk Register).
Configuration Management
- Secrets and configuration are stored exclusively in Heroku config vars, separated per environment — they are not embedded in the source code (see Secret Management).
- Separate environments — production, staging, and development are isolated, with distinct credentials (see Heroku Architecture).
- Managed infrastructure — the configuration of services (Postgres, Redis, S3) is managed through the providers' consoles, with access protected by mandatory 2FA.
Patching
Security patches for dependencies and the platform are applied following the operational SOP (Backup, DR & Patching, v1.0, 2026-04-29). Details: Scanning and Patch Management.
Maintenance Windows
Planned maintenance work is communicated in advance. Maintenance windows and their impact on the SLA are described canonically in Maintenance Windows.