Blend Developer Guide

Two Environment Deployment Process

  • Page Owner: Not Set
  • Last Reviewed: 2025-08-26

Environments‌

This deployment guide is for clients with only two environments:

  • Development / QA / Integration - This environment is for development of new features and bug fixes. It has no uptime guarantees and intended to be the place that breaks first.

    • Clients review new features and bug fixes here.

    • Content should not be entered here except as necessary for testing.

    • At this point, individual tickets may be selected for promotion to the next step.

  • Production - The final environment, public facing site(s).

    • All changes must be reviewed before they hit production.

    • All content entry and maintenance should happen here.

    • Content here may be moved back to the Development environment regularly and as needed. No content from any other environment should be moved here.

Branches

The git repo will have one branch for each environment, and an additional branch for holding Pull Requests.

  • prerelease - Not deployed anywhere. All branches start as Pull Requests to this branch. This is a holding area for changes not yet approved for stage.

  • qa - Deploys to the QA server. Developers can and should merge items out here freely.

  • main - Code that it is in production. Must go through prerelease branch first.

Process

Unfortunately, there are far too many variables and environments to consolidate all deployments to a single process. However, the following is a rough guide to how deployments should work. All deployments should be closely modeled off of this, with minor changes to reflect the specific environment and/or client.

  1. A deployment ticket is created and scheduled. The ticket should include links to all the tickets that are approved for the deployment, and should link all of the approved tickets as "related" tickets (so all tickets and their status are quickly visible).

  2. All tickets to deploy must be merge requests going into the prerelease branch. Each PR should note the associated ticket and should note a post-deployment steps that are necessary. See: Workflow.

  3. Once all the tickets are approved for deployment, the are merged into the prerelease branch. A new merge request is then created for the prerelease branch to go into the main branch. This PR should contain a link to the deployment ticket.

  4. The final release PR is reviewed one last time before deployment. It is approved and merged.

  5. The main branch is then built and the resulting artifact is deployed to main.