Abstract
I joined a new program as it worked toward its first release. In one quarter I delivered all 16 of my tickets on time and reviewed 62 merge requests, including every change my team made for the release. I also introduced a merge request template that every repository in the program adopted.
Keywords: code review, test planning, infrastructure as code, Terraform, GitLab
Problem
I joined a new program as it worked toward its first release. The work spanned many GitLab repositories and several teams.
Merge request descriptions were inconsistent, and so were the unit and component tests from one repository to the next, with gaps in coverage. With the release on a fixed schedule, every change needed a careful review, and regressions had to be caught early.
Approach
Delivery. I ramped up quickly and took on tickets for my team. In one quarter I delivered 16 tickets and 20 merge requests, all on time for the release. Alongside feature work, I created and updated AWS infrastructure as code in Terraform and Terragrunt, and I wrote new tests and fixed broken ones as I went.
Review. I reviewed 62 merge requests in one quarter, including every change my team made for the release. I also reviewed every merge request the DevOps team made for the release and joined its planning meetings.
Process. I brought a merge request template from my previous program and drove it to quick adoption across every GitLab repository in the program. With a peer, I assessed the existing tests and wrote the program’s initial test plan, so tests would be consistent from unit level up to full system tests.
Result
Every ticket I owned landed on time for the release, and every change my team made for it got a review. The merge request template became the standard across the program, and the test plan gave it a path to consistent tests.
Table 1: One quarter of delivery and review.
| Measure | Count |
|---|---|
| Tickets delivered on time | 16 |
| Merge requests merged | 20 |
| Merge requests reviewed | 62 |