You Should Use a Live Deploy PR

GitFlow and Trunk-Based Development: A Quick Recap

Before diving into the specifics of using a Live Deploy PR, let’s briefly recap two common branching strategies: Gitflow and trunk-based development.

Gitflow involves multiple long-lived branches like main (or master), develop, and feature branches. In contrast, trunk-based development focuses on maintaining a single main branch where all changes are integrated. The main branch always contains the latest code, which is continuously integrated, tested, and ready for deployment.

The Concept of a Live Branch

To streamline the deployment process and keep track of what’s deployed in your environment, introduce a “live” branch. This branch mirrors the state of the deployed version of your application. Whenever code is deployed, it’s merged into this branch. This approach allows you to easily see what code is currently running in production or any other environment, such as staging or acceptance.

Using a live branch simplifies the deployment process. By defining a specific action (like merging to the live branch), you can automate deployment tasks. This pattern can be extended to multiple environments—simply add a corresponding branch (e.g., staging, acceptance) and adjust the deployment scripts accordingly.

What is a Live Deploy PR?

A Live Deploy PR (Pull Request) is an automated pull request created whenever your main branch and live branch are not in sync. It provides an easy-to-read overview of what changes are ready to be deployed. The Live Deploy PR highlights all the commits and changes that haven’t been deployed yet. This gives developers and stakeholders a clear view of what will go live next.

Benefits of a Live Deploy PR

1. Changelog Visibility
   A Live Deploy PR acts as a changelog for each deployment. It provides a simple way to see what features, bug fixes, or other changes are included in each release, making it easier to track progress and communicate updates.
2. Familiar Deployment Workflow
   Deploys are triggered using the same familiar pull request workflow. This consistency reduces friction and speeds up the deployment process, as developers are already accustomed to using pull requests for code reviews and merges.
3. Code Review and Approval
   By requiring approvals on the Live Deploy PR before merging, you can ensure that multiple developers review the changes. This extra scrutiny helps catch potential issues before they reach production.
4. Automated Testing
   You can configure your CI/CD pipeline to run tests against the Live Deploy PR. This ensures that the changes are thoroughly tested in an environment that closely mirrors production, reducing the risk of deploying buggy or untested code. This is a perfect place for you to trigger tests by QA.tech.

How to Set Up a Live Deploy PR

Setting up a Live Deploy PR can be done easily with GitHub Actions. Here’s a step-by-step guide:

Define the GitHub Action:
Create a workflow file named .github/workflows/create-main-to-live-deploy-pr.yml in your repository. This file will use the mikepenz/release-changelog-builder-action@v3.4.0 action to automatically generate the Live Deploy PR whenever there are changes between your main and live branches.

name: Build Live Deploy PR

on:
  push:
    branches:
      - main

jobs:
  pull-request:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      pull-requests: write
      repository-projects: read
    steps:
      - uses: actions/checkout@v4
      - name: pull-request
        run: |
          gh pr create --head "main" --base "live" --title "Live Deploy" --body "Generating changelog, please hold for github action to finish..." --label "Live Deploy" || true
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
      - name: changelog
        id: build_changelog
        uses: mikepenz/release-changelog-builder-action@v3.4.0
        with:
          # https://github.com/mikepenz/release-changelog-builder-action
          configuration: '.github/templates/release-changelog-builder-action.json'
          fromTag: live
          toTag: main
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
      - name: update-pull-request
        run: |
          gh pr edit main --body "${{ steps.build_changelog.outputs.changelog }}"
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

‍

Create a Template File: Add a template file at .github/templates/release-changelog-builder-action.json. This file defines the structure and content of the changelog that will be included in the Live Deploy PR.

{
  "categories": [
    {
      "title": "## Changelog",
      "labels": ["any"]
    },
    {
      "title": "## Internal",
      "labels": ["internal"]
    }
  ],
  "pr_template": "- #${{NUMBER}} by ${{AUTHOR}}",
  "template": "## Changelog\n${{UNCATEGORIZED}}\n${{CHANGELOG}}",
  "ignore_labels": ["Live Deploy"]
}

‍

3. Enable it
Nothing else is needed. This will be automatically picked up by GitHub, as it will read all files in .github/workflows by default.

The Result

By following these steps, you’ll have an automated process that creates a pull request whenever changes are ready to be deployed from your main branch to your live branch.

The PR provides a clear, concise overview of what changes are included in the next deployment, supports automated testing, and allows for review and approval before deployment. This setup helps maintain a stable, reliable deployment process, improving code quality and reducing the risk of production issues.

Using a Live Deploy PR not only enhances visibility into your deployment pipeline but also aligns with best practices in continuous integration and continuous deployment (CI/CD). It’s a straightforward yet powerful way to ensure your team knows exactly what’s in every release and to maintain high-quality standards across your software development lifecycle.

‍