M1 Scope for GDCT

M1 is truly about creating an environment and ecosystems centered around the cloud and resource enablement. To achieve this we will need to learn new skills and create a learning environment focused on “shifting left”, that is allowing and enabling self-service for the Seagen resources.

Criteria for Success

The following criteria is set to achieve the scope.

  1. Value Identification and Management

  2. Policy Stabilization and Cross-Cloud Parity

  3. Granular Visibility

  4. Resource Consistency and Traceability

  5. Targeted Growth

  6. Operational Excellence

  7. Rapid Deployment

  8. Prolific Quality

  9. Measurable KPIs and Metrics

Onboarding Changes

Team

From

To

ITS Submit 2.0

legacy

distributed, hexagonal archtecture

Data Science Rafiki

Azure Pipelines and Single Deploy to development only

Individual distributed deploys through to production

Automated Pathology

3rd Party Project deployed to development only

Seagen Project with distributed deployes through to production

Bioinformatics

Grow your own automation

Standardized automation to production

Biostatistics

Grow your own automation

Standardized automation to production

ATLAS

No automation or cloud presence

Cloud first with automated deploys using PaaS

Clinical Data Management

No cloud presence

Use Databricks and data lake to manage operational data sets and conform to standard

Azure Resource Deployment

When teams need to deploy resources to Azure, the base Terraform Module will be created in the Seagen repositories following our standards and definition of done. We should have a repository for each type of resource deployed to Azure. The purpose of this is to help DevOps upgrade and version the resources and modules.

However, if a team wants to use the modules to deploy resources, they will use the Terraform Registry and corresponding Readme.

Almost all of the resources we are deploying to Azure are complete in Terraform or Powershell. Some resources are being deprecated or transitioned to other resources so support is limited. However, if the automation works we will publish the module and people can use it. When we hear that a module will be retired, then we will transition this module to another corresponding module or technology or sunset it and inform the teams.

At the same time, the DevOps team will need to continue validate the state of the modules so they can keep them up to date. This work will continue on indefinitely

Google Resource Deployment

Google resource automation is a bit different than Azure because many Google services and resources are not Terraform ready. GCP will be used by Data Science and specifically TOPS. Though they are not ready they have aspirations as does the data management and architecture team.

We are finding that many of the resources cannot be fully automated thus increasing the scope of work for the DevOps team. This will have to be factored into the ongoing development of the platform and corresponding learning environment.

Oracle Resource Deployment

Oracle is an IaaS first environment. Though they do have PaaS or serverless compute, we don’t use that and will not use it in the future. The scope of the Oracle automation is to move the code from SharePoint into GitHub and then create automation pipelines to create resources, apply the code, and validate the system is functional.

Salesforce Veeva Deployment

Salesforce uses a concept of DevHubs to create what are called scratch environments. Once automated, we will use GitHub and deploy the environment and the code. The SFDC team will transition from change sets to object based deployment to simplify their approach. The first step though, was to get the pipelines created and have a landing zone in GitHub for the team.

Terraform Cloud

We will use Terraform Cloud to plan, apply, validate state, and destroy resources on all the clouds we can. Terraform Cloud is an Infrastructure as Code tool that we use to help us standardize how we get resources to the cloud. We will implement the Terraform Cloud, Security and Key store, and Sentinel for testing. In some instances TFC does not work. In this case we can use Powershell to help with the automation.

Octoperf Test Automation

Octoperf is used for test automation from UI through the integration and functional testing. It is well-suited for API and endpoint testing. This tool will be implemented through the GitHub pipelines and the implementing team will create the project, obtain an id and add that ID to the pipeline. Once added, the test will kick off with the defined test automation parameters on Octoperf. The results will be delivered back to the repository and into the pipeline so the team will have an output of the results.

Overall Process

  • Team wants to use the cloud

  • Elicit value from team and objectives

  • Create or reuse existing cloud resources

  • Create, reuse, transition to GitHub

  • Migrate code to GitHub

  • Devops scans code looking for Critical and Major vulnerabilities

  • DevOps runs tests on the pipelines using Sentinel

  • Test automation created using OctoPerf