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
- Create a new milestone for the sprint (ex. Sprint 104)
- 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.
- Scope out the sprint by assigning issues to that milestone and getting the work for the sprint approved by client
- 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
- Create a new branch, off of master, for the sprint and label it “sprint{#}” (ex. sprint104)
- Commit code to the sprint branch while referencing the associated issue at the end of every commit
- When ready to send items to QA, run
git push staging sprint104
Issue Flow
- 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. - 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
- After discussion is complete or ticket passes QA, it will be set to
Pending Merge
- Once sprint is merged into master, the
Pending Merge
issues will be labeledPending Smoketest
- Once Smoketest is complete, issues will be marked as closed
Merging
- Merge will begin only after all issues associated with the sprint have been set to
Pending Merge
- Before merging sprint branch into master, merge master into the sprint branch
- Create a pull request for the sprint branch to be merged into master
- Verify everything looks good on the Pull Request and merge
Deploying
- When readying to deploy, set a freeze on the main site
- Copy a new version of staging from the live site
- Verify that you have the latest version of master (
git checkout master
,git pull origin master
) - Deploy the updated master to the staging site (ex.
git push staging master
) - Run smoketest on the staging site, ensuring all the associated changes have made it to the site and are working as expected.
- 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.
- Once everything passes, deploy staging to live
- 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:
- Send email to client to verify the work is complete
- Link to the confirmation email within the “Sprint Success” issue and close that issue
- Close the milestone
- Delete the sprint branch
Leave a Reply