0 Comments

Part 1 – General Overview & Account Structure.
Part 2 – Setting up the Azure and Visual Studio Online (VSO) structure and maintenance.
Part 3 – Setting up the Azure Environments with ARM and PowerShell.
Part 4 – Setting up Build Servers.
Part 5 – Setting up Continuous delivery (CD) on CI Development builds.
Part 6 - Setting up Release Manager for Dev nightly, QA, Stage and Prod deployments.

Part 2 – Setting up the Azure and Visual Studio Online (VSO) structure and maintenance.

In part 1 of this series I discussed the general azure account and subscription structure that we settled on. In this post I will go into a little more detail how we achieved this, what automation we felt was critical to success and how we used VSO to accomplish our end-to-end Azure/Vso pipeline.

image

Azure

After the the above structure was setup in the Enterprise Portal, the next biggest thing to look at is identity.

User Identity:

Most Enterprise users will already have an Active Directory on premise, with a management policy already in place as to how users/computers are managed by a given team. Microsoft provides Azure AD Connect which is a service that will constantly sync changes between your on premise AD and your AD in Azure. Do not underestimate how long it will take to set this up, there are many prerequisites that you will have to go through with your on premise AD before you are able to sync it with azure. I really would not recommend progressing any further with Azure until you have this or an equivalent strategy for user and administrator access setup; we did and the later migration is going to be difficult.

Access Control:

The client was keen to embrace a less restrictive access control policy on developers than perhaps is ‘normal’ in order to achieve a low maintenance highly flexible environment, but with tight control around key environments for consistency control. It was decided that all developers would have full read-write control to their own programs dev subscription (i.e. all projects within the program they belong to), with full read permissions to the QA subscription and no rights to staging or production. To ensure consistency we developed a set of custom PowerShell scripts to hand over to the team in charge of account admin, this would ensure naming of groups were correct and reduce the chance of accidental escalation of privilege to other environments.

Tear down and re-provision:

For a ‘DevOps’ pipeline to work efficiently, and for all key stakeholders to have confidence in it, it is vital that everyone is encouraged / coerced into scripting every last detail of a project. To encourage this we setup Azure Automation Jobs that would tear down the resource groups within the development subscriptions every night (with a few minor exclusions for VM’s hooked up to release manager, we will come back to this later). This meant that we as developers had to ensure we added every last setting to our Azure Resource Manager templates (ARM) that described a given project.

In production a tear down and re-provision strategy is obviously not always practical, so we also wanted to test an inline upgrade. To do this, our QA deployment would delete the given resource group, retrieve the ARM template used in the current live environment, apply this to QA, before applying the new QA ARM script of our new deployment that would inline upgrade the environment. This requires a high level of co-ordination, and does have some downfalls (i.e. dependent on the changes between different version of your ARM script you may be unable to do a live deployment and have to arrange downtime for release).

VSO:

Azure subscription location:

As with on premise, your VSO and build server access control needs to be extremely tight (having permissions to check in changes, release new builds and administer VSO or azure subscriptions is as good as having admin access to any PC/server/subscription in any environment that your are deploying to). We hence decided to separate VSO into its own Azure Subscription named “dev tools”, where we would also later place our build VM’s. This isn’t entirely necessary, especially now with RBAC in Azure, but it feels like a good separation of concerns where access control can be kept tight and interlinked resources between subscriptions can be kept to a minimum (i.e. Release manager has to be able to ‘see’ all subscriptions in order to release the software).

Collections:

At the current time of writing VSO can only support 1 team collection per VSO account, unfortunately this means you either opt for multiple VSO accounts or flatten your structure and utilize team projects. Neither option is ideal, and it is good to hear that Microsoft are working to bring this feature to VSO, but after some trial and error with both approaches we settled on 1 VSO account with a flatter team project structure. This does mean we lost one level of abstraction, but on the whole this has not been a problem for the client. The clients on premise TFS 2013 only had a handful of collections anyway (one for each ‘Program of works’), so moving everything up one level and applying security at the team project level has mostly been okay. When/if Microsoft bring multiple collection support into VSO, the migration path should be much more straightforward than it would have been from multiple VSO accounts.

Branch structure:

This is one area with no change between Azure and on-premise. Following best practice set out in the book ‘Professional Team Foundation Server 2013', we implemented a streamlined branch structure. What branching structure you adopt will be very dependent on your team and the business around you, have a read at the different options setout in the book above and see what is best for you.

Build & Release:

VSO introduced ‘Build vNext’ in May 2015 and as far as possible we planned to utilize the many benefits this offered (no xaml build scripts being the main one). However, VSO has not yet released ‘Release vNext’ and until such time the current Release Manager 2015 for VSO has a dependency on XAML builds.

Microsoft has been clear that Build vNext is the future, and we were keen to establish a template for later migration, so we planned to utilized build vNext for our CI builds while having the XAML build (that was hooked into the Release Manager 2015 pipeline) operate on a “rolling build” after a given number of successful check-ins to perform our Continuous Delivery (CD). Please see part 5 of this series for further detail on the setup.

Summary:

Hopefully this has given a insight into how we setup Azure and VSO for this client. The next set of posts I intend diving a little more technically in-depth into, so if you have not already done so now is a good time to sign up for azure.