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 labeled Pending 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