Reference

Feature

Coherence makes three different kinds of environments available to your team. Features are one of the three.

  • Workspaces: Fully integrated, hosted, Cloud IDE's
  • Features, or Preview Environments: also known as Review Environments, Previews, Branch Previews, Branch Environments
  • Static Environments: staging and production are the most clear examples of static environments. These are not linked to a branch, and deploy based on either manual actions or continuous deployment automation logic

By default, 2 environments will be created when you onboard to Coherence:

  • A Feature will be created for your default branch, which you define in the first step of the application creation flow. A Feature includes a Preview Environment, as well as being a container for any Workspaces used to edit the git branch that the feature is linked to.
    • Your default branch on Coherence is not the same thing as your default branch on github.
      • The github default branch remains the base branch for new branches that you create, including on Coherence.
      • The Coherence default feature is a special kind of Feature that cannot be deleted or closed, and which is used during onboarding the generate the initial infrastructure deployed to your cloud account.
  • A Static Environment called Staging will also be created. If you don't plan to use this kind of environment in your workflow, you can delete it on the Environments tab.

Preview Environments are an integral part of the Coherence developer experience. Popularized for the frontend by Platform-as-a-Service tools like Vercel and Netlify, and for full-stack apps by Heroku Review Apps, Coherence now makes the same thing possible in your own cloud systems, without forcing you to glue them together yourself.

Where do Preview Environments (Features) Deploy To?

Coherence supports 2 types of Accounts (AWS) or Projects (GCP). One is used for production, and one is used for non-production. The account that you configure during your initial onboarding will be used for non-production workloads. You will configure your production account later on, after you've gotten your app running with Coherence.

Preview Environments are deployed to your non-production account.

What Resources do Preview Environments Deploy?

Each Account (AWS) or Project (GCP) will deploy some resources that are shared by all environments, and some resources that are deployed for each environment. A few notable call-outs:

Universal

  • VPC, Load Balancer, and Redis are shared by all environments

GCP

  • One Cloud SQL instance per resource definition is shared by all Preview Environments, each environment gets its own database on the instance
  • One Cloud Run service per Coherence service per environment.
  • User defined GCS buckets are provisioned on a per-environment basis

AWS

  • One RDS instance per resource definition per environment
  • One CloudFront distribution per environment per domain
    • Coherence assigns a subdomain from coherencesites.com by default
    • Any custom domains also provision a distribution
  • User defined S3 buckets and SQS message queues are provisioned on a per-environment basis

Feature Lifecycle

Features are the concept on Coherence that determine if a Preview Environment is available and deployed, or not. Features have several stages in their lifecycle.

  • Active: this is the default initial status for a feature. This means that the cloud infrastructure for this environment is provisioned and if there has been at least one successful build, the environment should be available on the web at the URL on the environment defined within the feature's detail page.
  • Paused: after a configurable number of hours (defined with preview_inactivity_timeout_hours in coherence.yml) without a new build, a feature will be moved from active to paused and the infrastructure (excluding the database or database instance) will be removed from your cloud infrastructure. The next push to the branch, or a manual change to the status in the Coherence UI, will move the feature back into active status and re-provision the infrastructure. This is designed as a cost-savings measure for teams with long-lived branches and an intermittent need to test using the preview environment of the feature.
  • Archived: This status mean that the infrastructure, including that database or database instance, is deleted. The next push to any branch linked to the feature, will not have any effect on the feature status - manual action in the Coherence UI is required to change it to active or paused. Merging a PR and deleting the underlying git branch will automatically move a feature from active or paused to archived.
Previous
Collection