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

Configure:Orchestration 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 Orchestration 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 as well as running applications that are 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.

Team Members

Backend Team

Person Role
New Vacancy - Seth Engelhard (Interim) Engineering Manager, Configure:Orchestration
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

Frontend Team

Person Role
Jean du Plessis Frontend Engineering Manager, Configure
Mike Greiling Senior Frontend Engineer, Configure
Jacques Erasmus Senior Frontend Engineer, Configure
Enrique Alcántara Senior Frontend Engineer, Configure

Stable Counterparts

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

Person Role
Taurie Davis Staff Product Designer, Configure
Daniel Gruesso Product Manager, Configure:Orchestration
Dan Davison Senior Software Engineer in Test, Configure
Evan Read Senior Technical Writer, Manage, Verify, Configure, Growth
Viktor Nagy Senior Product Manager, Configure:System Group
Maria Vrachni Senior Product Designer, Configure

Processes

Planning

We use planning issues to work out the planning for the next milestone asynchronously.

  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 for the next milestone
  3. The Engineering Managers reviews the issues to determine whether there will be sufficient capacity to deal with all the issues listed
  4. EMs also add bugs to the milestone that should be worked on based on Priority and Severity labels.

Example planning issue: https://gitlab.com/gitlab-org/configure/general/issues/6

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

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.

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.
    1. This is a good time to discuss and clarify interdependency between backend and frontend
  2. Backend and frontend will work on the issue in separated branches
    1. Each will submit their own MR for review
    2. Frontend and backend will put the feature behind a feature flag
  3. Once both MRs have been merged, a third MR will be opened to integrate the work where backend and frontend will collaborate to:
    1. Remove the feature flag
    2. Add documentation
    3. 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.

How to work with us

How to contribute to Auto DevOps

Read our specific GDK instructions on how to develop features for Auto DevOps.