workflow.md

Workflow

We use Jira to track bugs and features and git flow to track changes to the code. The workflow for a ticket goes as follows:

1. The developer moves a ticket into the "In Progress" column, assigning it to themselves.

2. The developer creates a new branch off of develop (or another feature branch if necessary) naming it feature/REALM-XXXXX-description where "REALM-XXXXX" is the ticket number in Jira and "description" is a 1-3 word description of the ticket.

3. Any changes needed to fulfill the ticket are performed in 1 or more commits. Each commit should start with the ticket number, as in REALM-XXXXX Added link to make a gift. Prefixing the ticket number here causes the commit to appear in Jira.

   Sometimes a single ticket will have multiple commits directly related to it, and multiple commits with the ticket prefix. Other times, there will be a commits related to the ticket such as code cleanup or refactoring that are not directly related which may not include the ticket number. There should be a balance between keeping feature branches (and pull requests) focused and leaving code better than when you found it.

4. The developer pushes their feature branch to origin and then creates a pull request in GitHub to merge the changes into develop. If the commits are tagged properly, the pull request will appear in Jira.

   

5. The developer moves the ticket in Jira to the "Verify" column.

6. Another developer reviews the pull request for code quality and potential interference with the rest of the app, but is not responsible for the ticket actually being fulfilled. The reviewer leaves any comments on issues that need to be addressed before the request is closed. The reviewer either merges the pull request or closes it without merging, in which case the developer should fix any issues before reopening the same pull request.

   Once a pull request has been merged, the branch should be deleted to keep the repository clean. You can do this directly from GitHub when closing a pull request. If there is more work to be done on the branch for future pull requests, the developer can simply re-push the branch.

   If there is no one available to close a pull request before the end of the sprint, the original developer should close the request themselves. The pull request should still be created though, to leave a history for other developers when they return.

7. Once the pull request is merged in, it will appear as "MERGED" in Jira. At the same time, the Xcode Server will see changes to develop, run tests, and if the build succeeds upload a new build to TestFlight. This should only take a few minutes. While TestFlight might take longer to process a new build, once the change has been integrated by the Xcode Server, the app can be installed directly from there using the web interface.

   

   Once a build is available, a tester should install the latest build and verify the ticket. If the ticket has been fulfilled, it should be moved to the "Done" column. If it has not been, it should be moved to the "To Do" column, and the developer should start the workflow over again. Note that Jira can track multiple pull requests for a single ticket.

Some changes may not have a specific Jira ticket such as adding more unit tests, non code changes like documentation, automation, or general refactoring. In which case steps 2, 3, 4 and 6 should be followed.

This is really good. It captures the procedures that we have been doing for the last few months and the additional continuous integration that was recently added. Hopefully other teams can learn from this.

I would add under 6.) After the reviewer merges the pull request, the branch can be safely removed. This keeps the remote repository cleaner and you can easily recognize branches actively being developed.