For an understanding of what this team is going to be working on take a look at the product vision.
The Release:Release Management is focused on all the functionality with respect to Continuous Delivery and Release Automation.
This team maps to Release devops stage.
See our jobs-to-be-done (JTBD) and their corrresponding grade here.
The following people are permanent members of the Release Team:
|Nicole Williams||Frontend Engineering Manager, Release (CD)|
The following members of other functional teams are our stable counterparts:
|Orit Golowinski||Senior Product Manager, Release|
|Nick Gaskill||Senior Technical Writer, Release, Secure (Fuzz Testing), Protect|
|Kevin Chu||Group Manager of Product Management, Configure, Monitor, Release|
Like most GitLab backend teams, we spend a lot of time working in Rails on the main GitLab CE app, but we also do a lot of work in Go which is used heavily in GitLab Pages and the Gitlab Release CLI. Familiarity with Docker and Kubernetes is also useful on our team.
We are always striving to improve and iterate on our planning process as a team. To maximize our velocity and meet our deliverables, we follow a planning process for each release. For more information about that process visit our planning page.
Issues that contribute to the release stage of the devops toolchain have the
The group's primary Slack channel is
#g_release-management, and the public managers channel is
#release-managers. We also support a number of feature channels for discussons or questions about a specific feature area. We no longer support issue specific channels, as they are easy to lose track of and fragment the discussion. Supported feature channels are:
We hold recurring office hours to give community members a chance to discuss any questions, issues, or merge requests. For details about upcoming office hours, check out the epic or the playlist on GitLab Unfiltered.
The Release Management engineering team will work with the Product Manager to regularly triage issues that are viable candidates for community contribution. There are a few ways that team members can assist with contributions, primarily by:
If a merge request becomes a high priority task and the contributor has become less active or stalled, consider adding an explanation comment and finishing the merge request. Always remember to give credit and appreciation to the community contributor in order to encourage future participation.
The Release Management Team Workflow board can be used to track features as they make their way from idea to production. This board details the various stages an issue can exist in as it is being developed. It's not necessary that an issue go through all of these stages, and it is allowed for issues to move back and forward through the workflow as they are iterated on.
Below is a description of each stage, its meaning, and any requirements for that stage.
workflow::ready for development
UX Readylabel, as well as either
backendor both labels to indicate which areas will need focus.
In order to make sure sprints are effective as possible, it is important to ensure issues are clearly defined and broken down before the start of a sprint. In order to accomplish this, engineering evaluation will take place for issues that require it (small changes and bug fixes typically won’t require this analysis). Engineers will look for assigned issues with the
workflow::planning breakdown label that have user stories defined, as well as functional, performance, documentation, and security acceptance criteria. See Build phase of the Product Development Workflow.
Assigned engineers will work with Product, UX and other engineers to determine the implementation plan for the feature.
Once an implementation plan has been finalized, the following steps should be taken:
workflow::ready for development.
As a byproduct of the engineering evaluation process, a rough estimate of the number of merge requests required to develop a feature will be produced. This measure can be used as a way to determine issue weights. These weights can be useful during the planning process to get a rough gauge of how many features can be worked on in a milestone, and to understand how much work the team can do in a milestone. This metric also aligns with the throughput metric currently measured by engineering teams.
If you have no idea where to begin the development due to lack of knowledge on the context or you're less confident on the current technical proposal, it might be better to work on Proof-of-Concept MR (PoC or Prototype) at first. This gives you more insights on the current implementation details and potential required changes.
This step removes a lot of "if"s from your assumptions. When you're making a technical proposal, often you don't have enough time to investigate the actual implementation details. In such case, you're assuming like "Probably, this feature works like …" or "Probably, this feature and that feature are connected like …", which leaves some probability in your development plan, and if it turned out a wrong assumption, you may need to rethink the whole approach, even though you're at the middle of development cycle. PoC step derisks such a turnaround by cross-checking the technical proposal with domain/performance/security experts and UX/PM.
Here is how to work on PoC step:
Technically, if you've done a PoC step, there is no need to ask additional reviews in actual MRs as long as you don't change the feature behavior. You can simply focus on general engineering review or documentation review, only. For example, improving code quality, refactoring code, writing tests, writing documents, etc.
This is an issue template for feature development. It includes some important engineering tasks to be done in general.
``` ## Technical proposal ## Feature Flag This feature is implemented behind `feature-flag-name` feature flag and disabled by default. Once we've confirmed the feature is deemed stable, we remove the feature flag in order to publish the feature as GA. ## Planned MRs ### Backend - [ ] [MR-1 title](MR link if it already exists) - [ ] [MR-2 title](MR link if it already exists) ### Frontend - [ ] [MR-1 title](MR link if it already exists) - [ ] [MR-2 title](MR link if it already exists) ### General - [ ] [Write a feature spec to test frontend and backend change altogether](MR link if it already exists) - [ ] [Remove the feature flag and update documentation](MR link if it already exists) # i.e. publish the feature ```
This is an issue template for feature evaluation. It includes some important engineering tasks to be done in general.
When you enable a feature via feature flag and expect a significant impact on user workflow or production load, you should create an issue with the following template to communicate better with the affected users or SRE.
``` ## Summary ## Feature details ## Timeline ## How to enable the feature ## How to disable the feature ## Beginning of evaluation - [ ] Announce in Slack/CompanyCall (T-minus 1 day) - [ ] Enable the feature ## End of evaluation - [ ] Announce in Slack/CompanyCall - [ ] Disable the feature ## Feedback/Metrics ### The second evaluation ### The first evaluation ```
Code reviews follow the standard process of using the reviewer roulette to choose a reviewer and a maintainer. The roulette is optional, so if a merge request contains changes that someone outside our group may not fully understand in depth, it is encouraged that a member of the Release team be chosen for the preliminary review to focus on correctly solving the problem. The intent is to leave this choice to the discretion of the engineer but raise the idea that fellow Release team members will sometimes be best able to understand the implications of the features we are implementing. The maintainer review will then be more focused on quality and code standards.
This tactic also creates an environment to ask for early review on a WIP merge request where the solution might be better refined through collaboration and also allows us to share knowledge across the team.
Since we are a remote company, we depend on asynchronous updates to communicate the status of our work. We currently use 3 methods to communicate with the team, two occur daily and one occurs weekly:
Our daily updates on progress and status will be added to the issues as a comment. A daily update may be skipped if there was no change in progress. It's preferable to update the issue rather than the related merge requests, as those do not provide a view of the overall progress.
The status comment should include what percentage complete the work is, the confidence of the person that their estimate is correct and, notes on what was done and/or if review has started. Finally, if there are multiple MRs associated with an issue, please include an entry for each.
A couple of suggestions to consider when adding your async updates:
Complete: 80% Confidence: 90% Notes: expecting to go into review tomorrow Concern: ~frontend
Issue status: 20% complete, 75% confident MR statuses: !11111 - 80% complete, 99% confident - docs update - need to add one more section !21212 - 10% complete, 70% confident - api update - database migrations created, working on creating the rest of the functionality next
The Geekbot Daily Standup is configured to run each morning Monday through Thursday and posts to
#g_release-management Slack channel. It has just one question:
Is there anything you could use a hand with today, or any blockers?
This check-in is optional and can be skipped if you don't need any help or don't have any blockers. Be sure to ask for help early, your team is always happy to lend a hand.
The Weekly Status Update is configured to run at noon on Fridays on the
#g_release-management Slack channel, and contains three questions:
What were your accomplishments this week?
The goal with this question is to show off the work you did, and celebrate merge announcements (merge parrot!). This could be a whole feature, a small part of a larger feature, an API to be used later, or even just a copy change.
What do you plan to work on next week? (think about what you'll be able to merge by the end of the week)
Think about what the next most important thing is to work on, and think about what part of that you can accomplish in one week. If your priorities aren't clear, talk to your manager.
Who will you need help from to accomplish your plan for next week? (tag specific individuals so they know ahead of time)
This helps to ensure that the others on the team know you'll need their help and will surface any issues earlier.
When going out of office (OOO), be sure to clearly communicate it with other people.
#g_release-managementas your backup to help distribute the workload.
Read more in the Paid time off page.