Developer workflow
This page summarises the information presented in this section from the point of view of the developer and in terms of GitHub operations. We assume that a task in the To do column of the task board has already been assigned to you.
Create readiness checklist
Edit the description of the GitHub issue and paste in the content shown below. It consists of a series of level 1 headings that correspond to the items in the DoR
1 2 3 4 5 6 7 8 9 10 |
|
1 2 3 |
|
Elaborate the requirements
The description of the issue at the outset is likely to be relatively high level. This is where you break the issue down into individual tasks which you should add to the issue description as a task list. Later, you should check off easch task as it is completed. You can use the example below as a template for the task list.
1 2 3 |
|
Confirm readiness
Review the completed DoR checklist with the project manager. If there are any issues, they will need to be resolved before moving on. Assuming everything is OK, this is point where the task is moved into the In progress column of the task board.
Create development comment
Create a new comment entitled Development notes. This is for recording any useful information about the issue as you work through the development. There is no set format for this comment since each issue will have different concerns.
You can copy the template below and paste it into the new comment.
1 2 3 |
|
Development
You should be making code changes on a separate branch as required by the DoR. As you proceed, you should be
- Making notes in the development comment
- Checking off tasks in the issue task list
- Updating documentation as needed
- Writing and running unit tests as needed
- Commiting your work regularly - at least once a day
- Ensuring that you use descriptive commit comments
- Ensuring that you reference the GitHub issue number in the commit comment (e.g. #74)
Create deployment comment
As you work through the development, you may become aware of some steps that need to be taken at the point that your changes are deployed. This could include, for example, configuration changes that are not part of the codebase, unusual database operations, information to be communicated to testers, etc. If there are any issues that fall into this category, you should create a deployment comment to document them.
You can copy the template below and paste it into the new comment.
1 2 3 |
|
Create a pull request
Create a pull request (PR) in GitHub. In the panel on the right of the PR creation page, you should
- assign an appropriate person to review your changes
- associate the PR with the relevant project
- link the PR to the related issue
In the text of the PR, paste the DoD check shown below and tick off the items that have been completed. If any of them warrant any additional notes, you can add them below the relevant list item.
1 2 3 4 5 |
|
Fix any issues raised by the reviewer
You can add further commits to an open PR. Just follow the same procedure as usual which is described in the Development section above.
Mark issue as approved
Once the reviwer has approved the changes, move the issue to the Reviewer approved column on the project task board.