Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Maturing Locately Dev Processes
Branching, merging, reviewing,
releasing
Motivations/Drivers
• A dev team that is
– Growing (7 committers)
– More distributed (Boston/KC)
• A codebase that is
– Gr...
Emerging Necessities 1
• More controlled trunk
– A broken trunk affects more devs
– Higher velocity of development means w...
Emerging Necessities 2
• Improved Code Reviews
– Asynchronous code reviews
• Less disruptive to the reviewer
• Non-blockin...
Suggested Processes
• Based on best practices, judgment, personal
preferences, guessing
• Open for debate and evolution
• ...
Branching into Feature Branch
• Create a branch
svn copy -rHEAD svn+ssh://matt@dev.locately.com/ebs/repo/siphon/trunk
svn+...
Working in Feature Branch
• Perform check-ins as desired (w/o code review)
• Collaborate with co-workers via this branch i...
Installing ReviewBoard
• With your virtualenv activated:
easy_install RBTools
• Create ~/.reviewboardrc:
REVIEWBOARD_URL="...
Creating Review Request
• Create a RB review request for the changeset that
took rev. 8178 to rev. 8186:
rbt post -d --rev...
Code Reviews via ReviewBoard
• Reviewer:
– Check out the code from the branch if desired
– Within ReviewBoard: make commen...
Merging Feature Branch into Trunk
• Once a changeset is reviewed and approved
• Perform a final merge of trunk into the br...
Other Thoughts
• Use ReviewBoard to capture design artifacts:
e.g., specs, plan of attack
• And iterate/comment on them, b...
Upcoming SlideShare
Loading in …5
×

Maturing Locately Dev Processes

193 views

Published on

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Maturing Locately Dev Processes

  1. 1. Maturing Locately Dev Processes Branching, merging, reviewing, releasing
  2. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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

×