Common flows¶
This page lists common tasks that one might do as a member of DevOps and the flows that one does when performing them.
Tip
These flows are far quicker if you make use of GitLab quick actions for issues and merge requests.
What shall I do?¶
If you have nothing else to do, you can find something to do in the following ways:
- Look at the board and start work on an open unclaimed issue.
- Go to the issues
list and
search for open issues, assigned to you with the
workflow::rework
label. These are issues which you may need to do extra work on. - Go to the issues
list and
search for open issues, not assigned to you with the
workflow::review required
label. These are issues which you may be able to review. - Go to the issues
list and
search for open issues, not assigned to you with the
workflow::needs testing
label. These are issues which you may be able to test and merge.
Starting work on an issue¶
Issues which are on the far left of the board (the "sprint ready" column) and which are unassigned are free for people to pick up. In the issue life cycle these are known as "sprint ready" issues.
- Select an issue from the board.
- Assign it to yourself.
- Add the
workflow::in progress
label. - Work on the issue. If the work involves a code change, see the making code changes flow.
- When ready for review, add the
workflow::review required
label. - Add an estimate of the time spent addressing the issue.
Making code changes¶
When picking up an issue, it may require code changes in one or more repositories.
- In the target repository, make sure
master
is up to date:
git checkout master
git pull
- Create a feature
branch in which to
work. Name the branch
issue-{issue number}-{summary}
. For example:
git checkout -b issue-150-fix-incorrect-docs
- Develop the feature.
- Push the branch back to GitLab:
git push -u origin issue-150-fix-incorrect-docs
- GitLab will respond with a link to create a merge request for the new branch.
Visit the link and make sure the merge request is configured in the following
way:
- Requires at least one approver.
- Delete source branch after merging.
- If your merge request in and of itself entirely addresses the issue, you can automatically close the issue by adding "Closes #[issue number]" to the merge request description. (In GitLab terminology, these are called issue closing patterns.)
- If your merge request helps an issue but does not entirely address it, mention the issue but do not use an issue closing pattern. For example: "this MR helps us with #[issue number]".
- Assign yourself to the merge request in addition to the issue. A reviewer can add themselves as a Reviewer.
- Add the
workflow::review required
label to the issue which the merge request addresses. Do not add the label to the merge request.
Reviewing issues¶
Open issues labelled workflow::review required
are open to be reviewed.
Important
You should always add the time you spend reviewing merge requests to the related issue and not the merge request.
There are two classes of issues: ones with associated merge requests and ones without.
Issues with no related merge request¶
For issues without a related merge request, you should be able to review the issue directly.
- Go to the issue and determine if the work completed addresses the issue.
- If the work addresses the issue, close the issue.
- If the work does not address the issue, leave a comment explaining why and
add the
workflow::rework
label.
Issues with a related merge request¶
See also the dedicated merge request page page for more information.
Warning
The various workflow::...
labels are used to reflect the progress of the
issue in the board. Merge requests do not appear on the board and so
workflow labels should only ever be set on the issue.
- Go to the issue and select a related merge request which a) has no Reviewers or b) you are set as a reviewer.
- Add yourself as a Reviewer of the merge request, if necessary.
- Review the code.
- If you are happy with the code, approve the merge request and add the
workflow::needs testing
label to the related issue. - If unhappy, make sure the review describes what should be done, add the
workflow::rework
label to the related issue, assign the merge request to the original author and stop work on the merge request for the moment. - Test the merge request.
- If happy, merge.
- If not happy, explain why, add the
workflow::rework
label to the related issue, assign the merge request to the original author, remove your approval of the merge request and stop work on the merge request for the moment.