[LRUG] [Workflow] Getting a Pull Request from creation to merge

[Alex Reis]

The team I've been working with for a year now functions on a slightly
different, organic workflow. It's not unlike the one used in open source
projects, which I find to be quite effective:

Everyday stuff:
- All commits go into master and are posted to campfire from github
- Anyone interested clicks the link, has a go through the code and either
comments on github or brings issues up in campfire/IM
- If no one said anything, it probably didn't touch an important part of
the code and was ignored, or everyone agrees with your changes
- Feedback is usually instant since a review is done on a per push basis.

Big, breaking changes:
- Commits are done to a branch
- Code until done, then:
- CI is run against the branch
- Pull request is created
- Another team member reviews the pull request and merges it
- We usually spend the next day fixing unforeseen issues anyway

Requirements for this to be successful and viable:

- No n00bz allowed on their own: The team is comprised only of experienced
programmers who love what we do, know what we are doing, and care about the
others enough not to allow crap into the code. Inexperienced programmers
are welcome, but are under constant mentoring and have their code in a
branch that is reviewed before merging.

- Staging environment: Although everything goes into master, it's not
deployed to production. Production code is a separate branch that we bug
fix on. Hopefully one day we will get our cucumbers to cover the whole of
the app and trust them enough to promote anything that passes CI to
production, working with feature toggles to shield users from unfinished
functionality.

- Collective code ownership, individual accountability: We're free to
change and poke around the whole of the codebase, but the person who wrote
a piece originally has a certain attachment to it and a sense of
responsibility for keeping it working and clean. If something bad happens,
they're usually the ones fixing it.

- Awesome Product Owner: Your PO needs to understand that keeping a
codebase healthy is as good to his pockets as is new functionality. Having
them available at all times for answering questions and overhearing
conversations on campfire is definitely a must have. Keeping the team
accountable for bugs or big disruptions to other people's working
environments should also be their job.

- Non-blaming culture: When something bad happens, no one asks "who screwed
up?". We try and figure out who can fix the issue faster and give them
every support they need.

- Small team: We're 5 people. Perhaps this could get a little chaotic if
you're on a bigger team, but at that point, in my experience you should
really give some thought at splitting teams up around functional areas (not
technology!).

- Horizontal hierarchy - Not having anyone be "team lead/architect/tech
lead/CTO/<insert fancy bossy title here>" is the best way to keep
responsibility shared and everyone accountable. Again, in my experience,
YMMV

Advantages (for me, YMMV):

- Fosters collaboration - everyone looks at all code being modified at all
times; the team works as a unit to come up with solutions and keeping the
codebase clean
- Enables remote work - since it revolves around Campfire, it's as easy to
get your code constantly reviewed, same as if you were on site.
- Fluidness - No one sits around waiting for code to be reviewed. Sure, we
need to wait for the PO to approve a piece of code, but since communication
is very much open, the PO gets to see progress and give feedback even
before code is integrated to master and pushed to staging.
- Team bonding - We're all in it together, responsibility is shared and
we're all equally accountable for code quality and working software.
Instead of thinking "oh damn, I have to go back and fix because person X
dislikes this bit" a couple days after you've pushed, you get instant
feedback and avoid the context switch

Hope you find it at least interesting, it's definitely diverging from most
of what's been posted to this thread already. If you think we're insane for
not doing feature branches, I suggest reading
http://martinfowler.com/bliki/FeatureBranch.html or watching
http://www.youtube.com/watch?v=xzstASOvqNc

Best,

Alex



On Tue, Aug 20, 2013 at 8:21 PM, David Waller <david.a.waller at btinternet.com
> wrote:

> A bit late to add my 2p, but anyway...
>
> Context switching cost is almost impossible to avoid, but I've found that
> you can mitigate it in small ways
> - keep changes small so that they're fast to review
> - the team needs a shared commitment to not blocking each other
> - a reviewer shouldn't be pulling themselves out of a deep state of
> 'flow', but there are plenty of times when you're taking a lunch break,
> catching up on email, etc. when you can tack a code review onto the end.
>
> If you're doing continuous deployment or something along those lines, one
> of the key benefits is being able to turn round a fix in next to no time.
>  If maintaining that sort of feature/bugfix velocity is a priority for your
> team then much of what I've suggested comes simply as a beneficial side
> effect of that.
>
> David
> _______________________________________________
> Chat mailing list
> Chat at lists.lrug.org
> http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lrug.org/pipermail/chat-lrug.org/attachments/20130821/1a2eaa55/attachment.html>