Gitlab hero border pattern left svg Gitlab hero border pattern right svg

Configure:System Group

Vision

For an understanding of where this team is going take a look at the product vision.

As a member of the Ops Section you may also like to understand our overall vision.

Mission

The Configure System 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 Serverless functions and applications deployed via GitLab as well as Infrastructure as Code (IaC), ChatOps, and Runbooks.

Major efforts thus far have focused on empowering developers to build Serverless applications with Knative.

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.

Team Members

Backend Team

Person Role
Nicholas Klick Engineering Manager, Configure:System
Grzegorz Bizon Staff Backend Engineer, Configure:System
Matt Kasa Senior Backend Engineer, Configure:System
Alishan 'Ali' Ladhani Backend Engineer, Configure:System
Alex Ives Senior Backend Engineer, Configure:System
Magdalena Frankiewicz Backend Engineer, Configure:System

Frontend Team

Person Role
New Vacancy - Clement Ho (Interim) Frontend Engineering Manager, Configure
Mike Greiling Senior Frontend Engineer, Configure
Jacques Erasmus Senior Frontend Engineer, Configure
Enrique Alcántara Senior Frontend Engineer, Configure
Emily Ring Frontend Engineer, Configure

Stable Counterparts

The following members of other functional teams are our stable counterparts:

Person Role
Taurie Davis Staff Product Designer, Configure
New Vacancy - Nicholas Klick (Interim) Engineering Manager, Configure:Orchestration
Daniel Gruesso Product Manager, Configure:Orchestration
Dan Davison Senior Software Engineer in Test, Configure:Orchestration
Evan Read Senior Technical Writer, Manage, Verify, Configure, Growth
Thong Kuah Senior Backend Engineer, Configure:Orchestration
James Fargher Senior Backend Engineer, Configure:Orchestration
Hordur Freyr Yngvason Backend Engineer, Configure:Orchestration
João Cunha Backend Engineer, Configure:Orchestration
Tiger Watson Senior Backend Engineer, Configure:Orchestration
Viktor Nagy Senior Product Manager, Configure:System Group
Maria Vrachni Senior Product Designer, Configure

Processes

System Team Issue Workflow

  1. Issue is Created
  2. Solution is validated
  3. Issue is Groomed
  4. Issue is estimated
  5. Adding to a Milestone
  6. Issue is worked on by team
  7. Issue is tested

Key Takeaways:

  1. Issues must be groomed and estimated before being added to a milestone
  2. In order to make sure milestones are not too full, we track the amount of work we accomplish in each milestone and use that to determine the size of the next one.

New Issues

Before being added to the backlog, an issue is first assesed by the team's product manager to ensure that it meets minimum standards and is a good fit for the teams skills.

Grooming

Once an issue has been accepted by the product manager, the issue is groomed by either the EM or another member of the engineering team. This process involves checking for 3 things:

  1. Problem Statement
    In the case of a bug, this might be reproduction steps, in the case of a New feature, this may be a statement from a persona. In the case of a sub-task, this should include the end goal along with the specific portion of that goal we wish to accomplish.
  2. Definition of Done
    In the case of a bug, this should be the expected behavior. In the case of a new feature, this should be a list of expected things and any necessary mock-ups for new UI/UX components.
  3. Relevant Background Information
    In the case of a bug, this may be previous instances of a bug, links to other issues, or server or job logs from the time period when it occurred. In the case of new features, this may be links to user research, parent issues, or a deeper explaination to give context for the feature. In the case of a sub-task, this should be at a minimum, a link to the parent to provide broader context.

The goal of grooming is threefold:

Estimation

We estimate all issues before adding them to a milestone in order to ensure we have a good sense of how much work is added to an individual milestone.

For an item to be considered for a milestone, it must first be estimated by a member of the team. That person will add an issue weight.

Milestone Planning Time

We use planning issues to work out the planning for the next milestone asynchronously. We strive as a team to only plan as much work as we think we can deliver.

Example planning issue

When planning a milestone, we'll look back at how many items of each size we accomplished in the last three and consider that when we plan. We'll also take into account any changes in team size or vacation. Using this information we'll begin to cultivate a data driven approach to milestone planning so we can be confident in what we plan to deliver.

Planning Process

  1. The PM opens up a new milestone planning issue at the start of every milestone and lists the issues that we should be working on in priority order.
  2. All stakeholders (PM, UX, Engineering) are invited to collaborate on the planning issue for the next milestone.
  3. A sync meeting is held to discuss and debate the planning issue. All stakeholders collaborate on solution validation.
  4. For any issue that is not fully groomed, the PM assigns those issues to the EM for further clarification or grooming.
  5. The EM may work with Engineers to groom and validate these issues.
  6. The EM reviews the issues to determine whether there will be sufficient capacity to deal with all the issues listed.
  7. EM also add bugs to the milestone that should be worked on based on Priority and Severity labels.
  8. The EM assigns workflow::ready for development to issues that are fully groomed.

Milestone Execution

Where Team Members Pull Work

Developers only take work labled as workflow::ready for development and in the following order:

  1. Issues in the current milestone
  2. Issues from the top of the prioritized the backlog

Urgent Work

As a team, we recognize that sometimes urgent issues happen outside of the regular planning process. When this happens, urgent issues should still go through the grooming and estimation phases. Once marked workflow::ready for development, those issues should be added to the milestone and another issue of the same or larger size should be removed.

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.

Issue testing

In order for an issue to be considered "Complete", it must be verified in production.

Scheduling

Feature development

Our goal is to move towards a continuous delivery model such that the team completes tasks regularly and keeps working off of a prioritized backlog of issues and as such we default to team members self-scheduling their work:

Bug fixing and priortized work

MR reviews

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:

Backend & Frontend Issue Collaboration

Our team follows the GitLab workflow guidelines for working in teams.

Given a reasonable sized issue, that requires UX, frontend and backend work, the preferred way to collaborate on the issue is as follow:

  1. Once an issue is labeled workflow::ready for development, backend is usually able to start working on the issue.
  2. This is a good time to discuss and clarify interdependency between backend and frontend
  3. Backend and frontend will work on the issue in separated branches
  4. Each will submit their own MR for review
  5. Frontend and backend will put the feature behind a feature flag
  6. Once both MRs have been merged, a third MR will be opened to integrate the work where backend and frontend will collaborate to:
  7. Remove the feature flag
  8. Add documentation
  9. Implement e2e tests for the feature

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.