Deployment

The deployment process should generally occur across four consecutive stages: development, testing, staging, and production.

Repository Branches

While smaller, simpler projects need not abide by this, larger/long-term projects should adopt a trifecta branching scheme. Each branch corresponds with one of the three deployment environments, making the automated deployment of a given commit easy to understand and follow.

• A feature-name (e.g. 55-add-user-api-endpoint) branch acts as the primary development branch. CI/CD should push commits on this branch to the testing environment (solarix.dev).
  • Some repositories may also use a combined testing branch to merge development features and deploy to the testing environment (solarix.dev).
• staging is the staging branch. CI/CD pushes commits on this branch to the staging environment (solarix.site).
• master is the production branch. CI/CD pushes commits on this branch to the production environment (solarix.host).

Stage 1: Development > Testing

• Developer makes changes in local dev environment.
• Developer commits change.
• Developer pushes change to a new feature-name branch and generates a merge request.
• Upon merge the feature-name branch to testing environment (solarix.dev).

Stage 2: Testing > Staging

• If tests are green from testing then the developer pushes the commit to the staging branch.
• This staging commit deploys to the staging environment (solarix.site).

Stage 3: Staging > Production

• If tests are green from staging then the developer pushes the commit to the production branch.
• This production commit deploys to the production environment (solarix.host).

Exceptions

Some smaller projects may skip one or more of these branches/environments. For example, a project may use solarix.dev for testing and solarix.host for production, but not utilize any staging environment. In other cases, internal projects may solely use solarix.tools.

How Deployments are Executed

See GitLab Runners for more information.