For an understanding of where this team is going, take a look at the product vision.
As a member of the Ops Sub-department, you may also like to understand our overall vision.
The Configure group is responsible for developing Ops-focused features of GitLab that relate to the "Configuration" and "Operations" stages of the DevOps lifecycle. These refer to the configuration of infrastructure, and the running of applications deployed via GitLab.
This team is currently building out more features for our Kubernetes integration, including the Auto DevOps feature set, and making it easier for GitLab users to make the most of Kubernetes and DevOps best practices.
As per the product categories, this team is responsible for building out new feature sets that will allow GitLab users to easily make use of the following modern DevOps practices:
We work collaboratively and transparently, and we will contribute as much of our work as possible back to the open source community.
We measure the value we provide by the number of deployment pipelines going through our infrastructure management features (either K8s, Auto DevOps, Serverless or IaC in general). We believe that this is a good measure for the customer value as in the end our users want either their infrastructure or something on their infrastructure to be deployed.
We break down this metric into input metrics by product category and might come up with further breakdown of the metrics when necessary.
|Nicholas Klick||Backend Engineering Manager, Configure|
|Thong Kuah||Staff Backend Engineer, Configure|
|Hordur Freyr Yngvason||Backend Engineer, Configure|
|João Cunha||Backend Engineer, Configure|
|Tiger Watson||Senior Backend Engineer, Configure|
|Mikhail Mazurskiy||Senior Backend Engineer, Configure|
|Serena Fang||Backend Engineer (Intern), Configure|
|Matt Kasa||Senior Backend Engineer, Configure|
|Emily Ring||Backend Engineer, Configure|
The following members of other functional teams are our stable counterparts:
|Justin Mandell||Product Design Manager, Package, Configure, and Monitor|
|Dan Davison||Senior Software Engineer in Test, Configure|
|Evan Read||Senior Technical Writer, Configure|
|Viktor Nagy||Senior Product Manager, Configure|
|Maria Vrachni||Senior Product Designer, Configure|
|Kevin Chu||Group Manager of Product Management, Configure & Monitor|
We use planning issues to work out the planning for the next milestone asynchronously.
Example planning issue: https://gitlab.com/gitlab-org/configure/general/issues/6
Our goal is to move towards a continuous delivery model so the team completes tasks regularly, and keeps working off of a prioritized backlog of issues. We default to team members self-scheduling their work:
workflow:ready for developmentcolumn.
workflow:ready for developmentissue.
In addition to the self-scheduling of feature development, the manager will from time to time assign bugs, or other work deemed important, directly to a team member.
We rely heavily on iteration as part of our workflow and aim to deliver the smallest possible MVC in the shortest period of time.
We use the following practices to enhance iteration on our team:
Team members should use their best judgment to determine whether to assign the first review of an MR based on the DangerBot's suggestion or to someone else on the team. Some factors in making this decision may be:
Our team follows the GitLab workflow guidelines for working in teams.
Given a reasonably sized issue requiring UX, frontend and backend work, the preferred way to collaborate on the issue is as follow:
workflow::ready for development, backend is usually able to start working on the issue.
The above is a guideline and clear communication should be preferred over process to ensure the best collaboration strategy on an issue. For example on smaller issues, or where the frontend component of the work is minor, it may be feasible to work on the same branch.
Read our specific GDK instructions on how to develop features for Auto DevOps.