If you are striving to achieve a fully automated and mature process that will deploy runbook automations to Azure all from within the VSTS ecosystem (VSTS is assumed to be set up), then this blog is for you! After attempting a few deployment scenarios that are similar by concept but not in design, I’ve noticed a few “nice to have” situations that I thought might be beneficial for fellow automation experts to have under their belt. First, let’s talk about the core concepts of a code repository and how that can be the bare bones of your build & release process.
Basic introduction to Git repositories
Getting started with Git out in VSTS is practically streamlined and can be achieved by navigating to the “Code” section of VSTS and clicking on an ellipsis button next to your project to reveal options for creating a repository. Simply stated, this concept is basically a one stop shop location that will contain code that is ultimately tracked and versioned for you. It essentially boils down to folders holding files that are constantly being watched by Git on your local file system, and tracked out on the “remote” with Git GUI tools, which is basically the server. Typically, with Git and any code base, a “Master” and “Develop” branch should be implemented in order to keep work separated for your build and release processes. This means that any development work should be placed in the “Develop” branch (or branched off of that branch, but we will get to that later) and any released code should be contained in the “Master” branch. Git does a great job of showing changes based on commits, overall history, and even how a pull request will affect the code by displaying a “diff” which is essentially a before and after comparison of code state. Finally, there are many Git third-party GUI tools out there today that allow you to manage not only the repo, but the code as well.
Where can I author Runbooks while utilizing Git?
Great question. Today, there are numerous applications that interact with Git but the biggest contender is Visual Studio Code with its rich extensions. With there being so much support and updates, VS Code does a great job of harnessing Git on the back-end to connect and even displays which branch you’re currently working in! As mentioned earlier, there are many extensions out on the marketplace that enable other bits of functionality that you can enable in your client as well.
How does tracking work in a code repository?
There many ways to reveal how a code repository has been growing/developing. Usually, any GUI can show the changes that have been made via commits and can even show updates to branches. See below for having VSTS provide commit history versus a specific branch and its history:
Commit-based history:
Branch history:
As you can see, comments can be a big factor with determining how far back to pull from. They act as a descriptor of the change that could be a huge help when deciding where a bug was introduced or how far back you want to pull from – but at that point, a binary search to find the commit that introduced a bug may make more sense (hint: “Posh-Git” is a great PowerShell module for Git management)
Doesn’t VSTS track code to PBIs?
That’s correct. From a project perspective, managing code within Visual Studio Team Services (formerly known as Visual Studio Online) is extremely flexible and easy to use. Once you get going with a code repo from VSTS, you can commit changes to the branch that you’re working in and associate that specific commit to a particular product backlog item. How cool is that? This could help you track those changes and estimate against the project timeline with ease.
What happened with Azure and VSO?
A few years back, there were plans to have Azure synchronize with VSO/VSTS but currently only a Github source control connection is supported. While this would have been a bit limited, this could have been revolutionary! Azure still has a focus on Github and how that integration provides developers with pushing their changes up to the cloud via a particular repo, branch, and folder path for Runbooks. See below:
Should I keep my code in one location?
Absolutely not! In a perfect world, having your code in one place does not make sense. What happens if the network goes down so you can’t access a file share, or if a hard drive failure occurs? There should be no reason why your code is in location – utilize Git for this exact reason. With the use of code repositories, a local copy is pulled down onto the end user’s device but is synchronized to the remote server which hosts the working version and is the driving “engine” of managing change control. Visual Studio Team Services is a great example of having code in a secure remote location, but can be pulled down at any point.
Ultimately, the code repository should be the one and only place for edits (Azure Functions supports this concept if continuous integration is enabled). From an ITSM perspective, changes to code are happening frequently and having a source control system like VSTS managing your code for you only makes sense. Allow the repository to be the structure and standardization for all development and QA testing, and leverage when to release to your production system.
At the end of the day, the moral of the story here is get your code into some kind of repository for tracking. If you aren’t doing this today, you are doing it wrong. Change control for code is much harder to manage when you don’t have robust tools like Git. It’s even easier when utilizing an application like Visual Studio to push your changes up to the remote, and use third-party tooling like SourceTree or GitKraken to visualize and conceptualize how your repo structure currently looks.
Check out this blog on managing Azure Automation deployments with VSTS
here. Thanks for reading!