# 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.

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 # Development environment is up-to-date # All existing tests pass # Development branch is created # Use cases are defined and documented # Acceptance criteria are defined # Any database changes are identified and documented # Any dependencies/impacts are identified and documented # The issue has been elaborated # Tests have been identified and documented # Each task is feasible 
As you go through the list, document any important information in the appropriate section. This should be done in the form of a series of checlist items that can be ticked off as youy deal with them. You can use the example below as a template for creating a checklist.
 1 2 3 - [ ] Task 1 - [ ] Task 2 - [ ] Task 3 
You can also add notes below each checklist item as required.

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 - [ ] Task 1 - [ ] Task 2 - [ ] Task 3 

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 notes Your content here... 

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
• 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 # Deployment notes Your content here... 

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 - [ ] All acceptance criteria are met - [ ] Unit test coverage > 70% - [ ] Functional tests passed - [ ] Limitations are documented - [ ] Documentation is updated 
Once the PR has been opened, move the issue to the Review in progress column on the project task board.

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.