CI/CD

The available steps for backend and frontend services for your application differ.

Build Ordering

The order of a build is:

• Prior to starting the pipeline, Coherence will make sure that the cloud infrastructure is up to date so the deployment will succeed, for example adding a database for a new preview environment, configuring a load balancer or SSL/DNS. See the AWS or GCP information for more details.
• Push the source code to the provider, using cloud storage.
• Build containers, using cache as much as possible, and push to the registry.
• Run the steps you provide below, in order specified below in these docs.
• Deploy frontend assets and new web-facing backend containers
• Deploy any workers or cron tasks
• Run integration_tests if specified in your top-level configuration. See here for some examples.

Any steps above not specified below for each service type, are automatically provided by Coherence in your CI/CD configuration.

Backend Service Pipelines

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.

• It runs at workspace startup as well 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.

Frontend Service Pipelines

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.