Day to day

The Wilson Team sprint board in Gitlab is the primary source for work that is being done in a sprint. It shows what is currently in progress, what needs review, and what is available to be picked up by developers.

The issues on the sprint board, and in particular in the Sprint Ready column are organised by priority order (with highest priority at the top); they should always be picked up in this order, from top to bottom.

When a developer has finished their current work and is looking for something new to pick up they should do the following things in order:

1. Complete an issue in the Needs Deployment column you are the assignee for (see Deploying changes).
2. Re-review an MR you are reviewing where the assignee has responded.
3. Re-work an MR you are assigned to where the reviewer has left comments.
4. Take the top issue from the Review Required column and review it (see Reviewing an issue).
5. Take the top unblocked issue from the Sprint Ready column and start work on it (see Working on an issue).
6. If there is no work to pick up, talk to your team lead so they can add additional work to the sprint.

Important

Unfamiliarity with a service or project within Gitlab should not prevent any team member from picking up the top ticket in the sprint board lists to work on or review. If you feel you cannot complete an issue or a review without assistance, you should still pick the ticket up and take responsibility for the work or the review, and ask for assistance from more senior developers.

For reviews, you may wish to do a first pass then ask for a second review from a more senior developer. It is the reviewer's responsibility to make sure a complete review gets done, but not necessarily to complete the entire review themselves.

When working directly on unfamiliar projects, ask lots of questions, open draft MRs and request feedback, or ask for paired programming. It is the assignee's responsibility to push the ticket forwards, but not necessarily to do all the work by themselves.

If you are in the middle of working on an issue, or reviewing an issue, there is no need to stop working on it to pick up something higher in the list above that becomes available. For example, if you have picked up a new issue to work on, and the assignee for an MR you reviewed finishes responding, you do not need to stop work to re-review that MR.

Note

The procedure outlined above should be taken with a degree of common sense. Developers should continually be communicating with each other, and the above set of priorities does not prevent anyone asking for a review in the MS Teams dev channel as a priority if it unblocks other work.

Try not to ask for reviews in Teams as a matter of course, but reserve it for when getting the review done quickly will help speed up delivery. Developers should try to be responsive on Teams as much as possible, and work collaboratively and sensibly.

In some exceptional circumstances the top issue from the Review Required or Sprint Ready columns may not be appropriate for you (or anyone) to pick up. If that is the case, ask a more senior developer or the team lead for guidance. You should always reach out before circumventing the priority order of issues.

Note

Sometimes you may wish to pick up specific tickets to support personal development goals. If this is the case, it should be agreed beforehand with your team lead, and the ticket should generally be pre-assigned to you at the start of the sprint. If the issue is particularly time-critical pre-assigning it may not be possible. It is the developer's responsibility to flag to the team leader at the start of the sprint any tickets which may support personal development.

Roles

The "Assignee" of an issue is responsible for:

• Understanding the issue (this may involve asking clarifying questions to senior developers).
• Working on any changes by opening MR(s) and assigning themselves to those MR(s).
• Deploying any changes made.
• Ensuring the issue moves from Sprint Ready to Done.
• Ensuring the issue is in the correct workflow state throughout its lifecycle.
• Closing the issue once all work is complete.

The "Reviewer" of an issue/MRs is responsible for:

• Ensuring the review process is followed.
• Ensuring the MR is eventually approved.

Working on an issue

This does not really deviate from the DevOps-wide flow. When an issue is picked up, you should assign yourself and add the workflow::In Progress label. You then become the "Assignee" of that issue.

You should typically not pick up tickets that are blocked by other tickets (indicated by a red stop sign in the issue card on the board). Some blocked tickets are "soft-blocked" by other tickets, these can often be worked on before the blocking ticket(s) is completed.

When opening an MR you should select yourself as the "assignee" of that MR.

Code change MRs should be raised using the "Wilson Standard Webapp MR" template. The sections in italics should be filled in by the assignee of the MR before moving the issue to workflow::Review Required.

Infrastructure change MRs should be raised using the "Wilson Standard Infrastructure MR" template. The sections in italics should be filled in by the assignee of the MR before moving the issue to workflow::Review Required.

For issues that require team review or discussion, it is the assignee's responsibility to arrange a meeting or post in the developer Teams channel to invite discussion. The issue assignee is responsible for collating and summarising the discussion.

Note

Required changes to infrastructure should be done as part of the general work on an issue, not reserved for the deployment stage.

In some exceptional cases a breaking change will need to be released at the same time as changes to infrastructure - in these cases the assignee should raise a separate deployment MR with the infrastructure changes and the deployment of the new release together in a single MR as part of the deployment process. Whereever possible, these kinds of breaking changes should be avoided.

Re-working an issue

Once an MR has been reviewed, and a review submitted, the linked issue should be moved back to workflow::In Progress. At this point, as the issue assignee, you should respond to the review comments left in the MR by making further changes or providing responses to the comments.

Once the re-work is done, notify the reviewer and move the issue directly back to workflow::Under Review. Notifying the reviewer should be done via a comment in the MR, or by requesting a re-review using the button in Gitlab.

Multiple MRs

If an issue requires multiple MRs, the assignee is responsible for moving it between the workflow states that make most sense as it is worked on. If it is moved to workflow::Review Required but not all MRs are ready for review the MRs not requiring review should be marked as Draft:. Explain in issue comments where MRs are interdependent, and clarify how the MRs will be merged and deployed together whereever this is necessary (although it should always be avoided if possible). You may want to make use of the merge request dependencies feature in Gitlab.

If an MR is approved, merged and deployed, but further changes are needed to meet the acceptance criteria, the assignee should move the issue back to workflow::In Progress and continue to work on it.

workflow::Blocked

The workflow::Blocked label is only for externally-blocked issues. Any issues that require input externally from the team should be moved into this state. Issues blocked by other issues in sprint or waiting for responses from other team members remain in their normal workflow states.

Reviewing an issue

When you pick up an issue to review you should assign yourself as a reviewer to all linked open non-draft MRs, at this point you are the "Reviewer" of an issue and are responsible for ensuring the review is completed. Move the issue to "Under Review" to mark that the issue is now being reviewed.

You should review the MR following the review checklist set out in the MR description. If you need more input on the review it is your responsibility, as the reviewer, to find additional reviewers and explain what is required from them, e.g. check specific parts of the code, do a second complete review, etc..

Review comments should be raised as part of the Gitlab review feature. Where possible, try to do a complete review and submit it for processing by the assignee, rather than raise many individual comments. The review should be submitted with the "Request Changes" option in Gitlab (which allows the assignee to request a re-review), unless no response at all is expected to the comments provided.

Once a review has been submitted, move the issue back to workflow::In Progress for the assignee to respond to.

Once all currently open non-draft MRs are approved, the reviewer's responsibility is complete, the issue can be moved to workflow::Needs Deployment, or back to workflow::In Progress if further MRs need completion. If the issue moves back to workflow::Review Required there is no expectation that the same reviewer reviews any new MRs.

Issues without MRs

Some issues will not have MRs. To review these, move them into "Under Review" as above, then comment in the issue with your thoughts on whether the issue is complete or not, or whether further work is required. Request any additional supporting evidence that is not already provided in the issue comments.

Some issues will need review from the whole team, or invite discussion. In these cases, anyone can and should add comments to the relevant threads in the issue. Once the assignee has provided a summary, one team member can then review the issue by checking that the team is in agreement and that the summary is accurate, then closing the issue and moving it directly to workflow::Done. If this is not the case, comment on any missing points of discussion or agreements still needed.

Deploying changes

Once an issue is ready to be deployed, the MRs should be merged and deployed as soon as possible.

This process is the responsibility of the issue assignee, and differs if the service has renovatebot configured this process is straightforward. If it does not, or if the release requires infrastructure changes alongside it, see the Manual deployment section below.

Once an MR is approved, it should be merged by the original assignee/author of the MR. This will create a release or a release MR (and if release-it is not configured a commit sha on the repository's default branch). If a release MR is created, the developer should assign themselves to review it, then approve and merge it if they are happy all the changes to be released are expected.

The assignee should then trigger renovatebot to raise an MR in the relevant infrastructure repository. If the gitlab group is configured with CI triggering this should happen automatically, shortly after the release is created. If CI triggers are not configured, renovatebot can be manually triggered using the "Dependency Dashboard" issue in the infrastructure repository.

Once the deployment MR has been created, the issue assignee should assign themselves as the reviewer of the MR. They should use the CI manual controls to deploy the change to development, and smoke-test that the changes made and released are working as expected. Once they have tested the deployment in development, they can approve and merge the release MR. The changes should be deployed automatically to staging, where they should be briefly checked again.

Once the assignee is happy that the deployment will succeed, they should then click the CI manual controls to deploy to production (if significant time has passed since the plan job ran against production it may need to be re-run).

After changes have been deployed the assignee will either close the issue or move it back to workflow::In Progress if there are further changes needed to meet all the acceptance criteria of the issue.

Manual deployment

If the project does not have renovatebot configured or if the release requires changes to the infrastructure alongside the release, the assignee must raise an MR against the infrastructure repository to release the changes to production. They should use the "Wilson Standard Deploy MR" template for the MR.

In this case, the assignee must request a more urgent review of the deployment MR by requesting reviewers in the MS Teams Wilson Developer's channel. Hopefully someone will pick this up to review as a priority, and then follow the standard review process, checking the deployment changes against development.

Once the reviewer has approved the deployment MR, the assignee should merge it into the infrastructure default branch and then:

1. Apply the changes to staging.
2. Smoke-test the changes and general functionality of the service in staging.
3. Apply the changes to production.

Deployment failures

If a deployment fails, it must be resolved immediately as a priority. Leave the issue open, and move it back to workflow::In Progress to resolve.

If the failure is unrelated to changes in your MR, or takes significant time to fix, or has impacted users significantly raise an incident for the deployment failure, using the standard Wilson Incident process, and assign yourself to that incident. Investigate and fix the deployment problem, involving other developers to troubleshoot and assist as needed.

It is the issue assignee's responsibility to ensure that changes are successfully deployed to production.

Closing an issue

Once all changes required to resolve an issue are complete and fully deployed to production (where appropriate) the issue can be moved to workflow::Done and closed.