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

[Zetter]

Your process is similar to what used in the past. My prefered workflow
different from when the pull request is given the 'OK':

7. The person who worked on the card merges changes
8. They deploy to production

This has the benefit that the person doing the merge and deploy is the one
that knows the card the best so it will be easier for them to deal with
unforeseen problems (merge conflicts or failed deploys) they will also be
able to update the product owner who they already have a dialogue about the
card with. Making changes, merging and deploying can be done as a single
process without context switches.

I've missed out any QA or sign off- this can done by the product owner on
the developers machine before the pull request. To save time I tend to only
do a separate QA/Staging deploy when I know the card has environment
specific changes- such as installing a new package or new chef recipe.

With these modifications there's still going to be a cost to context
switching around the back-and-forth of updating the pull request. One thing
that helps is making sure iterations are full of cards that only take less
than a few hours- if someone is always working on a small card, it will at
most be a few hours until someone is able to view a pull request.

Chris


On Mon, Aug 19, 2013 at 1:38 PM, Matthew Rudy Jacobs <
matthewrudyjacobs at gmail.com> wrote:

> (This is a process question, rather than a Ruby question)
>
> How do you folks manage getting code from pull request to production?
>
> At Enthuse.me we work in the following way;
>
>    1. we take a card
>    2. we work on the code until we believe it is done
>    3. we issue a pull request
>    4. another member of the team takes a look at the pull request
>    5. we converse about any issues
>    6. we make any changes
>    7. another member of the team merges the pull request
>    8. the code is deployed to the QA server
>    9. the product owner checks the function on QA
>    10. the code is deployed to Production
>
> This all seems to be fine,
> but the problem is context switching.
>
> Steps 4 to 8 can take a couple of days to run through.
>
> Maybe I finish the code on Friday, but no one is free to review it until
> Monday.
> I start working on something else, then someone raises an issue with my PR.
> When I'm next free I take a look, deal with their questions, make some
> changes, and ask them to take a look again.
>
> That process takes a lot of time, and requires both the reviewer and
> myself, to switch back and forth.
>
> How do you deal with this?
>
>
> _______________________________________________
> 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/20130819/f43949dc/attachment-0003.html>