Continuous Integration, Automation and Deployment are all closely related.
The CI script for a given repository will:
- Run tests.
- Check and gate quality.
- Build the code into a deliverable package, usually a Docker image, and distributing it.
- Trigger deployments to
This must be configured for every repository, but most will follow the same pattern.
CI should trigger unit tests on every commit to any branch:
- On feature branches to demonstrate that each is is ready to merge to
- On every merge to the
developbranch to demonstrate that all merged feature branches continue to function.
- On every merge to
masterso that we know that a tagged deployment is ready to ship.
The CI environment should spin up any needed services to run tests. Any secrets, even for transient containers, should be stored in the repo’s secret storage, not in the CI file.
Checking and gating quality
The build should break when the branch isn’t in a deployable state. This will prevent it from being merged or deployed until it’s ready.
- Any failed tests should break the build.
- Code coverage should be exported from test runs and included in the SONAR report.
- SONAR should be triggered for feature, develop and master branches.
- If the SONAR quality gate is not met (static analysis of code coverage) the build should break.
Building and distributing images
- Images should be built from the CI pipeline for the
masterbranches, and for tags.
- Images should be pushed into the GitLab Docker repository for easy retrieval by developers.
- Images should also be pushed into the AWS Docker repository for deployment in AWS.
There are three AWS environments:
develop, automatically deployed from the
staging, automatically deployed from the
production, automatically deployed on every tag on the
They contain three parallel instances of the Crossref AWS system, with the same services and infrastructure. These are defined in separate Terraform files which span across services. CI automation deployment will deploy to each of these environments.
As part of the work of setting up a new ECS Service, that service’s ECS Service Definition will have been created. The CI pipeline for a service will include a deployment step which will update the ECS Task definition and kick off the new version of the service.