Hybrid Model for GitHub and Azure DevOps – Enjoy the best of both worlds
Shany Wiesel explores the benefits of a hybrid model using GitHub Enterprise and Azure DevOps.
We often hear repeating conversations with Enterprise customers who have invested in Azure DevOps and have great working dev sec ops processes and success enabled by Azure DevOps:
- Why even bother to consider integrating with GitHub Enterprise?
- What would be the added value?
- How do we evaluate maturity and readiness?
- When is the right time, if ever, to consider migrating Azure DevOps workloads to GitHub enterprise?
While we know that Microsoft is investing in Both products, Azure DevOps and GitHub Enterprise, we also know that more options for Cross Service avenues are being introduced. This opens endless possibilities to consider the “what, when and why.” Keeping in mind that GitHub enterprise is constantly being introduced as the future we should plan for, it is all about timing, effort, and value.
One of the major strengths of Azure DevOps is that it was always developed with planning for integration attitude. Azure DevOps supports multiple integration points across each of the major services— Azure Repos, Azure Boards and Azure Pipelines. Therefore, we can easily consider updating / improving existing DevOps workloads, implemented in Azure DevOps with the desired capabilities that come with the innovative GitHub approach of collaborating and solving problems by building software together.
When we review how we manage our coding and source control practices we need to understand our organization’s maturity. Hopefully we have migrated all our TFVC repositories into Azure DevOps Git Repo’s by now. If not, we are way behind … next step is to understand the collaborative maturity of the way our developers work together. When comparing the Azure DevOps Git Repo’s and GitHub Repo we find that both offer a rich code review experience with branch policies, pull requests, code reviews, webhooks, etc. What about collaboration? Software developers today want to be efficient. They don’t want to write code that someone else has already built. There’s no need to invent the wheel again. They also want their code to be shared in a secure manner but still receive feedback. Azure DevOps supports private and public visibility projects. While setting repositories permissions is more intuitive in Azure DevOps and enables some collaboration opportunities, the culture of inner source sharing requires investment in planning. GitHub offers 3 layers of Repositories visibility. While defining a repository as public may not be an option for enterprise developers, defining a repository as private can limit collaboration, partnership, and the teamwork spirit. Therefore, an Internal repository offers the best middle ground and the flexibility of keeping intellectual property secured for only enterprise developers while accommodating an inner-source collaborative approach among the developers within the enterprise.
A common concern raised by Enterprise developer managers when opening the gate for collaboration is “how do we secure all these activities?” In the Azure DevOps world, most enterprises have invested in code security extensions such as Sonarqube, WhiteSource or Black Duck. While we can continue and integrate Sonarqube, WhiteSource or Black Duck with GitHub we can also enjoy the in-house code scanning capabilities that promotes capabilities to find vulnerabilities that allegedly other tools miss, also utilizing CodeQL, the industry’s leading semantic code analysis engine, having revolutionary approach that treats code as data to identify security vulnerabilities faster.
DevOps methodologies are not only about collaboration, but also about efficiency. It is about enabling our developers to create new code and avoid wasted time. A familiar conversation we have with developers is about the struggle to create a development environment because their computer hardware and software have failed. Maybe they were home and needed the computer in the office. Maybe there is a new developer requiring a lot of effort to help him/her get setup. Would GitHub Codespaces ease the impact of those scenarios? It does provide the capability to have all the workspace in a browser, but it requires the developer to have connectivity.
Let’s discuss documentation or better frame the conversation to how we manage, monitor, and understand our projects status. Most enterprises have evolved into Agile practices and left behind the waterfall approach. Planning, following, understanding, and learning from the team required a lot of change management and resulted in a lot of enterprises customizations to Azure Boards, often supported by extensions. While GitHub Projects can be customized to support similar workflows that we have done in Azure Boards, in most cases it seems that it is a lot of work with not a lot of value. A nice middle ground to enable support of GitHub repository commits and pull requests, while keeping the investment in Azure Boards, would be to connect Azure Boards to GitHub. Integrating GitHub with Azure Boards lets you plan and track your work by linking GitHub commits, pull requests, and issues, directly to work items in Azure Boards. Linking GitHub repositories to Azure Boards, the best of both worlds, enables and surfaces a basic DevOps desire of linking Work management into development workflow, connecting ideas to releases, scanning the code in GitHub for security vulnerabilities and tracking DevSecOps methodologies and enjoying the great of both worlds.
So, we explored coding and planning– now we probably should explore how we make it all real by the term that we all learned to love: CICD (Continuous Integration Continuous Deployments). Again, assuming that we have matured our classic pipelines and migrated all to YAML, with both Azure Pipelines and GitHub Actions, we can create YAML workflows that automatically build, test, publish, release, and deploy code. When we examine our mature and powerful Azure DevOps pipeline, that was built with the enterprise in mind and works well for the enterprise world. We need to make the decision– when does it make sense to keep our pipelines in Azure DevOps and when does it bring us value to migrate to GitHub Actions? We can start by comparing the capabilities, especially understanding the feature parity , keeping in mind that the GitHub Actions are rapidly evolving and explore the current recommendations for common scenarios. On the other hand, GitHub is trying to make actions have its own appeal with collaboration mindset, encouraging developers to embrace opensource culture by choosing from thousands of workflows and Actions created by the community, or from GitHub Actions Marketplace, offering solutions to work around the gaps. For example, while Azure DevOps pipelines support both Variables and Variable Groups, GitHub Actions supports only Variables. To work around the limitation, here is a community solution for action variable groups and another solution for variable substitution.
To summarize, we have the luxury of creating our own hybrid model to include the maturity and enterprise friendly capabilities of Azure DevOps with the flexible and innovative spirit we find in GitHub Enterprise. While GitHub is working to make the platform have its own appeal, by being the place where the world’s software developers gather to make things and then make them better, some features are unique to Azure DevOps but can be custom created for GitHub, it is all about what brings developers the most value.
Light
Dark
0 comments