2. Release Workflow
2.1. Prerequisites
Tickets are specified and in “Selected for Development” status in Jira.
2.2. Workflow
Release Start: the team lead will indicate the start of the release on Slack. Everyone in the team is expected to choose the tickets they want to work on and any remaining ones will be assigned by the team lead afterwards. The team lead will share a planning document with everyone on Slack.
The team lead should read all tickets to be able to discuss them with the team. If anything is unclear, a discussion with the Pearl team might be necessary.
Understand requirements: Before planning, everyone in the team should have a call or discuss on slack any items that are not clear about their tickets. This is expected to not take too much time since the goal is understanding the requirements.
Set approver for all tickets: once requirements are clear, the assignee should set the approver for the ticket. Setting the approvers helps in the reviewer estimate the time needed for review.
Planning: the assignee should prepare a plan for every ticket (big or small) in the shared planning document where everyone has access. This will help the reviewers estimate the time needed for review.
Planning discussion and approval: this happens between the assignee and the team lead. The planning should also indicate if ticket needs to be separated into multiple PRs for easy review and which PR covers which part of the planning.
If the ticket has work on completely separate features then we can separate it into multiple tickets.
Set time estimate and due date: once the planning is approved, the assignee needs to set the time estimate and due date for the ticket. When setting the due date, the assignee needs to account for any time necessary to review other tickets where they are the approver.
The team lead is expected to give feedback on time estimate (if necessary) after all time estimates are set.
Implementation: the team lead should discuss with author when there are delays and no communication.
Review: Each ticket will have 2 reviewers (the approver and a second reviewer). The assignee has to move the ticket in Jira to “SC Test” so that the approver is notified about that. Also, in github, a PR should be opened and the developer should request a review from the approver on github as well. If the work passes the approver review, the approver should mark the PR as approved and request a review from the second reviewer.
If there is any feedback from a reviewer (first or second reviewer), they should leave it on github (request changes) and move the ticket back to “Selected for development” in Jira.
time for review:
within a day at most for tickets that have 1 PR from review request
within half a day for tickets with multiple PRs
Merging: When the second reviewer approves the PR, the first reviewer is responsible for merging the ticket. You can find guidance for merge steps in this link.
2.3. The second reviewer
Each PR will have 2 reviewers, the first one is set as the approver of the ticket in Jira and the second one is the same for all PRs in the release. Here are a few notes about the second reviewer:
They are, as the name suggests, the second one to review the PR on github
responsible for reviewing all PRs in the release
responsible for taking care of any hotfixes that are discovered. This includes communication with the Pearl team around:
what is the root cause of an issue
how to reproduce it
what is the fix and,
when the hotfix will be ready for deployment
They should be proactive about investigating any issue that appear in the outage channel, no need to wait for the Pearl team to ask about the issue, they should just add a comment that they are investigating the issue.
For the tickets that the second reviewer works on, they will be reviewed only by 1 reviewer.
The second reviewer position is not permanent, the second reviewer can be changed in case things didn’t work out well for them or a different team member expressed interest and has the skills/experience to take this responsibility. Still, it should be noted that anyone starting it, will try it for at least 3 or 4 releases (about 2 months).
The reason for having only one person as the second reviewer is that they will need to investigate bugs that happen in production and for that they will need to have an idea about all the features developed in the release. Also, we want to avoid cases where we need to figure out who should be working on the hotfix before even starting the investigation.
Also, for the initial hotfixes, the team lead or a previous second reviewer will help in investigating issues. That way they can guide the new second reviewer during the investigation and implementation processes. Once things are on track, the second reviewer will have the ability to merge hotfixes by themselves to master, so they no longer need any help.
2.4. Meetings in a release lifetime
Planning meeting:
parties involved: team lead and one team member
when: at the start of the release before starting any implementation
purpose: discuss the plan of the tickets assigned to the team member and make sure that all work requested is covered in the plan
Huddle meeting
parties involved: team lead and all team members
when: every other day
purpose: A check-in where we discuss the progress of the release work and any questions around the work.
Meeting with the Pearl team
parties involved: team lead, all team members and the Pearl team
when: weekly meeting
purpose: go over any questions about the release and discuss any issues bugs that arise. The agenda for the meeting can be found here.
Release Showcase
parties involved: team lead and all team members
when: at the end of the release
purpose: demo the features implemented during the release.
Retrospective meeting
parties involved: team lead and all team members
when: at the end of the release
purpose: go over what went well and what needs to change during the release.