Megan was very excited that she was able to build the first resource in their organization, the IoT hub. At the same time she wanted to follow a pattern that could be easily extended as new departments were added to their organization. As mentioned earlier she sought to build three tools that could help them simplify building new resources. At the same time she wanted to make sure she spent her time on building tools that directly helped building the floating car prototype.
Next morning she met John to show the progress she’d made in setting up the hub which make him really pleased. He also demoed the progress he’d made in setting up 1000 wireless sensor on his Tesla and was ready to connect them to the IoT hub. They looked at different ways to connect the sensors to the hub for a few hours and made several decisions. Just before they wanna leave to grab a bite for lunch, Megan explained to John what she had thought about extensibility. John liked the idea but like Megan wanted both of them to stay focused on building the prototype so they decided to add a friend of Megan called Ali to the team. Ali, a graduate from USC, had been Megan’s coworker at Microsoft and had strong DevOps skills and was an Azure certified architect. Megan called Ali and asked if he could join them for lunch. Ali was able to meet them at lunch and did not take any long to convince him to join PG to lead building the internal tools they needed. They decided to establish a department called “internal” and gave Ali the director of software development in charge of the internal department.
Next day Ali and Megan met in the afternoon at a nearby coffee shop and brainstormed building the internal tools. After a few hours, they came up with the following rules to apply to all the departments:
These rules specify who can do what and are enforced by building specific groups with strict permissions in VSTS.
ITAC #1: There will be one VSTS project per department. For example Org for the root IT department and an internal project for the internal department.
ITAC #2: Create a separate repo for each department/asset combination.
ITAC #3: For each new department create three groups in Azure AD to manage development and testing, project management, and owning the resources. Groups are named using the pattern [Department].[Role]. For example the developers in the internal department will be part of InternalDev group.
ITAC #4: Apply these relationships among the groups:
- [ParentDept].[Role] is a member of [ChildDept].[Role]. This will ensure that the parent department has all the permissions given to its children. For example Org.Owner is a member of Internal.Owner giving Megan ownership on all resources in the internal department.
- [Department].Owner is a member of all the other groups within the same department to make sure owner has all the permissions that other members of the department have. For example InternalOwner, Ali, would be allowed to write code (inherited from InternalDev), modify the release definition (inherited from Internal.PM).
ITAC #5: A person from [Department].PM team has to manually start a deployment to DEV (no CD for IAC). A member from [Department].Contributor has to pre-approve a QA deployment happen (to make sure she is fine with replacing the existing structure that might be under test). Both [Department].Contributor and [Department].PM have to pre-approve a PROD deployment (to make sure the IAC is vetted by the QA and owner is fine to push to production which requires coordination with other departments ahead of deployment).
ITAC #6: The following rights are defined for member of the three groups. The rights are applied by adding the Azure group to the the corresponding VSTS group: [Department].Contributor to VSTS contributor group and [Department].PM to VSTS project admin group.
- Contributor: write access to repo, creating test runs, co-pre-approving QA and PROD deployment
- PM: manage work items, creating build and release definitions, co-pre-approving PROD deployment.
- Owner: Can do what other groups can do and will have permission to add or remove PMs.
Figure below shows the VSTS group and permissions:
These rules define how to name, build, and release infrastructure resources and applications.
ITAC #7: The IAC file follows this naming conversion: [Department].[Solution].Arm for example the infrastructure for CloudOrg is called Internal.CloudOrg.Arm.
ITAC #8: IAC provides the same topology for all environments while allowing for variations on size of resources. For example a web app could be using a basic edition of a database in DEV and a standard edition in PROD. To allow this they decided to have a separate parameter file for each environment (similar to having separate configuration files for applications). parameters files are named [ResourceName].parameters.[ENV].json. For example, the web app parameters file in DEV is called WebSiteSQLDatabase.parameters.DEV.json.
ITAC #9: Both AAC and IAC can reside in the same solution.
ITAC #10: Infrastructure and applications have separate release definitions since they are released with different frequencies (Infra is deployed much less frequently that the application). These definitions follow the following naming convention: [Solution]-[Type] where type is either ARM – for infra- or APP – for application. Release definitions – and – also build definitions – are exported and added to the solution under CICD Definitions folder in the solution.
ITAC #11: The resource group name is built using the combination of organization abbreviation, VSTS project (name after department), the solution name, and the environment. For example: PG-$(System.TeamProject)-BalancingData-$(Release.EnvironmentName)
ITAC #12: All resources are tagged for generating consumption billing breakdown reports. The tag is called dept and set to department’s name by adding a parameter to IAC and providing its value inside the release definition. This simplifies transitioning a resource to another department which only requires moving the repository without any changes to the code or release definition.
Following figures show the solution structure, IAC, and parameters and also the corresponding release definition.
Ali started applying these rules in VSTS and promised to have a version of the app the could use to visualize their IT organization in the cloud. Megan suggested to call this app CloudOrg since it could be used to visualize their entire organization. Ali liked the name and drew some wireframes to show what he had in mind on CloudOrg. They spent some time discussing various options. It was around 8PM that Megan felt a bit tired and said it has been a long day for me and I am about to leave, how about you? Ali said: well, it is too early for me to stop working! He then rolled up his sleeves and began coding CloudOrg. Megan giggled and said hasta mañana.