The document discusses emerging necessities for improving Locately's development processes as the team and codebase grow. It suggests adopting branching and merging workflows using Subversion for feature development and code reviews. Review requests would be created in ReviewBoard and include release notes. The workflow involves branching from trunk into a feature branch, merging trunk changes periodically, submitting code reviews, and then merging the branch back into trunk after approval.

1. Maturing Locately Dev Processes
Branching, merging, reviewing,
releasing

2. Motivations/Drivers
• A dev team that is
– Growing (7 committers)
– More distributed (Boston/KC)
• A codebase that is
– Growing (not in “maintenance mode”)
– More mission-critical to our business, customers,
users, analysts
– Less familiar overall to the team
• These are good things!
2

3. Emerging Necessities 1
• More controlled trunk
– A broken trunk affects more devs
– Higher velocity of development means we’re more likely to release
something problematic
• Better revision control in non-trunk
– Enable collaboration with co-workers on features
– Safely tuck away local check-ins without affecting trunk
• Need to capture, discuss, iterate on early dev artifacts
– E.g., specs, plan of attack
• More controlled release/push process
– Better planned and timed
– More deliberate schema migrations, minimizing impacts of downtime
– More robust staging/testing/go-or-no-go checkpoints
3

4. Emerging Necessities 2
• Improved Code Reviews
– Asynchronous code reviews
• Less disruptive to the reviewer
• Non-blocking for the developer
• But in-person discussion is still best
– Multiple reviewers, optional reviewers
– Desire for “sit-ins”
4

5. Suggested Processes
• Based on best practices, judgment, personal
preferences, guessing
• Open for debate and evolution
• Basic suggested workflow (for a “sizeable” mod):
– Branching into feature branch
– Merging (refreshing) from trunk into branch
– Creating review request
– Including “release notes”
– Code review
– Merging (re-integrating) from branch into trunk
5

6. Branching into Feature Branch
• Create a branch
svn copy -rHEAD svn+ssh://matt@dev.locately.com/ebs/repo/siphon/trunk
svn+ssh://matt@dev.locately.com/ebs/repo/siphon/branches/matt_20130730
• Option 1: New working copy for that branch (more
appealing IMO)
svn checkout svn+ssh://matt@dev.locately.com/ebs/repo/siphon/branches/matt_20130730
siphon_mybranch
• Option 2: Switch working copy to that branch
svn switch svn+ssh://matt@dev.locately.com/ebs/repo/siphon/branches/matt_20130730
/Users/mattklein/EclipseWorkspaces/locately/siphon
– Note that “svn switch” is just like “svn update” – it actually
performs the updates into your working copy (doesn’t allow you
to review them)
• For Eclipse: Import > Existing Projects Into Workspace
6

7. Working in Feature Branch
• Perform check-ins as desired (w/o code review)
• Collaborate with co-workers via this branch if necessary
• Regularly merge changes that have happened in trunk into this
branch:
svn merge svn+ssh://matt@dev.locately.com/ebs/repo/siphon/trunk
– This affects your working copy (not the repo)
– Sanest to do this with a clean working copy
– This copies changes that have happened in trunk since your last merge
(or since branch creation) into your working copy
– Review and commit those changes into your branch in the repo
• Use commit comment something like “merging changes from trunk into
branch”
• Repeat as necessary
• When done with the feature, submit a review request
7

8. Installing ReviewBoard
• With your virtualenv activated:
easy_install RBTools
• Create ~/.reviewboardrc:
REVIEWBOARD_URL="https://reviewboard.locately.com/"
REPOSITORY="svn+ssh://matt@dev.locately.com/ebs/svn/two"
USERNAME="matt"
PASSWORD="matt"
• (Yes, this actually works now)
8

9. Creating Review Request
• Create a RB review request for the changeset that
took rev. 8178 to rev. 8186:
rbt post -d --revision-range=8178:8186 --open
• Add one or more reviewers
– Who? TBD; informal for now
• Include release notes:
– Functional summary
– If schema migrations: expected duration, backwards-
compatible?
– What testing/verification should be done in “staging”
during push; what are the risks at go-live?
9

10. Code Reviews via ReviewBoard
• Reviewer:
– Check out the code from the branch if desired
– Within ReviewBoard: make comments,
suggestions, ask questions
– Always plan for in-person discussion
• De-personalize: keep it about the code, not
the coder
• Other best practices?
10

11. Merging Feature Branch into Trunk
• Once a changeset is reviewed and approved
• Perform a final merge of trunk into the branch
• Now trunk and the branch are identical, with the
exception of the branch’s changes
• Go into a clean working copy of trunk
• Merge into this working copy using --reintegrate
• Whose responsibility should this be? The
developer? A “CM manager”?
• Afterwards, delete (rather than re-use) the
feature branch
11

12. Other Thoughts
• Use ReviewBoard to capture design artifacts:
e.g., specs, plan of attack
• And iterate/comment on them, bring in the
appropriate people
12