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.
- Only keep one VSTS project called ITAC since to be able to share the groups made for different departments.
- Create a separate repo for each department/asset combination.
- For each new department create four groups to manage development, 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.
- 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 OrgOwner is a member of InternalOwner 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 InternalPM), and approve pushing release to Prod (inherited from InternalQA).
- A person from [Deparment]DEV team has to manually start a deployment to DEV (no CD for IAC) and has to be approved by a member from [Deparment]PM. A member from [Deparment]QA has to pre-approve a QA deployment happen (to make sure she is fine with replacing the existing structure that might be under test). All [Deparment]QA, [Deparment]PM, and [Deparment]Owner have to preapprove 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).
- The following rights are defined for member of the four groups:
- DEV: write access to repo
- QA: read access to repo, creating test runs, co-preapproving QA and PROD deployment
- PM: manage work items, creating build and release definitions, co-preapproving PROD deployment
- Owner: full permission to all VSTS actions against department repos, co-preapproving PROD deployment.
Figure below shows the VSTS group and permissions:
These rules define how to name, build, and release infrastructure resources and applications.
- The IAC file follows this naming conversion: [Department].[Solution].Arm for example the infrastructure for CloudOrg is called Internal.CloudOrg.Arm.
- 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.
- Both AAC and IAC can reside in the same solution.
- 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: [Department]-[Solution]-[Type] where type is either ARM – for infra- or APP – for application.
Following figures show the ARM templates 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.