Workflow for Full Project Sprints with a Single Developer

This is what we’re using as a template to follow when working on full project sprints that have a single developer.

The following sprint workflow is a work-in-progress.

Setup in Github

  1. Create a new milestone for the sprint (ex. Sprint 104)
  2. First issue created for that milestone will be a “Sprint Success” issue. This will be used to document general launch procedures, launch procedures specific to this sprint, as well as any sprint management notes.
  3. Scope out the sprint by assigning issues to that milestone and getting the work for the sprint approved by client
  4. Link the approval email from the client as a comment in the “Sprint Success” issue along with a checkbox list of the items stated in the email for the sprint.

Branching

  1. Create a new branch, off of master, for the sprint and label it “sprint{#}” (ex. sprint104)
  2. Commit code to the sprint branch while referencing the associated issue at the end of every commit
  3. When ready to send items to QA, run git push staging sprint104

Issue Flow

  1. After initial work on each issue is completed, the issue should be set to Pending QA and assigned to the person responsible for QAing the issue.
  2. If questions needed, the QA person will ask the question in a comment, assign the issue to whoever the question is addressed to, and label the issue with Question
  3. After discussion is complete or ticket passes QA, it will be set to Pending Merge
  4. Once sprint is merged into master, the Pending Merge issues will be labeled Pending Smoketest
  5. Once Smoketest is complete, issues will be marked as closed

Merging

  1. Merge will begin only after all issues associated with the sprint have been set to Pending Merge
  2. Before merging sprint branch into master, merge master into the sprint branch
  3. Create a pull request for the sprint branch to be merged into master
  4. Verify everything looks good on the Pull Request and merge

Deploying

  1. When readying to deploy, set a freeze on the main site
  2. Copy a new version of staging from the live site
  3. Verify that you have the latest version of master (git checkout master, git pull origin master)
  4. Deploy the updated master to the staging site (ex. git push staging master)
  5. Run smoketest on the staging site, ensuring all the associated changes have made it to the site and are working as expected.
  6. Once all the issues pass QA on staging, perform the general launch tests as well as any site specific tests listed in the “Sprint Success” issue.
  7. Once everything passes, deploy staging to live
  8. Verify changes on live and do a holistic QA Pass

Closing the sprint

Once everything has been deployed and passed QA, the project manager will:

  1. Send email to client to verify the work is complete
  2. Link to the confirmation email within the “Sprint Success” issue and close that issue
  3. Close the milestone
  4. Delete the sprint branch
Exit mobile version