Deploying to Production and Staging

The production branch of your Git repository is designated production, and a staging branch is designated for staging. Any code merged to those branches will automatically trigger a rebuild of the production and staging environments, respectively, in the Enterprise Cluster. Any defined users or environment variables will also be propagated to the Enterprise Cluster as well.

Note that there is no automatic cloning of data from the Enterprise Cluster to the Development Environment the way there is between branches in the Development Environment. Production data may still be replicated to the Development Environment manually.

The master branch is still available but will have no impact on either the production or staging environments. Deploys of the master branch will not trigger a rebuild of the Enterprise Cluster environments. A common model is to use the master branch as a pre-integration branch before merging code to staging, such as at the end of a sprint.

Deployment philosophy values consistency over availability, acknowledging that it is nearly impossible to have both. The way that the deployment works guarantees that you will never have inconsistent data on production due to ambiguous states caused by sloppy deployment. For example, you will never be running code that is inconsistent with the database schema. You will never be running code on one web server that is different than code on another web server. Such inconsistency is a frequent source of subtle bugs and we stive to avoid those entirely. The cost is 30-90 seconds of application unavailability per deployment.

That brief downtime applies only to changes pushed to the production branch. Deployments to staging or to a development branch have no impact on the production environment and will cause no downtime.

results matching ""

    No results matching ""