A few months ago, I spent some time to be able to use Azure DevOps as Source Control provider for an Azure automation account, with a script Microsoft provided. Unfortunately the script contained an error and it took some work to set up. So I found the error, created documentation for my team and set up the connection.
All this work isn’t needed anymore for Azure DevOps and Github, as Azure now offers the possibility to set up source control for Azure with the push of a button. It was a bit buggy when it was in preview, but now it works just fine. It’s easy to set up and doesn’t take a lot of time. I think you can have this up and running within 10 minutes.
(note: I will not be going into TFVC Source control as I have no experience with it. Want to use Gitlab as the source? It takes a bit more work, but it can be done. Click here to find out how.)
Step by step
Create an Azure Automation Account or use an existing one. The account needs to have an a RunAs account for the sync to work.
Note that the account you use to set up the sync, will be the account that keeps getting used to authenticate to Azure DevOps or Github. This means that when this account is disabled, Source Control will fail. It is advised to use a service account. Click here to see the needed permissions
Open your Automation Account in the Azure portal. Choose Source Control in the menu.
Select Add.
You get a menu where you put in a (display)name and then you authenticate to Azure DevOps or Github. When you choose Azure DevOps (it’s actually still called Visual Studio Team Services in the GUI), you will get the well known Microsoft login screen. When you choose Github, You will get asked by Github to Authorize access to your account.
The rest of the settings speak for themselves, they are mostly dropdowns. It’s quit flexible, you can choose to sync just one folder, but also to not publish the runbooks that are synced.
When you choose a folderpath, do mind that that folder must be an existing folder in the repository.
Click Save.
And that’s it, it’s connected now!
You can now click Start Sync to create an initial full sync.
How it works
Let’s say I commit a new file to master, or change a file. A new sync will be initiated at that time. It doesn’t matter how the change got to the master branch, a pull request or a direct push will both work.
The files are selected based on filename. If runbooks with the same name exist, they will be overwritten. Files in the Automation Accounts with different names will be left untouched.
When a sync has started, this presents itself as a scheduled job. You can see the process and the actions it takes when you go back to source control and select Sync Jobs.
Or you can look at the regular jobs in de Automation Account. When you select one, you can see the input, process and the logs.
When the job is finished, the runbook(s) has been created.
Notice that it is possible to use more than one source for the automation account.
Scripts will not be removed if they have different names then scripts in the automation account.
If you rename a script, it will appear as a new runbook. If you delete a script nothing will happen.
The jobs
It seems to me the process in the background is more or less the script I talked about earlier. It even still calls everything VSTS in the output for the Azure DevOps version.
That script required quit some manual work to set up, so this is a great solution.
In Github a script is running as well. Looking at the input, this script is very similar.
So assuming the script is the same as the one I worked with before, these actions are taken:
The connection is based on a webhook.
The initiative is at the source. A service hook will be created to run when code has changed. That servicehook collects the data about the commit and triggers a webhook in the Azure Automation Account, which starts the script. The script looks at the changed files, gets the contents and sets them up as runbooks.
