Visual Studio Team Services is Microsoft’s application life cycle management tool. While it is a very popular tool for storing code, building artefacts, and releasing them to both public and private clouds, we can sometimes forget about the other possible applications of its feature set.
You can use VSTS to version-control your ARM templates
ARM templates are a great tool for standardising deployments, but instead of getting everyone in your organisation to build their own, you may want to provide a polished set of templates that other teams can consume.
Git in VSTS allows anyone in your organisation with access to the repo to create a pull request and suggest changes that you can review together with your team.
You could even create an automated build that tests any suggested changes to ARM templates automatically and use a Release task to roll them out to a storage account that is available to all template developers and architects in your company.
You can use VSTS to version-control your infrastructure config
If you are worried about people spinning up large resources, you could keep a list of allowed configurations in VSTS and version-control it. Schedule an automatic roll out and tie it up with a PowerShell script to clean up any resources that do not comply. Alternatively you could simply roll out the config file on a regular basis and get Azure Automation to consume it.
You can use VSTS to version-control everything else as well
Policies, locking configurations, custom roles, tags, VSTS is happy to version control any piece of text you deem important enough to version and keep safe.
If you use IaaS resources, you might want to store your DSC and push new configurations to your DSC server or Automation account in an automated fashion, whenever things change.
What about permissions and access?
VSTS will release content via a service principal (a service account in Azure). Just like a normal user your service principal will have RBAC permissions, Access polices (where applicable) and Azure AD permissions.
This means that you can set up storage accounts that only service principals can write to, but that everyone can read from.
Service Principals are secured by either a key or a certificate. If you use private agents in VSTS you can store the certificate on said private agents.
You can have as many service principals in a directory as you like and any service principal will be able to access resources in any subscriptions contained in said directory if it is given the right RBAC permissions.
For bigger organisations I would not recommend using the auto create function for service principals in VSTS as this creates a service account that can access the entire subscription at a very high permission level. Instead the principal of least required access should be followed.