DevOps Community of Practice

GDCT has delivered a wide range of DevOps solutions such as self-serve repo creation, naming standards, Terraform quick start, Terraform modules and more. They have a significant backlog and it’s often the case that engineers in the IT community have issues they need fixed, additional functionality to add to existing GDCT-created resources or new technical solutions they would like to share with the IT community.

Currently, these engineer-driven requests are added to the GDCT backlog, prioritized and the engineers wait. Enabling engineer contributions will help bring needed solutions to market faster and reduce the GDCT backlog.

Think of it as open source development within Seagen IT - the DevOps Community of Practice (DCOP!).

Scenarios

Here are some common scenarios that support having a DCOP:

  • Any user of GDCT modules has a problem using a module. User sends a request to community for a workaround and/or fix.

  • An engineer using GDCT module observes or experiences a problem with a module. Engineer makes the fix and contributes it as a PR.

  • An engineer sees an opportunity to create a new module or modify an existing module. For a new module, the engineer uses the Create Repo automation to create a new repo for the module and pushes new code as a PR. Likewise, for an existing module, the engineer makes modifications and creates a PR.

  • An engineer sees an opportunity to improve a tool/process. Engineer proposes via a simple markdown template and submits it for review.

Governance

To contribute code and documentation, the engineering community will need access to DCOP-supported repos. In addition to common repo quality standards, we will have distinct responsibilities:

  • Engineers belonging to the DCOP are part of the DCOP_Contributors team. Members of this team have Write permissions to GDCT repos. This allows them to contribute code and documentation. Write permissions are to create PRs, there is no writing code directly into a protected branch.

  • Owners of DCOP resources have Admin permissions to GDCT repos. They are members of the DCOP_Admin team. They are the only ones that can merge PRs. They ensure that processes are followed in terms of code review, quality controls (e.g. snyk analysis), versioning, release notes and any other documentation.

Community Support

An integral part to have a successful DCOP is to have communication amongst its members. As Teams is the primary collaboration tool, we would have a DCOP channel with several sub-channels:

  • Sub-channel for Registry Modules. Purpose is for discussion on modules and notification of intent to create a new module.

  • Sub-channel for Terraform. Purpose is for discussion/peer help on Terraform practices, code sharing, etc.

  • Sub-channel for GitHub Actions. Purpose is for discussion/peer help on GitHub Action practices, code sharing, etc.

  • Module Updates. Purpose is for updates on new module releases and/or other merged community code. Notifications can be setup via webhook.

DRAFT FOLLOW-UPS

Still investigating a few things.

  1. Consider having GitHub Discussions enabled for DCOP supported repos. Gregg to investigate.

  2. Microsoft GA’ed their GitHub/Teams integration last week. Consider using that for the Teams integration instead of “Incoming Webhook” Teams connector. Douglas to investigate.

  3. Put some thought into having Snow requests come in to GDCT board versus using GitHub issues to populate the GDCT board (i.e. what Tony C demoed). There may be use cases for each (e.g. engineer vs non-engineer). Douglas/Gregg/Reviewers of this doc provide input to decide this.