GDCT Request Automation

Seagen has an automated request process for provisioning many of the capabilities that GDCT and DevOps provides.

How do we use this automation?

LeanIX VSM Product creation triggers a this process.

This request includes;

  1. Repositories

  2. Cloud Subscriptions

  3. Service Principle

  4. DevOps Deployment Pipelines

  5. User setup for GitHub project

Repositories will need to be named following a standard.

  • When a new product is needed, the team will request this through the Engineering Governance Committee.

  • There the EA team will ask what product is being created and the context of the product.

  • This will inform the creation of a new Product in LeanIX VSM.

  • Once created in VSM, the automation makes a request to the REST API and retrieves the program, context, and tags to be able to create the repo and subscriptions.

The following information is used to create the repo or subscriptions.

  1. Repo name - From LeanIX VSM Product List (REST API call)

  2. Cloud provider - Defaulted to Azure, determined as part of the EGC

  3. Subscription name - Created from the product name like launchpad-supplychain. If the subscription exists, then we use separate resource groups using Terraform (see Launchpad Supply Chain), else create a new subscription using the product-context naming convention. Only Products of type Customer Facing are synced with LeanIX EAM and SNOW.

For instance, you can use product-context as a default, or if you want to add more context, you can add a function like product-context-data

Monorepo

Called a monorepo because the infrastructure is included with the code.

  • invivostudies-omnivivo

  • invivostudies-proteintracker

  • invivostudies-adctracker

After deployment or connecting subscription, developer will create and deploy modules or resources to one or many resource groups based on their configuration needs.

Multiple Repos

This pattern uses separate repos based on context.

Example of Product/Program and Context Driven Repo Names eds-etl eds-bootstrap-data launchpad-manufacturing

Example of Product/Program, Context, and Function Repo Names

launchpad-manufacturing-digital launchpad-supplychain-inventory launchpad-supplychain-ordermanagement

After deployment or connecting subscription, developer will create modules or resources that will be deployed to separate resource groups based on function. In the example above, there will be 2 resource groups, inventory and order management respectively.

When to include infrastructure as part of your repo

There are 2 groups of developers in Seagen. Those who understand automation using scripting and those who do not.

Integrated Infrastructure Repository

If the infrastructure is included in the main repository, when changes are needed, the DevOps or Community of Practice teams will make the change and submit a pull request to the product team for review. If the review is accepted, the changes are merged.

There is also a file structure convention that comes with this choice. The following folders are being created by default.

main

cicd - contains Terraform files
code - contains source code, tests, and mock data
docs - contains markdown and supporting documentation
features - contains cucumber files

Complexity: The DevOps team needs to understand where the Terraform is located and what modules, resources are being deployed.

Separate Infrastructure Repository

If the infrastructure is in a separate repository, the DevOps or Community of Practice teams will make the change, review it amongst themselves, and schedule a deploy with the development team. Once accepted, the developer will create a pull request to the product team and review it with them. This choice also includes a file structure.

TODO: Create a reviewer role and security group. Create a role in VSM and assign to the products.

Source Repository - main - for source code

code - contains source code, tests, and mock data
docs - contains markdown and supporting documentation

Infrastructure Repository

main

main.tf
infra.tf
backend.tf
variables.tf
etc

TODO: Need an example repo with the structure of files and directories. (Tony Critchett)

Complexity: The DevOps and Community of Practice teams will need to know where the infrastructure is for the various teams that they need to support. These typically include the science team developers.

Who Creates the Repository

Only the GDCT Automation will create repositories. Manual repository creation is not allowed.

How Many Teams or Members are Assigned to a Repository

Users

There can be as many users as needed assigned to a repo. However, users should only be added to teams and not assigned directly to the GitHub repository.

Groups

All members should be assigned to one or more teams. Each member will be assigned one of 5 roles.

Repo Permissions

By default, the DevOps team is assigned as the Repo Owners. They maintain control of the repository.

For assigning other roles, we create a new group using the naming convention of team-function-group.

For instance, for Launchpad Manufacturing, we would have a team called launchpad-manufacturing-contributors launchpad-supplychain-contributors launchpad-supplychain-viewers

This makes understanding the permissions very easy. Though the permission is not used in the name, it does provide an understanding of what that team can do. It accommodates each permission and also focuses on the role.

How do we add users to a team that is assigned to the repository?

A user can request access to a repository via a SNOW workflow. The SNOW form sends the approval request to a group called Repo Access Manager. The members of this group will approve or reject adding a team member to a repo. When approved, the workflow continues and adds the member to the repo with write permissions. If rejected, the workflow stops.

TODO: Create the new workflow from LeanIX VSM, update existing workflow, reassign teams and members to repos.

TODO: Get a list of GDCT vs. non-GDCT repos, subscriptions, resource groups

Owner of GitHub - Restricted Permission

DevOps/GDCT team members are the only owners of repositories.

Administrators - Restricted Permission

DevOps/GDCT team members are the only administrators of repositories.

Maintain - Restricted Permission

A few members have maintain permissions. These are typically managers or leads for that development effort.

Write - Default Permission

The majority of the members will have write permissions. This will allow them to update and manage their code.

Triage

Not typically used at Seagen.

Read

Used by people who just want to read or evaluate the repositories.

How to Create New Repos

Teams can create repositories whenever they want as long as they use automation to do so. This can be done via linking a repository to a product. For instance, you have a product repository called launchpad-manufacturing and you want to add another repo associated with launchpad.

There is an action that will create a new repo using the naming convention from the associated repository. In this case it could be launchpad-manufacturing-digital where digital is the new repo. This repo has all of the pipelines you would get when creating a new product.

TODO: Create the new automation and pipeline that creates the repo with the GDCT policies and workflows applied

Shift Quality to the Left by Enforcing Good Quality

See ShiftLeft

When issues with code occur from the scans and management above, it should affect one engineer and should not be allowed to be promoted to production. As we develop the standards, we need to evaluate what scans are required, high, or critical, so that we understand the risk.

In the future, we will use the scan results to help improve quality and also drive change and practice.