Switching from these tools to GitHub Enterprise Cloud and GitHub Actions has become easier, safer, and even more seamless, with today’s launch of new migration tools.

GitHub Enterprise Importer (GEI) now supports migrations from Bitbucket Server and Bitbucket Data Center to GitHub Enterprise Cloud, and GitHub Actions Importer now allows you to move from any of Atlassian’s CI/CD products–Bitbucket, Bamboo Server, and Bamboo Data Center–to GitHub Actions.

A complex landscape

Companies across the globe rely on DevOps to fuel growth and drive innovation. However, the developer tech stack has become more complicated with countless tools that don’t always integrate easily or work together, resulting in a disjointed experience and operational overhead. And despite industry-wide investments in DevOps, developers report that the most time-consuming thing they’re doing at work besides writing code is waiting on builds and tests. Concerns regarding data security and the risks associated with coordinating workflows across numerous tools are often raised.

Navigating this intricate landscape has become increasingly challenging. Investing in the developer experience can not only result in four to five times more revenue growth, but having a single, integrated platform allows for developers to spend their time doing what they do best—building great software and making an impact.

GitHub is that single, integrated platform, used by over 100 million developers. With built-in integrations and APIs, GitHub Enterprise Cloud features enterprise-ready, scalable CI/CD deployment automation with GitHub Actions, collaboration tools, natively-embedded application security testing, and the industry’s first AI-pair programmer, GitHub Copilot.

Migrating your data has never been easier

If you’re making the move to GitHub, we know you’ll have data you want to bring with you so your team can hit the ground running. We also know that fear of migration can be a big barrier to switching, which is why we’ve worked hard to make moving quick, low cost, and painless.

GitHub Enterprise Importer is our tried and tested migration tool, used by thousands of GitHub customers to migrate more than 700,000 repositories to the GitHub platform.

Today, we’re launching support for migrations from Bitbucket Server and Bitbucket Data Center, allowing you to seamlessly bring your code, pull requests, reviews, and comments to GitHub Enterprise Cloud.

To migrate a repository, all you need to do is install our extension for the GitHub CLI and then run the gh bbs2gh migrate-repo command. For more details, and to learn about our tools for planning your migration and moving large numbers of repositories, see “Migrating repositories from Bitbucket Server to GitHub Enterprise Cloud” in the GitHub Docs.

Bring your CI/CD pipelines with your data

In addition to moving your repositories to GitHub with GitHub Enterprise Importer, you can also move your CI/CD pipelines to GitHub Actions with GitHub Actions Importer—a migration tool that helps you plan, forecast, and automate your CI migrations. In addition to BitBucket and Bamboo, GitHub Actions Importer already supports migrations from Azure DevOps, CircleCI, GitLab, Jenkins, and Travis CI.

GitHub Actions Importer is especially designed to help organizations when manual migration is not feasible. For organizations with large and sophisticated infrastructure, CI migrations are often a manual and time-intensive endeavor. GitHub Actions Importer speeds up this process while minimizing cost and the potential for error. In fact, since its inception, GitHub Actions Importer has helped thousands of users evaluate and test the migration of nearly a quarter million pipelines.

GitHub Actions Importer uses a phased approach to simplify the migration process:

1. Planning. In this phase, you analyze your existing CI/CD usage to build a roadmap for your migration.
2. Testing. Here you conduct dry-run migrations to validate that the converted workflows function the same as existing pipelines. GitHub Actions Importer supports unlimited iterations in this step to ensure any custom behavior is accurately encapsulated in your new GitHub Actions workflows.
3. Migration. In this last phase, GitHub Actions Importer generates validated workflows and opens pull requests to add them to your GitHub repository. To finalize your migration, you should plan to review these workflows and migrate those constructs that could not be migrated automatically.

To get started, head to our documentation or explore Importer Labs, our learning environment with tutorials for each supported migration path.

Get started today

With GitHub Enterprise Importer and GitHub Actions Importer’s new support for migrations from Atlassian’s DevOps tools, it’s easier than ever to switch to the GitHub platform.

Want to learn more about GitHub Enterprise? Get in touch with our sales team—we’ll be happy to help.

The post Switching from Bitbucket Server and Bamboo to GitHub just got easier appeared first on The GitHub Blog.

But this change goes beyond technology implementation and touches how we work as software engineering teams. In some cases, it has caused us to adopt new internal processes, work more iteratively with our customers and ultimately, think in a different mindset. As an industry, we’re transitioning away from shipping products to shipping services.

In this blog, we explore how this impacts software engineering teams and end users and how you can set yourself up for success on your service-led journey.

The role of a developer has evolved

The role of a developer has drastically changed, whether you’re comparing that over the last 10, 20, 30 years or beyond—most recently, with the disruption of AI and Large Language Models (LLMs), cloud computing, the internet, mainframes, graphical user interfaces, and more. Developers have been evolving and refining their development practices throughout these evolutions to keep up to date with the latest technologies and paradigms.

Diving into some of these evolutions further:

• Working with multiple programming languages and frameworks.With cloud computing and microservices, individual engineering teams are empowered to choose the most appropriate programming language, framework and platform for their needs.
• Infrastructure-as-code (IaC). Cloud has provided APIs access to manage and configure the underlying infrastructure that our teams build upon. Scaling infrastructure to deal with unexpected spikes or spinning up a deployment stamp in another region has never been easier.
• Increased consumer expectations. Imagine if your favorite shopping app was unavailable. What would you do? You’d probably complete your purchase elsewhere, and may even switch loyalty. Those expectations translate into enhanced engineering requirements, such as Service Level Agreements (SLAs), Recovery Time/Point Objectives (RTOs/RPOs), fast page loads and more, which add additional engineering complexity and pressure for our teams.

Throughout these evolutions, there is a subtle underlying expectation that I haven’t explicitly called out. The lines between development, testing, operations and similar begin to blur. This isn’t surprising, as this is one of the critical premises of a DevOps cultural transformation, removing silos, and focusing on delivering value for your customers.

This means that many of our engineers are likely cross-skilling and learning areas outside their areas of expertise. Developers are learning more about infrastructure as code and networking concepts. Operations teams are learning more about the applications and design patterns being adopted. This is before we even consider platforms like Kubernetes, where the responsibilities are further intertwined.

This is different to several years ago, where software engineering teams would ship approved application versions to users on discs (take your choice of CD or floppy disk). Product teams would prioritize the most critical features, while customer feature requests may have to wait for a later product release, months, or even years later. The cadence and pace of releases were also slower compared to now.

One example is Microsoft’s transition from Office as a boxed product to Office 365. This has also translated to subscription-based payments and customer-focused models, where updates are shipped frequently and quality is essential in continuously delighting customers, and delivering value in the platform.

But this change doesn’t happen overnight and is a journey. The DevOps transformation you’ve likely already embarked on is a vital part of that. Let’s identify some of the common challenges and strategies to overcome them.

Navigating the change: challenges and strategies

We’ve covered some of those strategies and challenges in our introduction, so let’s examine them more explicitly.

Shipping more frequently, safely

One of the promises of DevOps is to break down barriers across teams. This leads to a mindset where the engineering team thinks about the application holistically rather than application versus infrastructure. This subtle change already shifts the perspective away from product development. The team now takes end-to-end accountability for the build, testing and release to customers, shifting the focus to the customer’s experience rather than the internal friction and product development viewpoint.

Automation is commonly adopted to enable this change, particularly in Continuous Integration (CI) and Continuous Delivery (CD).

CI allows you to regularly check that the code compiles successfully and that the project passes some tests.

Have you started writing code, only to find that it does not compile? Or, perhaps you’ve written a new method, but found other parts of the codebase are not passing their tests?

Building a robust CI process helps you gain confidence in the quality of the software that you’re creating. CD then allows you to automate the release of that application to your target environments, and progress those towards production.

Have you ever accidentally executed a script against a production environment intended for dev? How about manually publishing a new release, to find that you have incorrectly configured the environment? Or, attempting to diagnose why the application will not deploy to your environment after following your internally documented steps?

CD allows you to remove the overhead that can slow down a release of the software to your users. Most importantly, the potential for error-prone human intervention is reduced, and a consistent release process enables more releases.

As organizations gain confidence in their processes, they may begin shipping directly to production. For example, an engineering team might ship versions of their product to the engineering organization and use that in their day-to-day work. Critically, if the application has flaws, it will impact the engineering team’s productivity. Therefore, standards need to be followed, and a level of quality needs to be baked into the process.

Bring quality into everything that you do

Quality can mean many different things, and entirely depends on where you are in your transformation:

• Does the code compile?
• Does the code successfully pass your tests?
• Does the code pass a certain level of code coverage?

But we can consider a wide variety of checks:

• Is the user interface accessible for all users (for example, screen readers, high contrast, and similar)?
• Does the application scale to our expectations?
• Does the application respond in an expected timeframe (for example, less than a certain number of milliseconds)?
• Is the application as reliable as we expect it to be? What happens if a core service fails?
• Are there vulnerable code paths in the code that we have written?
• Are we relying upon vulnerable dependencies in our project?
• Have we accidentally leaked secrets, which risks continuity of our ongoing services?

This is where several of the puzzle pieces start coming together. Cloud and IaC allow us to create new environments on demand as part of our automated processes. With that, we can begin bringing scalability tests, performance tests, chaos tests, accessibility tests and more to a running instance of our service, configured in a like-for-like environment to production.

That way, we’re no longer hypothesizing whether the application can scale. Instead, we’re able to deploy a version of the application, and simulate the expected scenarios.

However, these checks should not first occur on builds/releases from our production codebase. Ideally, we should be bringing many of these checks earlier into our development flow, checking for quality in a pull request before we merge to the main branch.

Customer-focused development, not product-focused

So far, we’ve been on a journey. Building automation and quality into everything we do so we can frequently deliver updated product versions to our customers.

But as we ship more frequently and move towards a cloud deployment model, our customers’ expectations shift. Depending on the service, downtime may be unacceptable. Similarly, customers may expect transactions to be completed within a given time or that the application meets specific accessibility standards.

The most important part here is the customer, and understanding what is most important to them. From a business perspective, this is important for several reasons:

• You must be perceived as bringing value to a prospective customer to attract new users. Therefore, if your application is hard to use, slow, and does not meet their needs, they will be unlikely to choose you over a competitor.
• In a service model, organizations typically pay for access through subscriptions. These subscriptions are recurring payments (potentially monthly or annual), meaning it’s vital to continually demonstrate value. If you don’t, you risk customer churn to competitors.

Rather than believing we know what customers want, we must know what they want by building feedback loops into our platforms, building communities with our top users, and, ultimately, using their feedback to prioritize our backlog.

Continuous learning and improvement

As I’ve outlined, running these services can come with high expectations. Depending on your size, scale, or even the types of customers, you may have a high set of availability targets to reach.

When things go wrong, it’s okay to demonstrate continuous learning, identify areas for improvement, and remediate it for the future. When something goes wrong, conduct a blameless retrospective. The idea is not to find who to blame, but to discover the root cause of the problem and determine how automation, refined processes, additional tests, and more can be adopted to prevent similar issues from happening in the future. Treat each failure as an opportunity to learn and improve.

Much like the functional requirements I’ve alluded to throughout the process (specific platform features), non-functional requirements should also be considered on our backlog. Communicating with transparency and with your customers in mind is vital. What have you identified? What are you going to do about it? And how are you going to improve it in the future?

From strategies to action

We’ve talked through how the industry has transformed, and the strategies that can overcome the potential challenges which may arise. But how do we put this into practice?

Implement CI/CD

Consider your current development practices:

• Have you prevented manual/human error-prone issues from taking place? Manual tasks, whether typing the incorrect configuration value or dragging and dropping deployment files, can quickly go wrong.
• Are there enough quality checks in place today? You are aiming to provide an exceptional experience to your customers. Are you including checks and balances within the development lifecycle to deliver on that? As challenges and live site issues arise, are you adding those to the backlog to prevent future repercussions?
• Is your production codebase always in a shippable state? Are you preventing your engineering teams from directly committing to the production codebase? In other words, have you implemented branch protection rules or repository rules to ensure changes are made through pull requests? This will allow you to run some of these checks earlier in your development process, preventing issues from ever reaching the production codebase.

If you’ve answered ‘yes’ to all three questions, then you’re progressing along the right lines! Investing in automation will help bring consistency and rigor to your deployment lifecycle.

‘Everything’ as code

‘Code’ has historically referred to application code. But now, we can create our infrastructure and CI/CD workflows as code. This evolution has a subtle set of benefits which are worth remembering.

Our code is stored in version control, which means we’re able to reuse the same practices that we’re used to as our application code:

• Changes can be viewed over time, allowing us to understand who made a change and why.
• You can use pull requests to ensure that each change is reviewed by at least one other human. After all, two heads are better than one, as they say!
• Changes to workflow code appear next to app-code changes in the same commit or pull request, allowing us to understand and verify their relationship.
• Automation can be triggered based on changes to a branch of code, and can surface results in a commonly-visible area (the pull request). Therefore, whether from an operations background, a traditional developer, or a data scientist, we can benefit from automating quality checks by storing our code in version control.

Check out this blog if you’re interested in learning more about GitOps, and how you can operate your infrastructure using similar techniques to application code.

Promote a culture of innovation, collaboration, and learning

Many enterprises operate in silos, but building a culture of innovation, collaboration, and learning is possible. The open source community builds openly, asynchronously, globally, and at scale, many lessons that we can adopt for our internal development.

Check out how you can reuse these practices for your internal software development.

This is the first step of a more extensive cultural transformation. Once you’ve removed those silos, consider how you can begin collaborating across your organization. What are the most critical customer priorities, and how are you collectively working towards solving those? Are you capturing and sharing feedback so that it can be delivered to the right teams across the organization?

And finally, challenges happen. While no one enjoys live site incidents, it’s a natural occurrence in the nature of our work. The vital part is being able to learn from those situations:

• What went wrong?
• How can you prevent it in the future?
• Have you communicated to your customers in a transparent and customer-focused way?

To put this into context, here are some of the ways that GitHub communicates openly:

• We publish a public roadmap, so you have an idea of our upcoming priorities.
• The communities discussions area provides an opportunity for you to give us feedback, and for you to discuss your proven practices, challenges, and opportunities with other community members.
• The GitHub Blog provides updates on significant product announcements, thought leadership, and policy updates relating to the industry.
• The GitHub Changelog is a more granular set of updates on our recent releases, including incremental feature updates.
• Our GitHub Status page provides an up-to-date view of the platform’s operational health. If there are any ongoing issues, you’ll be able to find out about them here.
• GitHub publishes monthly availability reports, including a summary of each incident, the cause, and steps taken to improve for the future.

Conclusion

Through this blog, we’ve explored the journey from a product to a service mindset. Much of this has been driven by new industry opportunities and trends (such as DevOps transformation, cloud computing and IaC). Even so, there is much for us to consider along this path:

• Implement CI/CD to help you ship more frequently and safely by bringing quality into everything you do.
• Adopt an ‘everything as code’ mentality to benefit from the above automation practices.
• Promote a culture of innovation, collaboration and learning by pivoting your focus to the customer, accepting that things may go wrong, and adopting a culture of continuous improvement.

The post Moving from a product to a service mindset appeared first on The GitHub Blog.

Fundamentally, these processes depend on some source of the truth. In GitHub, that source is a Git repository hosted on GitHub. Git repositories are great for this, as they allow us to store our code in a way that versions can be changed and tracked over time. As a result, we are able to view a timeline of edits to files and their contents.

Building and releasing software is a common use case of these workflows, but it is not the only one. There are operational considerations behind your code; you rely heavily on the reliability and consistency of the environments that host and underpin your software. Ensuring that these systems are online, managed, and monitored is vital. This includes the day-to-day tasks of managing desired state configuration while avoiding configuration drift, managing access permissions and deploying and managing new environments. These operational tasks have traditionally been manual and error-prone, potentially spanning several different tools and platforms to achieve an outcome.

To ensure smooth service management throughout these changes, teams have typically relied upon frameworks such as Information Technology Infrastructure Library (ITIL) and other change management practices (such as change advisory boards) to minimize risk and disruption to the business.

Is there another way? Could we use our Git repository as the source of truth for these operational tasks, and somehow reconcile changes with our real-world view?

What is GitOps?

Let’s first establish a common definition of GitOps. The Linux Foundation’s OpenGitOps landing page describes four key principles:

1. Declarative
   A system managed by GitOps must have its desired state expressed declaratively.
2. Versioned and Immutable
   Desired state is stored in a way that enforces immutability, versioning, and retains a complete version history.
3. Pulled Automatically
   Software agents automatically pull the desired state declarations from the source.
4. Continuously Reconciled
   Software agents continuously observe actual system state and attempt to apply the desired state.

In other words, GitOps builds upon the cloud native principles and ideas that we have been introduced to through platforms like Kubernetes. The ‘source of truth’ is stored and versioned in our Git repositories. That source is typically declarative, meaning that the state is described in a desired and immutable manner. In other words, we describe what we want, rather than how it should happen (otherwise known as imperative).

The idea of storing a desired state in Git is powerful. As a result, we’re able to get a full history of changes over time on the desired state of our environment, system or configuration. This gives us auditability into the changes that were made, who made them, and why.

Building on this concept of auditability, we can adopt features like GitHub branch protection rules or repository rules to put guardrails in place, ensuring that changes to the desired state pass a set of quality checks (such as linting, smoke tests) and perhaps manual reviews using the four eyes principle. That way, if the desired state needs updating (for example, deploying additional machines, reconfiguring an application, adjusting permissions, etc.), we can use the same continuous integration and continuous delivery (CI/CD) principles that we are familiar with when building and deploying software, and bring those changes in as a pull request from a feature branch.

But what if the current state (the live configuration of the environment) deviates from the desired state (in our Git repository)? Perhaps someone has manually tweaked a configuration setting, deployed a new machine or adjusted permissions manually.

An automated process (typically an agent) analyzes the current state and the desired state on an ongoing basis. It then makes the necessary changes to bring the current world to an accurate representation of the desired state. In other words, the agent is there to address any configuration drift that occurs. You could consider that as a ‘pull’ model, where the state of the existing environment is continuously reconciled against the desired state. As updates are made to the desired state, they are automatically detected by the agent, and it makes the needed changes to the environment.

Consider a platform like Kubernetes or technologies like Flux or Argo CD. They rely upon an agent continuously evaluating the current state of the environment against the intended desired state.

However, there are many platforms which do not have an agent capability to enable continuous reconciliation. In these cases, I have seen teams opt to use CI/CD workflows to push the desired state to their environment. Compared to an agent continuously reconciling the changes, updates to the current state would be slower (that is based on the triggers of our CI/CD workflow). Worse still, discrepancies in the current state and the desired state could emerge, as drift detection would not be available out of the box. This would also technically break the third principle from the OpenGitOps definition. In other words, if an agent is not available for your scenario, then CI/CD tools such as GitHub Actions to deliver changes to your environment may be an option, but bear in mind the tradeoffs you would be taking.

GitOps principles are not just limited to applications, and could be considered from an operational perspective. Tools like Ansible or Terraform could be used to describe the configuration of your infrastructure. Then, platforms, such as Ansible Automation Platform or Terraform Cloud, could help reconcile updated configuration changes to the estate.

GitHub’s entitlements project

Let’s look at another example. Last year, GitHub open sourced its identity and access management solution, Entitlements. It’s something that we use day-in and day-out to manage access to applications, distribution lists, organizational structure, and more, here at GitHub.

Storing these permission mappings in source control provides a clear source of truth which is reliable, and auditable. We can easily navigate through the historical changes in our repository to determine why changes have been made and by whom. Assuming that pull requests have been used to update the desired state, additional context on the relevant discussions, approvals and checks may be traceable as well.

This once again drives the importance of good governance practices, not just in our software projects, but also in repositories where we’re adopting GitOps principles to drive infrastructure configuration, or our identity and access management permissions. In particular, branch protection rules or repository rules could:

• Ensure that the minimum number of required reviewers have approved the changes.
• Use the CODEOWNERs file to automatically assign required reviewers to the pull request based on the files which have been changed, so relevant approvers are kept in the loop.
• Lint contributions in pull requests to ensure they still meet the expected standards.
• Execute a dry-run of the configuration permissions to identify the impact of a change, before accepting a pull request.

This also takes away the risk of error-prone manual changes, allowing automation to scale and accelerate the operational needs of the business. Our operations teams are still fully involved in the process. Their role may evolve into managing the workflows to enable these quality checks, reviewing proposed changes to permissions, and approving or rejecting based on the business need and justification.

Recommended practices

As with many projects and patterns, there are several recommended practices that we can consider adopting:

• As practiced by open source communities and innersource communities; a clear and simple README in your repository is important to showcase what the project is, how folks can contribute, and your expectations around contributions.
• Quality is something I’ve kept highlighting throughout the post. It is an important part of any workflow to ensure you’re shipping valuable experiences to your customers. Consider this as an evolution to your change management practices, and how you can integrate quality directly into your workflows:
  • Use branch protection rules or repository rules to bring quality into your contribution process, before code ever reaches your production branch:
    • Consider requiring at least one reviewer, so direct merges to your production branch are disallowed.
    • Consider turning off bypassing, if you prefer that all changes must go through the process without adhering to all checks.
    • Consider requiring status checks (specific GitHub Action workflows) to ensure the needed automated checks are a core criteria to allow a merge.
  • Use GitHub Action Workflows on a pull request trigger to automate quality checks before they reach your production code:
    • Consider linting the changes, to ensure the code follows a set of standard practices.
    • Consider a dry-run of your configuration changes, so that you know what is changing before merging to your production environment. This could be a terraform plan, a bicep deployment what-if, or similar with the tools in your own workflow.
    • If you are particularly mature in your processes, you could consider a smoke test and deploy the changes in some temporary environment (not production), to assess that the changes are as you expect.

Wrapping up

This has been a whistle stop tour on GitOps, with a special focus on our entitlements project which was open sourced last year! It has also highlighted the importance of quality checks outside of your software build and release pipelines, and how they can integrate into GitOps workflows as well.

The post Applying GitOps principles to your operations appeared first on The GitHub Blog.

A strong focus on automation can reap benefits, particularly in your development workflow and DevOps lifecycle. We know that continuous integration (CI) can help accelerate development and enhance overall quality, while continuous delivery (CD) and continuous deployment (CD) can help reduce time-to-production and test for quality in live environments (for example, API fuzzing, infrastructure-as-code [IaC] validation, performance and load testing, and much more).

While many companies are continuing along their DevOps journey, there isn’t one clear path to adopting these principles. In fact, there are usually multiple application teams creating similar build and deployment pipelines in parallel. These teams operate at different maturity levels (that is, how rigorous their quality gates are; from simple builds and linting, through to high levels of test coverage and automated tests in a live environment). In some cases, a team might be managing a separate tool, such as Jira, TeamCity or similar. In others, teams may be standardized on an underlying platform but choose alternate approaches, such as using a Command Line Interface (CLI) in Bash or PowerShell, or some in-platform ‘helper’ approach (such as GitHub Actions, Azure DevOps Tasks or similar).

This potential disparity brings several challenges in a business setting:

• The multitude of platforms adopted typically causes significant operational overhead and challenges in consolidating your toolkit.
• Teams are likely reinventing the wheel. By analyzing the languages, frameworks, target platforms and deployment approaches used, you’ll see patterns emerge.
• Quality is likely not well-governed across an organization. This can introduce risk when pushing to production. How can you be certain whether a component has been rigorously performance tested, or pushed to production after only checking for a successful build?
• In high-regulatory environments, you may need to demonstrate compliance against certain checks. With a decentralized CI/CD model, attesting compliance is challenging to justify. As a result, it requires a significant amount of work to ensure compliance across application teams.

So, with the groundwork laid out, what are potential solutions? Fortunately, GitHub Actions has a few features that may be able to help.

How can GitHub help?

GitHub Actions is GitHub’s answer to automation and CI/CD, with the ability to trigger based on several GitHub events. Alongside a rich ecosystem of community and third-party actions, the platform provides a number of primitives to assist you in governing your workflows.

Let’s explore the platform features available to help govern CI/CD at scale across your company.

Branch protection rules and required status checks

With GitHub Actions, your workflows are stored as source in your repository alongside your code. That means they can benefit from the same governance practices as your other code.

When writing code, you typically want to follow a consistent process to bring changes to your codebase. Ideally, there would be a set of quality gates that must be passed before the changes can be brought into production. This is where branch protection rules come in. They allow you to enforce standards, so that quality can be maintained.

Protection rules can be combined with status checks to ensure that your code is meeting a set of conditions.

These checks could include tasks like test execution, build verification or validating that no new security vulnerabilities have been brought into the project. Required status checks can be mandated on a repository by using branch protection rules, encouraging practices that lead to higher quality code being pushed to production.

Reusable workflows

Instead of repeating the same set of steps across multiple workflows, you can define them once in a reusable workflow. And, well, reuse them!

Think of them like a function in software, which is generic and reusable. Or, if you’re familiar with IaC, think of reusable workflows like a template, acting as a “cookie cutter” for different patterns of your workflow.

With that in mind, it’s typical to see a reusable workflow take several parameters and use those to determine the action (pun intended!) within the workflow. As an example, below is a reusable workflow, which:

• Takes a config-path as an input string (think of this as a parameter to a function).
• Passes envPat as a named secret value. GitHub Actions recognizes that this value should be obfuscated.
• Executes the workflow on a GitHub-hosted Ubuntu runner. This workflow runs the actions/labeler GitHub Action using the provided inputs and secrets.

on:
  workflow_call:
    inputs:
      config-path:
        required: true
        type: string
    secrets:
      envPAT:
        required: true
jobs:
  reusable_workflow_job:
    runs-on: ubuntu-latest
    environment: production
    steps:
    - uses: actions/labeler@v4
      with:
        repo-token: ${{ secrets.envPAT }}
        configuration-path: ${{ inputs.config-path }}

The above reusable workflow shows a workflow that could be scaled across a company for repeated use. An application team would pass in the relevant secrets and define their own configuration file (in a path of their choosing, as opposed to a predefined path), while executing the needed checks and balances.

Application teams can consume the reusable workflow in their own workflows, using a snippet similar to the example below:

jobs:
  call-workflow-passing-data:
    uses: octo-org/example-repo/.github/workflows/reusable-workflow.yml@main
    with:
      config-path: .github/labeler.yml
    secrets:
      envPAT: ${{ secrets.envPAT }}

This raises a question. When might you want to share workflows? First, you’ll want to consider how broadly to share them. Are some business-specific (for example, relating to the processes of a business unit), or are some company policies and should be reused throughout?

Division-wide

These workflows could be shaped by a business unit’s processes, a given business unit choosing a specific cloud provider, division-wide governance policies, or numerous other scenarios.

Consider creating a repository for the purpose of sharing workflows across the division. That way, application teams in the division can consume from the centrally maintained repository. If any workflows are sensitive, then you could consider creating a private repository, and only sharing as needed.

Company-wide

Some workflows may warrant sharing across the entire company, for example, companywide policies or practices. This makes sense for scenarios where a business wants to provide paved paths that include built-in guard rails.

Consider a business that has adopted common languages or similar target deployment platforms across teams. They may want to provide templatized workflows that include unit testing and linting as standard. Or, performance testing to some standard endpoints for a given cloud provider’s hosting platform.

In essence, the scope of commonality for these workflows exists at the company level. You could once again consider a repository for the purposes of sharing these reusable assets across the company.

Required workflows

Required workflows were recently released in public beta. They ensure that a specified workflow is executed in a pull request (appearing as a status check), and are configured at the GitHub organization scope. This is useful when you want to take a step further than empowerment, and mandate that specific steps are completed.

As an example, consider the rollout of a security scanning tool. To ensure that all teams are scanning for security issues in their projects before merging code to production, you could consider making this a required workflow.

However, it’s worth considering the tradeoff when adopting this approach. How opinionated and imposing do you want to be on application teams that are using GitHub Actions? Alternatively, how much do you want to empower those teams to choose the appropriate reusable workflows for their scenario?

This decision will depend on your team’s risk appetite and whether cultural norms would allow for standardization of practices across the company.

GitHub Actions Importer

We know that adopting CI/CD is not as simple as creating a new workflow. In many cases, you already have incumbent tooling (perhaps multiple) to complete your DevOps automation needs. Fortunately, GitHub has released the GitHub Actions Importer.

This tooling helps you to migrate pipelines from Azure DevOps, CircleCI, GitLab, Jenkins, and Travis CI. While not completely foolproof, the team have found that on average over 90% of tasks and constructs used in a workflow have been successfully converted. In case you missed it, the tooling became generally available last month (March)!

In real terms, this can help accelerate your adoption of GitHub Actions. In turn, you could then convert those workflows into reusable workflows, and share your commonly-used recommended patterns across the organization, benefitting your wider engineering community.

After all, that’s exactly what innersource is about: contributing to the success of others, and building on the work of others!

What guardrails can you put in place?

For some organizations and engineering leaders, the prospect of reusing CI/CD and automation practices across the company may seem daunting. However, there are several considerations to help mitigate risk while ensuring your teams can continue innovating and being successful.

Permissions and secrets

To deploy your application to an environment, such as Azure, AWS, GCP, or on-premises, you must grant some level of access to your CI/CD platform. This typically means providing passwords, or certificates and having robust operational procedures to manage those.

But what if you didn’t have to worry about secrets at all? What if you could deploy to a target deployment environment without using a secret? Fortunately, that is possible using GitHub Actions and OpenID Connect (OIDC). Check out my extensive blog post on the topic.

Take a moment and think about how you can combine this with the concepts we’ve explored so far. Your application teams can depend on a number of reusable workflows shared internally. Employees can submit a pull request to enhance those workflows, which would be reviewed by (and benefit) the wider community. Those reusable workflows may contain actions that leverage GitHub Action’s OIDC capabilities and remove the need for passwords.

In other words, you are starting to pull together a series of templates that bring together recommended practices from across the organization and reduce the toil by removing credentials and passwords as a requirement (and therefore the need for password rotations and similar). This is a win for application and operations teams.

Manage the permissions of your workflows

Each GitHub Action workflow run is executed with a set of permissions so that it can interact with GitHub Services. For example, pushing a new package to GitHub Packages. We recently updated the default permissions so that it is read-only by default. However, you can explicitly set these permissions in your workflow’s YAML definition.

Governance: allow/deny specific actions and reusable workflows

Organizations typically have rigorous component governance processes in place, helping them understand the dependencies they have adopted in the software they build. But how do you govern the use of GitHub Actions and reusable workflows?

At the enterprise level, you can use policies to restrict the use of GitHub Actions, specifying whether all actions and reusable workflows are allowed, only those within the enterprise, or a more controlled list.

When selecting the option “Allow enterprise, and select non-enterprise, actions and reusable workflows,” you can access further granularity. This includes only allowing actions created by GitHub, marketplace actions by verified creators, and allowing specified actions and reusable workflows. You can find more information about these governance options in GitHub Docs.

These same policies can be set at the organization level, or you can set GitHub Actions Permissions at the repository level. This allows you to empower decision-making at the level which makes most sense in your company.

Dependencies: keeping GitHub Actions up to date

Just like open source dependencies, it’s important to keep your GitHub Actions up to date. When using a GitHub Action, you can specify a version number, which ties to a Git commit ID, branch name, or version number associated with a Git tag.

If there is a newer version, Dependabot can generate a pull request to update your GitHub Action workflow and point to the most recent version.

Find out more about keeping your actions up to date with Dependabot.

Wrap-up

Automation in the developer lifecycle is critical to accelerating delivery, maintaining quality, and delivering value to your users. However, silos across businesses can prevent teams from collaborating effectively.

GitHub Enterprise and GitHub Actions can help bring teams together to share internal CI/CD best practices. We have also explored several opportunities to establish policies and governance at scale by building paved paths or guardrails using reusable workflows. This allows you to set teams up for success and empower them to do their best work, while adopting recommended procedures across the organization.

The post Building organization-wide governance and re-use for CI/CD and automation with GitHub Actions appeared first on The GitHub Blog.