Skip to content

Commit 3e9dd55

Browse files
emmajaneemmajane
committed
Initial commit of resources
1 parent 00de359 commit 3e9dd55

File tree

4 files changed

+282
-2
lines changed

4 files changed

+282
-2
lines changed

‎README.md

Lines changed: 19 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1,4 +1,21 @@
1-
workflow-git-workshop
1+
Git for Teams of One or More
22
=====================
33

4-
Supporting files for workshops and sessions about Git.
4+
Supporting files for workshops and sessions about creating a
5+
developer workflow for your project (and your team) with the
6+
version control system, git.
7+
8+
## Contents
9+
10+
*/presentations*
11+
12+
Reveal.js slides for various workshops and conference sessions.
13+
14+
*/resources*
15+
16+
- [Sample sprint workflow 1](resources/workflow-sample-sprint-1.md)
17+
- [Sample sprint workflow 2](resources/workflow-sample-sprint-2.md)
18+
- [Sample release cycle
19+
summary](resources/relase-cycle-sample-1.md)
20+
21+
Created by [Drupalize.Me](http://drupalize.me).

‎resources/release-cycle-sample-1.md

Lines changed: 58 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,58 @@
1+
# Sample Release Cycle Documentation
2+
3+
## Sprints and Release Cycle
4+
5+
You'll notice that we have no time-based milestones in the ticket tracker. We are no longer doing sprints that last for two weeks, with a big release every third week. We do a new release on the site every Wednesday with whatever work is ready to go at that time. We now have three sites for our process; dev, QA, and live. Here's how it works:
6+
7+
Throughout the week, we do peer review of resolved tickets prior to the work getting merged into the dev branch.
8+
On Monday morning we take whatever is in the dev branch at that time and merge that into the QA branch. Dev work continues in the dev branch/site, while the QA site is updated with the latest code for release.
9+
We create the weekly QA checklist in hackpad by copy/pasting the QA user story from the tickets that were merged in the last week. (Every new ticket needs to have a QA user story as the first line of the ticket.)
10+
Everyone on the team QAs the tickets we've closed, as well as doing a general spot check of the site to look for bugs and regressions. We also have a suite of tests that get run, and a list of standard manual QA we must do every week. Any QA fails or regression bugs that are found are opened in the ticket tracker and put in the QA Fixes bucket so they can be addressed (fixed or reverted) prior to release.
11+
Wednesday morning we merge the qa branch into the master branch, tag it, and pull it onto the live site.
12+
Every Thursday we do a blog post sharing what we've accomplished during the last week.
13+
This system means that we are constantly making improvements to the site. We can also respond more quickly to member support issues that involve bugs or features on the site, which gives us a big customer support win. The other nice thing, in terms of morale and momentum, is that if you happen to miss getting your ticket into a release you don't have to wait three weeks to see it finally get on the site. It can simply go in the following week. Doing this in weekly bites also means that the QA list is relatively short and manageable.
14+
15+
Some may wonder at the PM overhead for weekly tickets and QA. As far as QA overhead, since we now require the QA test as part of the ticket itself, it's pretty easy to just get a list of the tickets that were merged within the last week, do a little copy/paste and you have your test list. Since it is only a week's worth of work we often only have about 20 tickets to test plus the 14 manual standard tests. We have at least four or five people doing QA, so an hour or two for each person covers our QA needs, and doesn't concentrate it all on one person.
16+
17+
## Branch Management
18+
19+
This is our branch management policy. We are basically following the Git workflow outlined in this blog post: http://nvie.com/posts/a-successful-git-branching-model.
20+
21+
### Workflow Branches
22+
23+
- **dev** this is the main development line, code created in a feature branch that has been reviewed by a peer should be merged to this branch. Regular feature/bug branches should be made from this branch.
24+
- **qa** code in this branch is in QA for the next scheduled release.
25+
- **master** this is the production ready, deployed to the live server code. Hotfixes should be made from this branch.
26+
27+
### Branch Types and Names
28+
29+
These are the conventions for the kinds of branches we use and naming them. NOTE: you should never use the master branch.
30+
31+
- **Ticket branches** (e.g. 1545-add-queue-button). Each ticket should have its own branch normally and these should be named as _ticket#-some-descriptive-name_.
32+
- **Feature branches** (e.g. add-guides) If you have substantial work on a set of tickets that go together feel free to make a new feature branch for it. You can name that branch with some sort of descriptive title, without a ticket number.
33+
- **Hot fix branches** (e.g. hotfix-614-quickfind). These should be used for all hot fix tickets, one branch per ticket. They should be named as hotfix-_ticket#-description_. Hotfix branches should always be branched from the latest tagged release.
34+
35+
## Ticket Assignment
36+
37+
For the other side of the PM work, sprint loading and ticket assignment, we've removed that almost entirely by implementing self-assigned tickets. There is no PM work to go through the backlog and load a sprint anymore. This obviously requires a lot of trust, and for the whole team to be on the same page about where our priorities lie. We're a small team, all focused on the same goals. The roadmap makes it clear what our priorities are, and we trust each other to make sure the work gets done.
38+
39+
People can work on any ticket in the ticket tracker, but the buckets are listed in order of priority, and we assign each ticket a relative priority level as well, so we know where we need to focus at least part of our effort every week. This lets people work on things that are personally interesting or bugging the hell out of them, while trusting they will also work on stuff that isn't fun, but we all know needs to get done. If there is a particular deadline for something, then that is communicated to the team by email and/or scrum call (we have scrum twice a week, on Monday and Wednesday), and is often set to a higher priority so it floats to the top of our ticket lists.
40+
41+
The main PM responsibility on this side is making sure new tickets are reviewed, put in the right bucket, and assigned a priority. Instead of PM, we call this person the gatekeeper. As the product owner I am the gatekeeper, though I'll ask someone else to step in when I'm out of the office. When someone creates a new ticket, they don't put it in a bucket or assign priority, but they do state in the ticket if they feel that the ticket should be a high priority or a hot fix and if so, why. I review all new tickets daily (which is often only a max of two or three, if any) and decide the final priority. It's a very lightweight process and normally only takes me a few minutes a day.
42+
43+
This new process has made our site-building efforts much more flexible, which is really important for us. We all have multiple areas of responsibility, and being able to balance your available time for the site with other tasks is huge. If you end up not actually having time for tickets due to other responsibilities (remember, creating content and taking care of our members are our main responsibilities—not site development), you just don't assign any to yourself for that week, instead of feeling bad because you couldn't complete the ones assigned to you by someone else. On the other hand if you are blowing through tickets, then you can simply grab something from the pile and keep going without waiting on someone to give you work.
44+
45+
We work with a peer review system. Please note that if you do not have everything in place for a review, your ticket is likely going to be kicked back to you to resolve the issues first, especially if it isn't clear how to test/review the ticket. More about the peer review process can be found at [Peer Review]().
46+
47+
### Working on Tickets
48+
49+
1. Ensure a ticket is open in the ticket tracker, that it's for the current sprint, and is assigned to you.
50+
2. Work in a new branch that contains the ticket number that you're working on. (Please do not work directly in dev, or merge your code to the dev branch without review.) Note, that if you have multiple tickets that are very intertwined, you can create a feature branch to cover that group of tickets. You still need to use ticket ids in your commit messages. (@see step #3)
51+
3. On all commits for your ticket before pushing your branch, ensure that you have the ticket number in your commit message. This will automatically tie your branch to the ticket and make reviewing easier and faster. If you need to, use commit --amend to include the ticket #.
52+
Add ticket numbers with a "#" before them so the ticket tracker will associate the commit with the ticket; however, do not start your commit message with a # sign. The following are acceptable formats for commit messages:
53+
- "[#66]
54+
- "References #666"
55+
- "Resolves #666" - will also mark the ticket as resolved. (@see step #4)
56+
4. In the ticket tracker, mark your ticket as "Resolved".
57+
When marking a ticket as resolved include any manual steps necessary in a comment.
58+
5. Unassign the ticket from yourself. A ticket that is "unclaimed" is ready for anyone to review.

‎resources/workflow-sample-sprint-1.md

Lines changed: 103 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,103 @@
1+
Drupal 7: Sprint Workflow
2+
-------------------------
3+
4+
{NAME} is the product manager.
5+
6+
Dev site (http://d7.example.com) updates on **dev** branch automatically when commits are added to the **dev** branch.
7+
8+
For the Drupalize.Me upgrade we're working with a peer review system. Please note that if you do not have everything in place for a review, your ticket is likely going to be kicked back to you to resolve the issues first, especially if it isn't clear how to test/review the ticket.
9+
10+
**Working on Tickets**
11+
12+
1. Ensure a ticket is open in the ticket tracker, that it's for the current sprint, and is assigned to you.
13+
2. Work in a new branch that contains the ticket number that you're working on. (Please do not work directly in dev, or merge your code to the dev branch without review.) Note, that if you have multiple tickets that are very intertwined, you can create a feature branch to cover that group of tickets. You still need to use ticket ids in your commit messages. (@see step #3)
14+
3. On all commits for your ticket before pushing your branch, ensure that you have the ticket number in your commit message. This will automatically tie your branch to the ticket and make reviewing easier and faster. If you need to, use commit --amend to include the ticket #.
15+
Add ticket numbers with a "#" before them so the ticket tracker will associate the commit with the ticket; however, do not start your commit message with a # sign. The following are acceptable formats for commit messages:
16+
- "[#66]
17+
- "References #666"
18+
- "Resolves #666" - will also mark the ticket as resolved. (@see step #4)
19+
4. In the ticket tracker, mark your ticket as "Resolved".
20+
When marking a ticket as resolved include any manual steps necessary in a comment.
21+
5. Find a buddy to review and merge your code into the dev branch. See notes below on the review process we use.
22+
23+
Branch Types and Names
24+
----------------------
25+
These are the conventions for the kinds of branches we use and naming them. NOTE: you should never use the master branch.
26+
27+
- **Ticket branches** (e.g. 1545-add-queue-button). Each ticket should have its own branch normally and these should be named as _ticket#-some-descriptive-name_.
28+
- **Feature branches** (e.g. add-guides) If you have substantial work on a set of tickets that go together feel free to make a new feature branch for it. You can name that branch with some sort of descriptive title, without a ticket number.
29+
- **Hot fix branches** (e.g. hotfix-614-quickfind). These should be used for all hot fix tickets, one branch per ticket. They should be named as hotfix-_ticket#-description_.
30+
31+
Creating and maintaining branches
32+
-----------------
33+
NOTE: you must keep your branch up with dev. **At least daily you should update and merge the dev branch into your working branch(es).** If you don't, we can end up with PITA conflicts when moving back into master and live. Any tickets that have merge conflicts will be reopened and kicked back to you to fix before review.
34+
35+
**To start:**
36+
37+
D7
38+
git clone git@githost.example.com/d7me.git
39+
40+
**To make a branch:**
41+
42+
git checkout dev
43+
git pull origin dev
44+
git branch <branchname>
45+
git checkout <branchname>
46+
git push origin <branchname>
47+
48+
Do your work and push from here.
49+
50+
**To keep your branch current with dev:**
51+
52+
git checkout dev
53+
git pull origin dev
54+
git checkout <branchname>
55+
git rebase dev
56+
57+
If you have conflicts you need to resolve them in your branch prior to doing more work.
58+
59+
Ready For Review Checklist
60+
----------------------
61+
- Did I include the ticket # in my final commit message? (if not, use commit --amend to include it to re-write your final commit message and include the ticket #).
62+
- Have I documented any additional steps needed to start the review process? e.g. db schema update, or manual configuration
63+
- Have I included a screen shot of what the finished output looks like? (if relevant)
64+
- Have I merged in the dev branch so that my branch is up-to-date with the work other developers have completed?
65+
66+
Conducting a Peer Review
67+
-----------------
68+
We are currently using a peer-review process. Code reviews help both the reviewer and the reviewee improve their Drupal skills. If you are asked to conduct a review, please use the following steps.
69+
70+
1. Review the ticket that has been assigned to you. It should include all of the items from the "Review for Review Checklist" (above). If it does not, ask the developer/designer to update the ticket using the checklist.
71+
72+
2. Checkout a local copy of the branch relating to the ticket. From the command line this is done with:
73+
74+
3.
75+
76+
git branch -a # show a list of all available branches
77+
git fetch # downloads the branches
78+
git checkout --track -b NNNN-branch-name origin/NNNN-branch-name # NNNN should be the ticket number
79+
(short version of above = git checkout --track origin NNNN-branch-name)
80+
81+
3. Complete any steps outlined in the ticket to confirm the branch works "as advertised" in the ticket. If there are any errors, or things are missing, attempt to verify if the problem is on your end (e.g. did you clear cache?). If you cannot replicate what you should be seeing, contact the developer/designer and ask them for help to get your local environment looking like what it should in the ticket.
82+
83+
4. Once you've confirmed the branch is correct and complete it can be merged into the dev branch. Ensure your branch is up-to-date:
84+
85+
git checkout dev
86+
git pull
87+
git checkout NNNN-branch-name
88+
git rebase dev
89+
90+
5. Confirm the branch is still working "as advertised" (see step 3).
91+
92+
6. Merge the branch you've reviewed into dev and push it back up.
93+
94+
git checkout dev
95+
git merge --no-ff NNNN-branch-name
96+
git push
97+
98+
7. Confirm your new branch has been successfully integrated into the development site. It will take about five minutes for d7.example.com to be updated with the revised branch. Complete any additional steps required to sync the database with the new code (e.g. enable new modules). Proceed only once the new code is working on d7.example.com
99+
100+
8. Close the ticket in the ticket tracker. At this time there should not be any additional notes required; however, review the ticket carefully before closing it. If there are "part 2" bits (e.g. the site building part is finished, but now the ticket needs theming work), update the ticket as follows:
101+
- unassign the ticket
102+
- move the ticket to the MVP backlog
103+
- update the component, if relevant (e.g. move it from Site Building to Theming)

0 commit comments

Comments
 (0)