At the time of writing this blog, exactly 200 versions of Team Foundation Server(TFS)/Azure DevOps Server exist. This is including CTP’s (Community Technology Preview, RC’s (Release Candidate), SP’s (Service Pack), CU’s (Cumulative Updates), Hotfixes, Patches, Updates and of course RTM’s/RTW’s (Release To Manufacturing/Release To Web). When checking the version number (e.g. 18.181.32118.5), it’s not always clear what marketing version it corresponds to (Azure DevOps Server 2020.1.1 Patch 4). There is no complete list on the Microsoft website that shows all versions. That’s why I thought: let’s do something about it.Continue reading
Or how to implement role-based access control (RBAC) in Azure DevOps in enterprise environments and still keep it maintainable. 4 Antipatterns and an approach on how to implement this yourself!
Introduction and key values
Assigning permissions to users and groups of users in Azure DevOps in small companies, maybe up to about 25-50 employees is easy and straightforward. However, at a large scale one needs to think carefully about how to approach this. At a medium-sized customer (about 250 users) I had to redesign the permissions structure in Azure DevOps. Their most important requirement was to be able to manage access control through Microsoft Identity Manager (MIM – https://docs.microsoft.com/en-us/microsoft-identity-manager/). Microsoft MIM is put in place to implement role-based access control (RBAC – https://en.wikipedia.org/wiki/Role-based_access_control). The idea behind their implementation is that team leads can approve access to systems (self-service), instead of a support team. This access was predefined by the system administrators by setting up MIM roles and (Azure) Active Directory (AAD) groups. By using MIM roles that are linked to AAD groups, it is no longer necessary to assign permissions to individual users, as adding them to a group is all that is needed.Continue reading
When using Azure DevOps frequently, a moment will come at which you’ll be faster executing a task using script rather than clicking your way through… There are a lot of reasons on why you should code repeating work, including:
- Knowledge sharing (provided that you store the code in Version Control, accessible to your coworkers)
- It’s fast
For my family I host a WordPress website on Azure (using an Azure App Service). I created it a while ago. At that time, Azure Database for MySQL Server (https://azure.microsoft.com/en-us/services/mysql) was not available yet, so the only choice was to host it at ClearDB (http://w2.cleardb.net/).
When using Visual Studio Team Services (VSTS) and Build/Release Agents, the way to authenticate is through Personal Access Tokens (PAT). A PAT can either expire in 90 days, 180 days or 1 year. The question is: what happens after expiration with my Build/Release Agent? Will it stop working? What if I restart it after expiration?
Today I updated the utility I wrote which can help migrating a Visual Studio Team Services account from using Microsoft Accounts to start using Azure Active Directory accounts.
At a customer I’m implementing automated deployment for one of their web applications. We’re using a PowerShell DSC script that is kicked off by Release Management (which is part of Microsoft Team Foundation Server). Part of that script is a “File” resource which takes care of actually deploying the new files. Continue reading
For a customer I am analyzing the performance of the builds. They have Gated Check-in builds which take more than 30 minutes. The amount of Visual Studio Solutions built varies from 8 to 12. I need to know which part of the Build takes most time. Continue reading