<div dir="ltr"><span style="font-family:arial,sans-serif;font-size:13px">Your process is similar to what used in the past. My prefered workflow different from when the pull request is given the 'OK':</span><div style="font-family:arial,sans-serif;font-size:13px">
<br></div><div style="font-family:arial,sans-serif;font-size:13px">7. The person who worked on the card merges changes</div><div style="font-family:arial,sans-serif;font-size:13px">8. They deploy to production</div><div style="font-family:arial,sans-serif;font-size:13px">
<br></div><div style="font-family:arial,sans-serif;font-size:13px">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.</div>
<div style="font-family:arial,sans-serif;font-size:13px"><br></div><div style="font-family:arial,sans-serif;font-size:13px">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.</div>
<div style="font-family:arial,sans-serif;font-size:13px"><br></div><div style="font-family:arial,sans-serif;font-size:13px">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.</div>
<div style="font-family:arial,sans-serif;font-size:13px"><br></div><div style="font-family:arial,sans-serif;font-size:13px">Chris</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Aug 19, 2013 at 1:38 PM, Matthew Rudy Jacobs <span dir="ltr"><<a href="mailto:matthewrudyjacobs@gmail.com" target="_blank">matthewrudyjacobs@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">(This is a process question, rather than a Ruby question)<div><br></div><div>How do you folks manage getting code from pull request to production?</div>
<div><br></div><div>At Enthuse.me we work in the following way;</div>
<div><div><ol><li>we take a card<br></li><li>we work on the code until we believe it is done</li><li>we issue a pull request</li><li>another member of the team takes a look at the pull request</li><li>we converse about any issues</li>
<li>we make any changes</li><li>another member of the team merges the pull request</li><li>the code is deployed to the QA server</li><li>the product owner checks the function on QA</li><li>the code is deployed to Production</li>
</ol><div>This all seems to be fine,</div></div><div>but the problem is context switching.</div><div><br></div><div>Steps 4 to 8 can take a couple of days to run through.</div><div><br></div><div>Maybe I finish the code on Friday, but no one is free to review it until Monday.</div>
<div>I start working on something else, then someone raises an issue with my PR.</div><div>When I'm next free I take a look, deal with their questions, make some changes, and ask them to take a look again.</div><div>
<br>
</div><div>That process takes a lot of time, and requires both the reviewer and myself, to switch back and forth.</div><div><br></div><div>How do you deal with this?</div></div><div><br></div></div>
<br>_______________________________________________<br>
Chat mailing list<br>
<a href="mailto:Chat@lists.lrug.org">Chat@lists.lrug.org</a><br>
<a href="http://lists.lrug.org/listinfo.cgi/chat-lrug.org" target="_blank">http://lists.lrug.org/listinfo.cgi/chat-lrug.org</a><br>
<br></blockquote></div><br></div>