Configuration

coherence.yml

Just like every other devops/infrastructure tool, we have a .yml file we're looking for inside each repo you connect to Coherence.

  • By default the file is called coherence.yml and should be placed at the root of your repo. If you would like to call the file something else, or change its path, let us know and we can configure it for you.
  • It is possible to have multiple configs per repo, to support a monorepo

With this file, you'll configure Coherence to:

  • Provision full-stack branch preview environments and Staging/Production environments for gitops across all your services - with support for any application that can be containerized.
  • CI/CD Pipelines with build, test, and deploy steps - using first party managed cloud provided tools such as GCP Cloud Build or AWS CodePipeline.
    • Supports compiled languages such as Java or go seamlessly.
    • Parallelized test steps for increased performance.
    • Integrated database seeding and migrations.
  • Hosted cloud IDE and cloud shell for each environment

Routing and Domains

Services in one Coherence application are deployed behind a shared load balancer and domain, and use path-based routing to determine the service that will receive traffic for the request.

  • Each environment (Staging/Production/Branch Previews or Cloud IDE) creates its own deployment with a unique URL
  • Services in the same application will deploy from the same pipeline, with backend services deploying before frontend services.
  • Within an application, frontend services can use relative paths to access backend services. No special logic is needed to know the api url in an application with a frontend and backend in the same yml for example.
  • If you require distinct lifecycles for your services, seperate repos for your services, or unique domains per service (e.g. app.mysite.com and api.mysite.com) then you can use multiple coherence.yml files, and therefore create multiple applications.
    • Each application's Workspaces will be unique. You can reference another application's services using one of the deployed environments in this scenario, for example the staging environment for a backend from Workspace for an application that is only a frontend.
    • Applications can refer to services from other applications using their URLs, which can for example be configured based on Environment Variables. If in the same repo, regex logic based on branch name and subbing the application name in Coherence-generated URLs can be useful.
    • If both applications are in the same repo, their deployment lifecycles for push-based deploys are coupled by the github webhooks. Manual deploys will still require action in both application's UI's in Coherence.
    • Applications each incur fixed costs for cloud resources such as VPC resources.

Sample coherence.yml Example

Here is an example coherence.yml that uses all of the supported settings. See more examples here.

frontend:
  type: frontend
  index_file_name: index.html
  url_path: /
  repo_path: frontend
  assets_path: build
  local_packages: ["node_modules"]
  build: ["yarn", "build"]
  test:
    - ["foo", "bar"]
    - ["lint", "1"]
  dev:
    command: ["yarn", "dev"]
  cors:
    allowed_origins: ["www.example.com"]

  system:
    dev:
      cpu: 2
      memory: 4G

backend:
  type: backend
  url_path: /api
  repo_path: backend
  migration: ["migration", "command"]
  seed: ["seed", "command"]
  dev: 
    command: ["run", "command"]
    dockerfile: "Dockerfile.dev"
  test:
    - ["foo", "bar"]
    - ["foo", "baz"]
  prod:
    command: ["run", "command"]
    dockerfile: "Dockerfile.prod"
  compile:
    image: "foo/bar:1.2.3"
    command: ["foo", "bar"]
    entrypoint: "foo"

  workers:
  - name: dev_workspace
     command: ["worker", "dev", "command"]
  - name: default queue worker 1
     command: ["worker", "command"]
  - name: default queue worker 2
    command: ["worker", "command"]

  scheduled_tasks:
  - name: task 1
    command: [“sleep”]
    schedule: "* * * * *"

  resources:
  - name: db1
    engine: postgres
    version: 13
    type: database
  - name: redis
    engine: redis
    version: 4
    type: cache
  - name: test_bucket
    type: object_storage
    cors:
      - allowed_methods: ["GET", "POST", "PUT", "DELETE"]
        allowed_origins: ["www.example.com"]
      - allowed_methods: ["GET"]
        allowed_origins: ["*"]

  system:
    memory: 2G
    cpu: 1

build_settings:
  platform_settings:
    machine_type: "N1_HIGHCPU_8"

integration_test:
  type: integration_test
  command: ["cypress", "run", "--record"]
  image: "cypress/included:9.4.1"

preview_inactivity_timeout_hours: 72

For all services

Pausing Preview Environments

The top-level configuration value preview_inactivity_timeout_hours will configure how long Coherence should keep features active before pausing them. When paused, database instances will be preserved but all other infrastrucutre will be removed. Activity is judged from the most recent push to the branch (regardless of the resulting build status or success). Pushing a new build to a paused feature will-reactive it and re-provision the infrastructure. The status can also be updated in the dashboard at any time. The default is currenly 90 days.

Integration Testing

name_of_your_integration_tests:
  type: integration_test
  command: ["cypress", "run", "--record"]
  image: "cypress/included:9.4.1"
  • You can run integration tests as part of your build process in Google Cloud Build or CodePipeline on AWS.
  • Include your integration tests as a top level block along with your application's services with a type of integration_test
  • Include the image of your test container, a command to run it, and we will include your tests as a build step.
  • Any environment configuration variables that your tests need (CYPRESS_RECORD_KEY, for example) can be set using our config UI in Coherence.
  • COHERENCE_BASE_URL will be set as an environment variable that describes the url of the Coherence environment you are running in. Your tests can make requests to this url.

Build Settings

backend:
  build_settings:
    platform_settings:
      machine_type: "N1_HIGHCPU_8"

GCP

You can set the platform_settings property for machine_type using the values here for Google Cloud Build to configure the machine type for CI pipelines generated by Coherence.

AWS

You can set the platform_settings property for machine_type using the values here for CodeBuild to configure the machine type for CI pipelines generated by Coherence.

Previous
Config Checker
Next
Services