If you’ve been following my posts on Azure DevOps you may have been thinking that “this is all well and good but my code is in GitHub“. Well, Azure DevOps still has you covered.
As I previously mentioned, Microsoft now owns GitHub so it should come as no surprise that GitHub, whilst still a separate operation, has received plenty of attention when it comes to integrating with other Microsoft developer services, not least Azure DevOps. In fact, almost everything I’ve talked about up to now applies equally to code held in a GitHub repo as it does to code in an Azure DevOps hosted Git repo.
What this means is that you can keep your code in GitHub if you prefer, but use Azure DevOps boards to manage work items (as well as the Issues facilities in GitHub) and Azure DevOps build pipelines to manage builds.
When you push changes to GitHub your Azure DevOps build pipelines will be triggered and work exactly as they would if your code was in an Azure repo.
Setting this up is super-easy, barely an inconvenience.
You still need an Azure DevOps Project to host your pipeline(s) and your boards, if you’re going to use those (but you don’t have to – these are connected separately). Assuming you have a project, when adding a new pipeline simply choose GitHub YAML when asked to identify where your code is:
The first time you do this you will be asked to authenticate your GitHub account, after which you will then get to choose any of your repos (public or private). That is literally the only difference. After that, you then either create a starter pipeline, an empty one or select an existing pipeline from within the repo itself (if you have one), just as before.
For example, if you are deciding to simply move some code from an Azure Git repo to one on GitHub:
- ‘Migrate’ the repository (super-easy with Git due to the distributed nature of the beast)
- Create your new pipeline, pointing it to the same YML as before but with the pipeline connected to the GitHub repo rather than the Azure DevOps repo.
Done. It really is that simple.
You cannot simply point your existing pipeline to the new GitHub repo. Once a pipeline is created it is permanently connected to the repo selected when that pipeline was created. You can change the YML file that the pipeline runs to another YML file in the same repo (which you would need to do if you renamed or re-located your YML files, for example), but you cannot change the repo itself.
For migrating an existing repo the only downside to this is the loss of your previous pipeline history and stats, which may or may not be important to you.
If you are also going to use Azure Devops Boards and Backlogs in conjunction with this repo then a separate connection must be established between the project and the GitHub repo. This is achieved through the Project Settings -> GitHub Connections:
You will again need to authenticate your GitHub account and then choose which repos to connect to this project.
With this connection in place you can use AB#<work-item-id> in a commit message to link commits and pull-requests to work items in your Azure boards. You can even automatically update the state of those work items by using certain words or phrases in those messages. e.g. Fixes AB#145 will link a commit to that work item and set it to <strong>Done</strong>.
There are plenty more examples (and some potential gotcha call-outs) in the documentation.
So why would you do this (and why would you not ?)
Pro
- GitHub Pull-Request UX (still better than Azure DevOps despite some recent improvements
- Collaborators/consumers can find your code far more easily through the GitHub public repository UX
- The ability to separate public issues (GitHub Issues tracker) from private development plans/roadmaps (Azure DevOps backlogs and boards). That is, you can choose at what level of detail to share this information that suits you/your project
- Free, self-hosted CI/CD Azure DevOps builds using more traditional build machine vs GitHub Actions (still in beta)
- Both Azure DevOps and GitHub have very serviceable free price tiers, but moving up from that, at time of writing GitHub Pro provides unlimited collaborators on private repos for just $7/mth. Azure DevOps Basic (free) provides 5 free collaborators but US$9.08/mth per additional user.
Cons
- None that I can think of 🙂
Which isn’t to say that I think you should always use GitHub repos over Azure DevOps. In simple terms, GitHub imho makes perfect sense for completely open, public repositories and the richer backlog tooling in Azure DevOps may be attractive for completely private repos. For private repos with some collaboration GitHub may again have the edge.
For more nuanced, complicated scenarios, the ability to connect the two allows you to formulate a hybrid approach that suits you and your project(s) on a case by case basis.
It doesn’t have to be a question of Either/Or.