One of the coolest things about working at GitLab is that every line of code I write is source-available, and most of it is open source.
As a result, my public contributions to GitLab serve as an unusually detailed record of my professional work:
Below are some of the highlights of my time at GitLab, complete with links to all the nitty-gritty details.
One of the most interesting features I helped build during my first year at GitLab is merge trains, a conceptually simple feature with a lot of behind-the-scenes complexity. I wrote the majority of the frontend code for this feature; here’s a list of all the merge train-related merge requests I put together:
This feature was particularly fun to develop since I was part of the target audience!
When I joined GitLab, we had just started building out our GraphQL endpoint. Now, our goal is to make GraphQL the primary means of interacting programmatically with GitLab.
upcoming_releasefield to GraphQL
Then, I updated our frontends to use this new GraphQL data:
This conversion made it easier to implement some frontend performance improvements:
The part I’m most proud of? Despite swapping out the entire backend of the Releases page, no one’s seemed to notice 😀
As of GitLab 12.5, Releases can be associated with one or more Milestones. Developing this feature involved lots of small changes throughout the codebase:
When I joined GitLab, Releases could only be created or modified using the Release API. This (still ongoing!) effort helped make Releases simpler to use:
Originally, the only way to view GitLab Releases was on the Releases page, which showed all Releases for a given project. This feature added a new page — a Release page — that displayed a Release individually:
Some modification to make the Releases page more valuable:
As part of our effort to make Releases more useful, we added the ability to search for issues and merge requests by Release:
DORA 4 is a set of metrics that gauge the health of a DevOps team. I implemented DORA 4 charts within GitLab, and played a significant role in the design of the API.
Every once in a while I step outside the boundaries of the Release Management group and fix something that bugs me:
This could probably fit into the “quality of life” category above, but it’s consumed enough of my time that it’s worth calling out separately.
I care a lot about keyboard accesibility, and I’ve taken it on myself to make sure GitLab has best-in-class keyboard support.
I recently implemented a few nice-to-have shortcuts:
And I’m currently working on a much more ambitious redesign of how we implement shortcuts: