Services/DevCycle
< Services
Jump to navigation
Jump to search
Environments for Sync
There are four environments :
- dev: development environment composed of three VM: storage, reg and sreg. The configuration files for this environment can be freely changed. The servers are maintained and modified by the developer.
- sandbox: development environment composed of three VM: storage, reg and sreg. The configuration files are maintained by puppet.
- stage: stage environment composed of three VM: storage, reg and sreg. The configuration files are maintained by puppet and are similar to the sandbox files.
- prod: prod environment.
Continuous integration
- Hudson builds the RPMs in the dev environment on every commit
- Hudson runs the functional tests :
- against the dev environment on every commit
- against the sandbox environment every other hour
- against the stage environment every other hour
- against the production environment once per day
Configuration files visibility and cycle
- developers should be able to view at any time how sandbox, stage or prod is configured in Puppet. For this, the repositories that contains puppet files should be accessible in read-only mode by developers
- Ops should be able to see the configuration files and their default state in each code repository, and ask for upgrades of their initial state.
How Sync is deployed/released
There are two ways to upgrade the Sync servers:
- A regular planned release
- A critical fix release to apply asap
Regular releases
Once we've reached a dev/sandbox/stage/prod stability, we need to do regular releases in time boxes. Every week seems to be a good start.
- every Monday, the developer tags a release for every package when there are changes.
- Ops upgrade stage on Tuesday ask for QA to check it
- Ops upgrade prod on Wednesday
See the Deploying a new version section for more details.
Critical fixes releases
Urgent fixes might be applied by Ops in prod environment, then backported to code for the next regular release.
XXX process TBD
Deploying a new version
- the developer tags each repository using rpm-MAJOR.MINOR-release where release is the rpm release number in the spec file and MAJOR.MINOR the python version.
- the developer deploys the RPMs in the sandbox and validates that it works
- the developer possibly change some configuration files and ask to the Ops to push them in puppet
- once everything works, the developer validates that there are no failures in Hudson against the sandbox environment,then tells the Ops to upgrade the stage environment.