DXP Deployment Process

Environments

Every client should have 3 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 stage.

• Preproduction / Staging - This environment is for final testing and approval of bundles of changes before they are promoted to production.

  • Final review and site scans happen here.

  • Content should not be entered here unless absolutely necessary.

  • Content from production should be brought back to this environment on a regular basis (once a month or every two months, and ad-hoc as needed)

  • At this point, the entire bundle of tickets is either all approved or reverted. We cannot promote individual tickets at this stage.

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

  • All changes must be reviewed a final time once they hit production.

  • All content entry and maintenance should happen here.

  • Content here may be moved back to either Preproduction or Development environments regularly and as needed. No content from any other environment should be moved here.‌

Some clients only have Development and Production. These clients are becoming rarer.‌

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.

• stage - Code that is in the Preproduction / Staging environment. Items must go through the prerelease branch first and be approved by the client before going into this branch.

• main - Code that it is in production. Must go through stage 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 new branch is created for the item being worked. For example, issue/57001-fix-null or feature/nav-rebuild.

   • It is branched off main

   • main can be freely merged into this branch

   • This branch can be merged into qa when it is ready to be reviewed.

2. A Pull Request is created for the branch to merge into prerelease. The PR is assigned to the appropriate developer.

   • The PR can be approved, but will not be merged until the changes are approved by the client for the staging environment.

3. Once a set of branches are approved on the qa server and bundled up in a deployment ticket, the corresponding PRs are approved into prerelease and a new PR is created into stage. It is approved and the changes deploy to preproduction/stage.

4. Once the changes are approved on preproduction/stage, a new PR is created for stage into main. The PR is merged and the changes in the stage environment are promoted to production.‌

Variations‌

In some legacy environments, we don't have a Preproduction/Staging environment. In those cases, changes are deployed directly to production. Generally DevOps will build the release artifact automatically, but the final deployment of that artifact must be approved.

In some environments, code does not live on the Stage server for very long (hours at most). In these cases, we may skip the `stage` branch entirely, and move code direction to the `main` branch to go to the stage environment, and then the production environment very shortly after.