Introduction

One thing I challenged myself when starting at Microsoft was to get better at leveraging existing technologies and tooling to help drive greater impact not only with a specific use case; however, to the larger tech community as a whole.

One such activity I started to strive towards is storing all sample code, where possible, in public GitHub repositories so that others can benefit or draw ideas from my work. This post will cover some of the basics on what that journey has felt like for learning in public with Azure DevOps and GitHub Integration.

Background

For those that don’t follow me regularly, my background is primarily in Infrastructure as Code (IaC, Terraform, Bicep, ARM, etc..) and Azure DevOps (ADO) YAML Pipelines. Previous to Microsoft, I would stand up private ADO repositories so I could still own the code, easily export the repo if need be, and create the associated ADO Pipelines.

The thought occurred with more and more ADO and GitHub integration is this still the best setup for working with customers? I determined that though it still could work, I was running into issues with “finding my code” and remembering the ADO specific pieces. I decided to try an approach that involved storing all my source code and YAML files in GitHub, while still leveraging Azure DevOps Pipelines as my primary method to build and deploy code.

I felt this approach struck a balance where I can still limit connections and security in ADO to specific environments and variables, while still providing customers everything they need to quickly get going in their environments.

Disclaimer

I feel impelled to call out that this may not work for everyone. I am fortunate enough that the majority of work done via IaC and YAML pipelines can be completely agnostic of any copyright or trade secrets. IaC, when done correctly, will not involve anything that is proprietary or that is easily reproducible. The same goes with YAML pipelines. The goals behind both of these technologies is to drive developer productivity.

Also if you are interested in proceeding with this type of configuration please ensure there are no secrets in the code that could be accidently exposed.

Setup

For this configuration I have my personal GitHub Account, JFolberth, linked to my personal Azure DevOps Organization.

This was achieved by creating a service connection at the project level to my GitHub Account:

Here is the link to the full step by step to achieve this. For reference I used the GitHub Mobile App for authentication as it uses the Pipeline Identity and supports GitHub Checks for CI/CD.

For my ADO project structure, to assist in keeping myself organized, I created on project for my Terraform examples, and one project for my Bicep/ARM examples. This structure helped add another layer of organization above my personal GitHub where all the repositories are just listed out.

Architecture

So to recap how this will work the source code will be publicly available (or private if I want) to anyone who wants to on GitHub. The YAML Pipeline definitions will be located in the specific GitHub Repo while the consolidated template repo is also made publicly available. The Pipeline will execute via an Azure DevOps agent and leverage any security configuration setup in Azure DevOps to deploy to target environments.

Results

I can’t stress this enough, this has been a smashing success. I am now able to quickly share work I am doing with a customer to them, they can also monitor it’s progress, import/export and/or fork the source code I am writing into their environment.

Professional, I’ve been able to step in and demo code I haven’t touched in a while, been reached out to those in the community for assistance, and quickly assist others who could be facing similar challenges. It also serves as a great way to keep your work portfolio recent and available to those who are interested.

The biggest success stories by far is the repositories I created for YAML Templates and Flavors of IaC. The YAML Templates, in particular, serves as an example of how to consolidate YAML Pipeline templates for reuse across multiple repos and acts an accelerator for anyone looking to get started. By it’s very definition, a consolidated and reusable repository for Pipeline deployment, it fits as the perfect use case for this type of configuration and setup. For background on YAML templates I have a slew of articles on Microsoft’s Health and Life Sciences blog as well on my blog.

Conclusion

Hopefully this post Learning in Public: Azure DevOps and GitHub Integration gives you the confidence to take the leap and see what you can achieve in giving back to the community. From my personal experience it has paid dividends professional and offers as a great way to showcase to others the work you are doing.