Change management
Every production change to Sally goes through the same tracked path: recorded, risk-assessed, tested, approved by a second pair of eyes, deployed in a controlled window, verified after go-live, and reversible. The programme aligns with ISO 27001 control A.8.32 (Change Management).
What we cover as a "change"
Backend and frontend code, infrastructure and cloud resources, databases and storage, security and configuration components, integrations and third-party interfaces, deployments and releases, and changes to operational or support processes with technical impact.
The seven principles
The release cadence
- Weekly rollout every Saturday. The full system is rolled out on a fixed weekly rhythm.
- Mid-week fixes and small updates. Bug fixes and minor adjustments can additionally deploy during the week.
- Off-hours deployment. Mid-week deployments run in the evening or at night to minimise disruption.
- Critical exceptions. In critical exceptional cases, deployments can also happen outside these windows.
Pre-go-live testing
Every production change goes through the same checklist:
- Two manual functional tests. One by the developer, one by an independent tester.
- Automated end-to-end tests. Core user flows are covered: account creation, login, onboarding, calendar integration, account deletion, and further central process paths.
- Domain- and technical review. A targeted review of the change in the context of the affected components.
Deployment and verification
Deployments run through Azure DevOps. After go-live we check that the affected functions work, that no obvious follow-on errors surface, that the platform stays stable and reachable, and that no security or data protection side-effects are visible.
Emergency changes
Security-critical fixes, severe defects and acute production incidents follow an accelerated path. The principle of controlled execution still applies: documentation, follow-up review and approval confirmation happen immediately after the emergency change.