Managed CI/CD

Build pipelines are jobs that run in sequence whenever you deploy new code to an environment. Coherence automatically manages build pipelines for all environments (using CodePipeline/CodeBuild for AWS and Cloud Build for GCP).

If you need to support any external pipelines pre-build, you can easily integrate them with GitHub Actions.

You can also run full stack integration tests across services using preview environments as an additional step in your build pipeline. All that's required is an image of your integration test runner (e.g. cypress/base:12) and the command to start your tests. Learn more.

Build pipeline sequence

1. Provision necessary infrastructure (in the case of a new preview environment, that would include a database, load balancer, and SSL/DNS. See the AWS or GCP information for more details).
2. Push source code to the provider, using cloud storage.
3. Build containers, using cache as much as possible, and push to the registry.
4. Run user defined steps (see below), in order specified.
5. Deploy frontend assets and new web-facing backend containers
6. Deploy any workers or cron tasks
7. Run integration_tests if specified in your top-level configuration. See examples.

User defined backend steps

compile

If your app is written in a compiled language, this step runs before we build your app image in order to generate compiled binaries.

• These will be placed into the repo folder (which is the default working directory of the command) at whatever path your build outputs them, and will be carried forward to subsequent steps (including the build step) where your Dockerfile can pick them up and use them.
• An alternative approach to compiling like this is to use a multi-stage docker build, or to just run as part of your Dockerfile.

test

Defines the image and command used to run tests against this service.

• If the image is blank, we will run using the service's image.
• If both properties are not provided or blank, no test step will be generated in CI/CD.
• If this is an array of commands, we will divide them into up to 10 parallel steps, which can be useful if your test suite gets large and slow. Note that tests automatically get services such as DB/redis automatically injected, just like in workspaces and deployments.

migration

Used to migrate your database schema.

• Runs as a part of each CI pipeline
• If the migration fails, the rest of the pipeline will fail as well.
• See the details on resources for the interaction with snapshot loading, which can be used in place of migration in non-production environments if you configure it to do so.

snapshot

If you provided a snapshot_file_path for your resources, this step will be generated and used to load the snapshot file into the target. See the resources docs for more details on configuring snapshot loading.

seed

Used to place data into the database on workspaces and review environments.

• It should be idempotent, as it will be run on each pipeline execution or workspace creation
• Can be used to run a post-snapshot loading script. One note is that snapshot will only be run until the pipeline succeeds once, while seed will be run on every pipeline if it is present.

If snapshot, seed, or migration are not defined, the relevant steps will not be generated in CI. This is perfectly fine if this is the behavior you'd like.

User defined frontend steps

These commands will be run in the built service container for your frontend service type

build

Defines the command that will output your built static assets (js/css/html) to be served by the CDN from your cloud provider in each environment.

test

Defines the image and command used to run tests against this service.

• If the image is blank, we will run using the service's image.
• If both properties are not provided or blank, no test step will be generated in CI/CD.
• If this is an array of commands, we will divide them into up to 10 parallel steps, which can be useful if your test suite gets large and slow. Note that tests automatically get services such as DB/redis automatically injected, just like in workspaces and deployments.