<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Hi Murray, <br>
</p>
<div class="moz-cite-prefix">On 08/01/2019 14:56, Murray Steele
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CABUDGcq26SL0ak=5JPwt-BKYkUjwkhG=C_W=5azvQ=jdSR__Tg@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">Someone already asked this, but what does “rebasing
along the pipeline” mean? I’d expect to do some rebasing on my
feature branch to pick up changes to the main branch, but that
deploys would be that I merge my branch into
master/develop/whatever and that goes automatically to a
develop/uat/preview environment. Then <something happens>
and I do a merge-commit of that branch onto staging and it goes
automatically to the staging environment. The <something
happens> happens again and I do a merge-commit of the staging
branch onto production and that goes automatically to the
production environment. If you’re doing rebasing instead of
merge-commits here (or even ff merge’s) something seems complex
as rebases aren’t guaranteed to not need human intervention.
Right?</div>
</blockquote>
<p>I'm not sure about that. I guess it depends what we're assuming
about the branch we're merging or rebasing into. I have often
found that rebasing can be trickier than merging, but also that
both both merging and rebasing can lead to conflicts that need
manual intervention. I've almost never had a problem rebasing
along the pipeline, and I think it creates a smoother git history
that is then really easy to interpret in terms of what needs to be
tested manually, i.e. what are the latest items going out.</p>
<p>But merge along the pipeline, rebase along the pipeline,
whichever is fine; either way that's the manual step that I'm
trying to avoid. From your description above you've got manual
merge steps (maybe you're just elaborating on my example?) but
what I'm hearing in other threads is that folks have pipelines
from staging to production all from a single branch with no git
action involved in code being deployed first to staging and then
production - that's a new model to me, and what I'm really keen to
understand is in that case, what is the trigger for deployment to
production? Simply a successful deploy to staging?<br>
</p>
<blockquote type="cite"
cite="mid:CABUDGcq26SL0ak=5JPwt-BKYkUjwkhG=C_W=5azvQ=jdSR__Tg@mail.gmail.com">
<div dir="ltr">
<div>
<div class="gmail_quote">
<div><br>
</div>
<div>The other thing that confuses me is that it sounds to
me that the manual checks are the blockers, not the
“rebasing along the pipeline”. As others have said, I’d
be looking into automating those steps as much as possible
if I wanted to improve the process. If they can’t be then
I’d look into automating a “hey the rebase onto
<environment> has happened, and you started it, so
you should now do those manual checks” notification to
keep everyone on their toes. Maybe also some “Hey, X
commits are on "master" but not on “production”, sort it
out!” notifiers too.</div>
</div>
</div>
</div>
</blockquote>
<p>That's a good suggestion, although that might work best if we had
all paid developers to impose that on. We do have some paid
developers but many many open source volunteer contributors. We
would love to get them all involved in taking responsibility for
taking their contributions all the way to production, but that's a
bit of an uphill struggle :-/ Good suggestion though - my thought
about automating the git moves along the pipeline is like, hey
everyone, tuesday morning is the day we check staging, and
thursday morning is the day we check production kind of thing ...
it's out there on staging on Tuesday and if we don't check it will
be on production on Thursday so better fix any issues or stop the
deploy - but either way gotta be done ...<br>
</p>
<p>Anyhow as I was saying, we do have automated tests for all the
things that we might check on staging as "sanity" checks, but this
is what I've always found strange about the heroku model is that
you can't run automated tests on the actual servers - or are you
saying have some manual tests that poke production over http?
Back in the day (2006) when we had our own servers we'd be running
our tests on our servers in test mode (using the rails test db
etc.) and I felt more confident that passing tests meant working
server, but even then there was still room for slight changes in
configuration to cause problems.</p>
<p>So maybe the solution is a better devops set up that allows us to
match the prod configuration more precisely in CI or on the
staging server - at the moment we've got staging rigged to be as
close as production as possible, but then there are always some
differences like intercepting emails and notifications etc.</p>
<p>Anyway, what I'm really interested to hear is about anyone's
pipeline from dev to production that doesn't involve any manual
steps at all, i.e. no git operations, no checking any servers, no
testing any UIs; where code that gets merged will automatically
end up on production with no eyeballs and no typing - or maybe no
one has that ...?</p>
<p>Apologies if I'm being thick and/or dragging this out etc. Feel
like there's still a lot for me to learn/understand, get clear
here ...</p>
<p>Thanks so much for everyone's input.<br>
</p>
<p>Best, Sam<br>
</p>
</body>
</html>