Microsoft acquired GitHub in 2018 for $7.5 billion. As GitHub continues to grow in functionality and have many acquisitions of its own, it is becoming clear that GitHub is positioning itself to be a DevOps market leader. This has become more evident most recently, with the recent release of “GitHub actions“, GitHub’s solution to CI/CD. GitHub now has a complete DevOps story: it’s time for us to dive in and learn some more. It’s important to note that Azure DevOps is not going away. Azure DevOps is still an important part of Microsoft’s DevOps strategy. Over December, and the next few weeks we are going to:
- Setup a repository in GitHub and import our feature flags code from Azure DevOps
- Setup CI/CD with GitHub Actions to build our ASP.NET Core application and deploy it to Azure
- Play with some of the fun tools, such as DependaBot, to help maintain our product
Logging into GitHub, we create a new repository. There are a lot of options here. We select a name “SamsFeatureFlags”, keep the repository public, check the “Initialize this repository with a README”, add a “VisualStudio” .gitignore, and select the MIT license. While private repositories are now they are free, they do have limits, for example, you can’t create branch policies. There is also another level, “GitHub Enterprise”, where you can control permissions at a more granular level, but at a higher cost. It all depends on what your organization needs – but the free public repositories have so much to offer!
With the repository created, we head over to settings, where we want to setup a branch policy to protect the master branch. In the “Branches” section, we click “add rule” to specific a “branch protection rule” on our “master” branch. We add just one policy for now, requiring a reviewer for the Pull Request.
Next, we clone our code to our local dev machine, (we are using Visual Studio still), create a new branch “CreatingNewProjects”, and paste in the source code we had stored in Azure DevOps. We didn’t need to transfer history, but if that is important to you, there is also an import repository option. We also update the README.md file, describing our project and goals, before committing and pushing the code back to master. In GitHub, we can see in the banner right away that the push has been detected, and click the “Compare & pull request” button
In the open pull request we just enter a description and open the request.
All we need now is a review, which we quickly approve (on the “Files changed” tab), and the pull request is complete.
Everything so far has seemed very straight forward. At this stage, we noticed an email in our inbox from “GitGuardian“. Uh oh, we uploaded a secret. Similar to CredScan in Azure DevOps, GitGuardian is a built in GitHub tool to scan for and identify secrets from many different sources. Reviewing our code, we do find the secret. As this secret is exposed to the public, we also generate a new secret, create a new pull request to remove the secret, and approve the new changes.
Not super deep today, but we have to start somewhere. We now have our code in GitHub, with branch protection/policies, and confident we are automatically protected against accidentally pushing secrets into our repository. Next week we will add the fun stuff, CI/CD with GitHub actions.
- GitHub Pricing: https://github.com/pricing
- GitGuardian: https://www.gitguardian.com/github-public-monitoring