{"id":69851,"date":"2023-02-02T10:03:36","date_gmt":"2023-02-02T18:03:36","guid":{"rendered":"https:\/\/github.blog\/?p=69851"},"modified":"2023-02-03T05:53:53","modified_gmt":"2023-02-03T13:53:53","slug":"enabling-branch-deployments-through-issueops-with-github-actions","status":"publish","type":"post","link":"https:\/\/github.blog\/engineering\/engineering-principles\/enabling-branch-deployments-through-issueops-with-github-actions\/","title":{"rendered":"Enabling branch deployments through IssueOps with GitHub Actions"},"content":{"rendered":"

At GitHub, the branch deploy model is ubiquitous and it is the standard way we ship code to production, and it has been for years. We released details about how we perform branch deployments with ChatOps all the way back in 2015<\/a>.<\/p>\n

We are able to use ChatOps to perform branch deployments for most of our repositories, but there are a few situations where ChatOps simply won’t work for us. What if developers want to leverage branch deployments but don’t have a full ChatOps stack integrated with their repositories? We wanted to set out to find a way for all developers to be able to take advantage of branch deployments with ease, right from their GitHub repository, and so the branch-deploy Action was born!<\/p>\n

\"Gif<\/p>\n

How Does GitHub use this Action?<\/span><\/a><\/h2>\n

GitHub primarily uses ChatOps with Hubot<\/a> to facilitate branch deployments where we can. If ChatOps isn’t an option, we use this branch-deploy Action instead. The majority of our use cases include Infrastructure as Code (IaC) repositories where we use Terraform to deploy infrastructure changes. GitHub uses this Action in many internal repositories and so does npm<\/a>. There are also many other public, open source, and corporate organizations adopting this Action, as well, to help ship their code to production!<\/p>\n

Understanding the branch deploy model<\/span><\/a><\/h2>\n

Before we dive into the branch-deploy Action, let’s first understand what the branch deploy model is and why it is so useful.<\/p>\n

To really understand the branch deploy model, let’s first take a look at a traditional deploy \u2192 merge<\/strong> model. It goes like this:<\/p>\n

    \n
  1. Create a branch.<\/li>\n
  2. Add commits to your branch.<\/li>\n
  3. Open a pull request.<\/li>\n
  4. Gather feedback plus peer reviews.<\/li>\n
  5. Merge your branch.<\/li>\n
  6. A deployment starts from the main<\/code> branch.<\/li>\n<\/ol>\n

    \n\"Diagram
    <\/div>\n

    Now, let’s take a look at the branch deploy<\/strong> model:<\/p>\n

      \n
    1. Create a branch.<\/li>\n
    2. Add commits to your branch.<\/li>\n
    3. Open a pull request.<\/li>\n
    4. Gather feedback plus peer reviews.<\/li>\n
    5. Deploy your change.<\/li>\n
    6. Validate.<\/li>\n
    7. Merge your branch to the main<\/code> \/ master<\/code> branch. <\/li>\n<\/ol>\n

      \n\"Diagram
      <\/div>\n

      The merge deploy model is inherently riskier because the main<\/code> branch is never truly a stable branch. If a deployment fails, or we need to roll back, we follow the entire process again to roll back our changes. However, in the branch deploy model, the main<\/code> branch is always in a “good” state and we can deploy it at any time to revert the deployment from a branch deploy. In the branch deploy model, we only merge our changes into main<\/code> once the branch has been successfully deployed and validated.<\/p>\n

      Note: this is sometimes referred to as the GitHub flow<\/a>.<\/em><\/p>\n

      Key concepts<\/span><\/a><\/h3>\n

      Key concepts of the branch deploy model:<\/p>\n