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.
Interesting article, thanks. I wonder if it is possible to sync both ways, so you can edit in Azure or Git and have the sync go back and forth?
Hello Andrew,
This sync is one way only. You might be able to accomplish a two-way-sync with some custom (and probably ugly) scripting, but in my opinion this will do more harm than good.
With the one way sync you have all sources in one controlled environment.
It could be useful to protect your automation accounts from direct editing. I will think about a blogpost for ways to do this besides settings permissions.
Regards,
Barbara
Hi,
“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”
I understand that we need a service principal to get access to Azure and another account to get access to DevOps.
It this so?
Regards,
Łukasz
hi Łukasz,
To make sure your connection is always available, the easiest way is to create a service account that has permissions in Azure DevOps as well as permissions to set up the connection in Azure Automation.
It is possible however to use an account that just has permissions in Azure DevOps. For this you would set up the connection through PowerShell and use a Azure DevOps PAT-key generated by the serviceAccount. You can read about that one here.
So to conclude:
You don’t need a service principal.
You do need a service account that has permissions (and a license) in Azure DevOps.
You do need some way to access the Automation account in Azure. You can reach it by giving the Service Account permissions to reach it in Azure or create it in PowerShell.
I hope this answers your question.
Regards,
Barbara
Hi,
Thank-you for this article. I have integrated the azure devops repository into the automation source control and have also enabled the auto-sync, but the auto-sync feature is not working as expected.
Whenever I commit any changes in the runbook which are into the azure devops repo, the changes are not getting auto-synced to the runbooks in the automation account.
I am using the powershell script with PAT to perform this operation.The automation account have run-as-account with default permissions and PAT have following permissions :
Code (read)
Project and team (read)
Identity (read)
User profile (read)
Work items (read)
Service Connections (read, query, and manage)
Are there any permissions required on run-as-account or PAT? Let me know if I am missing anything.
Thanks,
Ankita
Hi Ankita,
I have tested this and have the same issue. My testaccount had full permissions, so permissions are not the issue. I do hear from people who have set up the sync through the portal (so without PowerShell) that they don’t have this problem.
I have reached out to Azure through Twitter, Will let you know if I hear back.
Regards,
Barbara
Hi Barbara,
Thank you for your reply!
I raised a Microsoft support ticket for the auto-sync issue, and they said that it is a known issue to their Product Group team. They are actively investigating the same and would shortly release the update.
Thanks,
Ankita
Nice one. But what about MFA protected accounts? For such PAT isn’t working….