06 / 07Deploy
Reviewed changes. Reproducible environments. Controlled deployments and recovery paths.
Deploy is the path a change takes from a developer to your production system. We keep that path in Git, reviewed and reproducible.
- Review
- Build
- Deploy
- Observe
Services map
When you need it
- Changes are made directly in production, and nobody can say what changed last week.
- A fix works in testing and fails in production, because the two environments differ.
- One person holds the only knowledge of how to deploy.
- After a bad release there is no agreed way back.
- A new CTO or an auditor asks who approved a change, and there is no record.
Platform
Deploy.
A new report, a repaired integration, a version upgrade: each change has to arrive in production without disturbing what already works.
A Git repository holds the desired state of the system: the code, the configuration and the description of the environments. Every change is reviewed there, and the environments are built from it.
The result is an environment that can be reproduced, not one that somebody has to remember.
What we do
- GitOps: Git as the source of desired state, with changes reviewed before they are merged.
- Reproducible environments for development, staging and production.
- CI/CD for build and deployment.
- Controlled deployments, with a recovery path.
- Containers, and Kubernetes where it is the right fit.
- Observability, so the effect of a release is visible.
How it connects
When a change goes live is a business decision. A release in the middle of month-end closing or the busiest shipping week is a risk nobody needs. So the timing belongs to the people who run those areas. The areas are on the Odoo page.
Changes made on the application layer travel this path. A customization comes from Build & customize, an integration from Connect, a workflow from Automate, a new version from Migrate & upgrade.
On the platform layer, the environments a change is deployed to are operated in Run. A system where changes have long been made by hand in production is a case for Rescue.
When you need it
- Changes are made directly in production, and nobody can say what changed last week.
- A fix works in testing and fails in production, because the two environments differ.
- One person holds the only knowledge of how to deploy.
- After a bad release there is no agreed way back.
- A new CTO or an auditor asks who approved a change, and there is no record.
Tell us how a change reaches your production today.