Release Process
Croud Tech software components must transition through Integration, Staging/Preview, Pre-Live, Environments prior to being deployed in Production.
https://croudcontrol.atlassian.net/wiki/spaces/DEVOPS/pages/25329665/Feature+Delivery
Configuration Management
Configuration of all CroudTech resources is fully managed via Git code repositories - this is broken into two categories:
Infrastructure
Configuration of all AWS hosting infrastructure and services is managed using https://www.terraform.io/. This provides a fully audited change history and reliable change management capability over the infrastructure via a set of version controlled TOML files.
Environments (those denoted by * are not yet managed via Terraform)
Production CroudControl Infrastructure
PreLive CroudControl Infrastructure
Production Tools Infrastructure *
Staging Environment Infrastructure *
Preview Environment Infrastructure *
Integration Environment Infrastructure *
The infrastructure management system is responsible for provisioning all AWS resources necessary to supply one or more Rancher servers that will host any CroudTech applications.
Application
Run-time configuration of all CroudTech applications is managed using Rancher (1.6). This provides a fully audited change history and reliable change management capability over all CroudTech applications via a set of version controlled YAML files.
Integration/Staging/Preview Environments
Application configuration for these environments in stored in the repository below:
https://github.com/CroudTech/devops-rancher-stacks-dev (Local/Integration/Staging/Preview Environments)
Each commit in that repository represents a snapshot of the entire environment as a collection of Rancher stack files, Git diff is used to manage promotion of releases between environments.
Pre-Live/Production Environments
Application configuration for Pre-Live and Production configuration files are subject to access controls - contact devops@croud.co.uk
The versioning strategy follows SemVer
Application Versions
Application versions are created using a continuous delivery pipeline service based on Drone. Every commit to a Git repository will trigger a build. A build consists of a series of pipeline steps executed in order, these typically follow the sequence below.
VCS clone
Run Tests
Determine which of subsequent steps should execute
Build Tagged Docker images
Auto Deploy Docker image to Integration environment
Notify DevOps team of results
Application versions (Tagged Docker images) can be built in one of two ways
Tag Triggers - The relevant Git repository is tagged in the appropriate format
Commit Message Triggers - A commit is made to the relevant Git repository where the commit message contains a string in the appropriate format
| Environment | Overview | Commit Message Trigger | Tag Trigger |
|---|---|---|---|
| Integration | Builds are delivered directly to integration environments via commit messages containing [integration]. This allows the integration environment to serve as a bleeding edge deployment to aid development and provide quick demos (internal only). | [integration] | N/A |
| Staging | Staging releases are formal, pre-RC software which is undergoing feature testing or other QA activity. These types of releases are not permitted beyond Staging. | [staging] | 1.0.2-beta-2 |
| Preview/Pre-live | These are generally RC releases and are versioned accordingly. | N/A | 2.0.3-rc1 |
| Live | This is a shipped version of software. | N/A | 3.0.2 |
Deployment
Once an application version (Tagged Docker image) is created, it can be deployed to any environment via a simple command line process. Details are provided in the mark down of the relevant Git repository.