CI/CD best practices are easy to talk about and hard to implement. For example, teams want to avoid surprises before deploying code but often stop short of introducing centrally managed policies to help protect their repositories. Let’s face it, there are plenty of challenges when defining, setting up, and enforcing policy at scale—especially scaling to hundreds of repositories and thousands of developers.
Reusable workflows introduced the idea of centrally managed workflows for an organization’s repositories. They helped the shareability of workflows but configuring each repository individually didn’t scale and more importantly, didn’t enforce the success of workflow runs.
GitHub has simplified the process of centrally managing workflows. Available today, GitHub Enterprise Cloud customers can require that certain workflows need to run successfully before code can be merged into an organization’s repositories. Earlier this month, we shared that GitHub Actions required workflows would be moving to GitHub repository rulesets. We’re excited to announce that setting up and managing these workflows is now formally part of GitHub repository rulesets. Not only do repository rulesets improve the experience of setting up and managing these workflows but it also allows several other benefits like branch targeting, bypass rules, and dry running rules in an evaluation mode.
Enforcing required workflow runs provides a new level of control to the code being added to your repositories. By requiring workflows via repository rulesets, all pull requests on selected repositories will be blocked until specified workflows run successfully. This easily scales from some to all repositories in the organization regardless of the number of contributors. The level of specificity for the workflow is also configurable—choose a workflow by specific branch, tag, current commit or specific SHA to lock in the exact version of the workflow that’s required. These controls will help save engineering time and effort by enforcing workflow runs on code contributions before they’re merged and deployed.
Requiring workflows from repository rulesets keeps set-up and maintenance for all your rules in a centralized UI. This also means that all additional tools provided by rulesets can be applied to your workflow rule. For example, you can create a bypass list that allows specific users to “break the glass” so they can merge even if the workflow doesn’t succeed. You can also set up and evaluate the potential impact of required workflow policies before enforcing them on repositories. This will allow you to fine tune and test the settings without disrupting the flow of contributors.
Repository Rule Insights are a powerful tool used to evaluate required workflows. When introducing a workflow rule, it’s necessary to make sure things are working properly before enforcing it throughout your repositories. By placing the rule into “Evaluate” mode, the audit reports the results of the rule without blocking downstream repository contributions. Staying in “Evaluate” mode provides the time necessary to evaluate the results of the rule before enforcing it. Once the rule is working as intended, switching from “Evaluate” to “Activate” enforces the rule and prevents any code associated with the workflow from being merged into the repository.
Workflows controlled at the organization level ensure repository contributions adhere to a defined set of automated processes. Defining and enforcing these workflows is now a part of GitHub repository rules, which greatly improves the experience to centrally manage repositories. Now, code contributions are guaranteed to adhere to the CI/CD policies defined by required workflows. Check out our docs to learn more about how to set up and require workflows at the organization level. And don’t forget to join the community discussion about requiring workflows. If you’re reading this on a Friday, don’t worry, set up your required workflows and build confidence in today’s deployments.
Get free virtual tickets to the global developer event for AI, security, and DevEx.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。
