Set up Multi-Job Pipelines in GitHub Actions with Required Review for Deployments in Specific Environments

When it comes to deploying applications, particularly to production, control is not just a preference—it’s a necessity. A deployment pipeline that incorporates mandatory reviews can act as a safeguard against unvetted changes, ensuring that every release meets the quality and security standards expected in a production environment.

Deployment Environments and Required Reviews

Understanding Deployment Environments

Deployment environments, such as staging and production, serve as isolated contexts where code is run or deployed. These are not just logical separations but can be configured to enforce specific rules and gates.

Setting Up Environments

First, we’ll need to define our environments in GitHub Actions. Here’s how you can set up a staging and a production environment:

1. Navigate to your GitHub repository settings.
2. Click on 'Environments' on the left sidebar.
3. Add a new environment by naming it (e.g., staging or production).

Configuring Review Rules

Once your environments are established, you can enforce rules, such as required reviews. This is done as follows:

1. Select the environment (e.g., production) to configure.
2. In the Protection rules section, enable Required reviewers.
3. Add the GitHub users or teams that must review deployments. Remember, up to six reviewers can be specified per environment.
4. To prevent self-review, ensure the option 'Prevent self-review' is checked.

Pipeline Configuration

Creating Multi-Job Workflows

Multi-job workflows in GitHub Actions allow you to orchestrate several jobs that can run sequentially or in parallel. In our case, we want a job to deploy to production to be dependent on a prior review stage.

Here’s an example snippet of a job definition that will pause for review before deploying to production:

Deploy-Prod:
    name: 'Deploy to Azure'
    needs: Deploy-WhatIf
    runs-on: ubuntu-latest
    environment: production

In the above YAML:

• needs: Specifies that this job will not start until Deploy-WhatIf completes successfully.
• runs-on: Defines the type of runner that will execute the job.
• environment: Specifies the environment to which this job will deploy.

To see the full pipeline configuration, check out the source code on GitHub:

Think-Alike/.github/workflows/build-and-deploy-prod.yml at main · Latzox/Think-Alike

Think Alike is a nodejs web application. The game offers an exciting twist to classic word games. Designed for multiplayer interactions, it features real-time gameplay where players enter a virtual…

GitHubLatzox

Workflow Execution and the Review Process

The Review Gate

When a deployment job that targets an environment with required reviews is initiated, the workflow will pause. Here’s what happens:

• A notification is sent to the designated reviewers.
• The deployment will not proceed until all necessary reviews are approved.
• If the deployment is rejected by any reviewer, the workflow will fail, and the code will not be deployed.

Proceeding After Review

Once approvals are in place:

1. The workflow resumes.
2. The deployment job runs, safely releasing your changes to the target environment.

The Benefits of Controlled Deployments

By setting up multi-job pipelines with environment-specific review gates, you're implementing a robust workflow that:

• Enhances Security: Reduces the risk of unapproved changes affecting your production environment.
• Increases Accountability: Creates a clear record of who approved the deployment.
• Improves Quality: Ensures that changes have been reviewed and tested by relevant stakeholders.

Remember, the goal of this approach is not to add red tape but to ensure that every deployment is deliberate, tested, and reviewed—key components of a mature DevOps process.