<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Hi Gareth,</p>
<p>Thanks - interesting point.</p>
<p>As far as I'm able to detect the code on the staging branch is
the same code that we end up deploying to production, since what
we deploy to production in the master branch, and when we rebase
the code from the staging branch into master, the staging branch
and the master branch end up being identical, assuming there are
no conflicts, and the way we operate that is only once in a blue
moon, and any extra changes there would be pulled back to staging
and develop.</p>
<p>Maybe I am mis-understanding how rebasing works (entirely
possible), but when I rebase staging into master what I am doing
is avoiding creating a merge commit, so that we have a nice smooth
single threaded git history. Again my understanding (possibly
faulty) is that when I rebase staging into master I am making the
code on master be identical to that on staging, assuming that they
have a shared history, but that staging has a few new commits,
e.g. currently our staging branch history looks like this:<br>
<br>
```<br>
* 2dadadbf 2018-12-13 | Fix future events query (#2922) (HEAD
-> staging, origin/staging, origin/master, master) [Nick
Schimek]<br>
* bd86c461 2018-12-13 | Bump newrelic_rpm from 5.5.0.348 to
5.6.0.349 (#2939) [dependabot[bot]]<br>
* 2d65985b 2018-12-13 | Bump grape from 1.2.1 to 1.2.2 (#2940)
[dependabot[bot]]<br>
* d1865dae 2018-12-12 | 2893 add grape api move legacy api (#2919)
[Sam Joseph]<br>
* 7f42d570 2018-12-11 | reduce events caching to one hour (#2936)
[Sam Joseph]<br>
* aa77c6ee 2018-12-11 | Bump letter_opener from 1.6.0 to 1.7.0
(#2934) [dependabot[bot]]<br>
* aa4d6bee 2018-12-11 | Bump stripe from 4.2.0 to 4.3.0 (#2933)
[dependabot[bot]]<br>
* 298a8118 2018-12-11 | 2883 improve 500 error page (#2931)
[ElisaRmz]<br>
```<br>
<br>
and our master history looks like this:</p>
<p>```<br>
* 2dadadbf 2018-12-13 | Fix future events query (#2922) (HEAD
-> master, origin/staging, origin/master, staging) [Nick
Schimek]<br>
* bd86c461 2018-12-13 | Bump newrelic_rpm from 5.5.0.348 to
5.6.0.349 (#2939) [dependabot[bot]]<br>
* 2d65985b 2018-12-13 | Bump grape from 1.2.1 to 1.2.2 (#2940)
[dependabot[bot]]<br>
* d1865dae 2018-12-12 | 2893 add grape api move legacy api (#2919)
[Sam Joseph]<br>
* 7f42d570 2018-12-11 | reduce events caching to one hour (#2936)
[Sam Joseph]<br>
* aa77c6ee 2018-12-11 | Bump letter_opener from 1.6.0 to 1.7.0
(#2934) [dependabot[bot]]<br>
* aa4d6bee 2018-12-11 | Bump stripe from 4.2.0 to 4.3.0 (#2933)
[dependabot[bot]]<br>
* 298a8118 2018-12-11 | 2883 improve 500 error page (#2931)
[ElisaRmz]<br>
```<br>
<br>
and they are identical because when I did our last deploy (kicking
off by manually rebasing staging into master), the few new commits
on staging were added onto master.</p>
<p>The environment specific branches don't have any evironment
specific config, and they don't contain different combinations of
feature branches, except in as much that at any given moment we
may have a few new features/bug-fixes/upgrades in develop that are
not in staging that are not in master, but as they move along
(what I call) the pipeline (perhaps I'm using the term
incorrectly), all of those features/bug-fixes/upgrades will end up
in master/production, and if we have a quiet spell with nothing
new coming in, all three branches will be identical.</p>
<p>Nevertheless, yes, we certainly want to deploy the same code
everywhere, as you suggest, and I think we are doing so - I could
be wrong. Perhaps our three branches, each tied to a different
server, is more complex than we need, or just rather different
from what everyone else is doing ... <br>
</p>
<p>Thanks so much for taking the time to comment.</p>
<p>Best, Sam<br>
</p>
<div class="moz-cite-prefix">On 08/01/2019 10:33, Gareth Adams
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAJ=YDWu5b06g=Z1CiTh3Yuj6jD4jjvbMKL=jhgwiWSJpOx_nuA@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="auto">Sam, I don't have a grand answer to your whole
question, but a phrase leapt out at me and I wanted to flag it:
<div dir="auto"><br>
</div>
<div dir="auto">> rebasing along the pipeline</div>
<div dir="auto"><br>
</div>
<div dir="auto">To me, this suggests the code on your staging
branch is not the same as the code you end up deploying to
production (and it might not be the same as the code in your
master branch)</div>
<div dir="auto"><br>
</div>
<div dir="auto">I guess there are a few reasons that could be:
you're storing some environment-specific configuration on your
environment branches, and can't merge them all together, or
maybe your environment branches contain a different
combination of feature branches that you're trying to keep
control of?</div>
<div dir="auto"><br>
</div>
<div dir="auto">Either way, I'd consider how (or if) you could
change your workflow to make sure you deploy the same code
everywhere (or at least deploy the same code to production
that you deploy to staging). That's the basis behind e.g.
Heroku pipelines' "Promote" button and it's the pattern I
commonly see now</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr">On Tue, 8 Jan 2019, 10:13 Samuel Joseph <<a
href="mailto:tansaku@gmail.com" rel="noreferrer noreferrer"
target="_blank" moz-do-not-send="true">tansaku@gmail.com</a>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<p>Hi Gerhard,<br>
</p>
<div
class="m_3868980048267634368m_-2707529618717350415m_-2020117851195068980moz-cite-prefix">On
07/01/2019 12:00, Gerhard Lazu wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr">Hi Sam,
<div><br>
</div>
<div>What determines that a build can go from your
development environment into staging? </div>
</div>
</div>
</blockquote>
Good question, the answer is:<br>
<br>
1) that all the unit, integration and acceptance tests pass<br>
2) that there are no merge conflicts<br>
3) that the manual sanity checks on develop are coming back
okay<br>
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr">
<div>And from staging into production? If you can
capture this in code, you can put it into a
pipeline.<br>
<br>
</div>
</div>
</div>
</blockquote>
I don't think there's any way we can remove the manual
sanity checks as the acceptance tests are just not that
reliable, and although we've poured 1000's of hours into
them and ultimately I can't see any way of making them
perfect.<br>
<br>
I didn't think the presence of a manual step would prevent
us using a pipeline, in as much as I thought of a pipeline
as just being a series of servers with matching branches and
code is them moved along them whether manually or
automatically. Heroku calls such things pipelines and seems
to have no support for automatically moving code along them,
it's purely manual from what I can see.<br>
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr">
<div><br>
</div>
<div>Why do you have 3 pipelines? </div>
</div>
</div>
</blockquote>
<p>I don't think we do. As I understand it, we have one
pipeline:</p>
<p>develop branch + develop server ---> staging branch +
staging server ---> master branch + production server</p>
<p>That's three paired branches/servers in one pipeline.
Here's a screenshot of how Heroku presents our pipeline in
their pipeline interface. Note the button "Promote to
staging" which allows you to manually move the code on the
develop server to the staging server, but doesn't actually
do a rebase of the code from develop branch to staging:<br>
</p>
<p><img alt="" moz-do-not-send="true" width="790"
height="157"></p>
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr">
<div>Based on the questions that you're asking, I
believe that it would help if you had a single
pipeline. </div>
</div>
</div>
</blockquote>
I agree - I think we do, but perhaps I'm wrong ...<br>
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr">
<div>The question that I would focus on is <i>What
would it take to have a single pipeline that has
an end-goal of creating production builds</i>?
Here is a pipeline example which stops after it
publishes a Docker image: <a
href="https://circleci.com/workflow-run/065467ef-87c0-4f5e-a2ab-5e11be12403f"
rel="noreferrer noreferrer noreferrer"
target="_blank" moz-do-not-send="true">changelog.com,
CircleCI</a>.</div>
</div>
</div>
</blockquote>
Ooh, thanks for sharing! I had to log in to CircleCI to see
that:<br>
<br>
<p><img alt="" moz-do-not-send="true" width="470"
height="208"></p>
but that looks really interesting.<br>
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr">
<div> If you are using something like Docker Swarm or
Kubernetes, the platform/ecosystem has all the
necessary tools to keep deployment concerns
self-contained. In the <a
href="http://changelog.com" rel="noreferrer
noreferrer noreferrer" target="_blank"
moz-do-not-send="true">changelog.com</a> case, the
Docker stack that captures the entire deployment has
<a
href="https://github.com/thechangelog/changelog.com/blob/cf2ebe0de0f35c96bf664b8bc9183bd1f3468565/docker/changelog.stack.yml#L15-L31"
rel="noreferrer noreferrer noreferrer"
target="_blank" moz-do-not-send="true">an update
component that is responsible for app updates</a>.
In this specific case, if the new app version starts
and is healthy for 30 seconds, it gets automatically
promoted to live. <a
href="http://changelog.com/podcast/254"
rel="noreferrer noreferrer noreferrer"
target="_blank" moz-do-not-send="true">We have
been using a similar approach since October 2016</a>,
a Docker stack just makes it easier.</div>
<div><br>
</div>
<div>I want to spur your imagination by sharing <a
href="https://ci.rabbitmq.com/teams/main/pipelines/server-release:v3.7.x"
rel="noreferrer noreferrer noreferrer"
target="_blank" moz-do-not-send="true">the
pipeline that is responsible for RabbitMQ v3.7.x</a>.
This pipeline captures what is possible if
imagination is set free:</div>
</div>
</div>
</blockquote>
Wow, that RabbitMQ pipeline looks amazing - and I've only
captured part of it in the screenshot:<br>
<br>
<img alt="" moz-do-not-send="true" width="593" height="375">
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr">
<div><br>
</div>
<div>* tests & builds 30+ apps...</div>
<div>* on all supported major runtime version...</div>
<div>* and all supported OSes</div>
<div>* tests upgrades</div>
<div>* tests client support</div>
<div>* releases alphas, betas, RCs & GAs</div>
<div>* and publishes to all supported distribution
channels</div>
<div><br>
</div>
<div>I hope this helps, Gerhard.</div>
</div>
</div>
</blockquote>
<p>That's extremely helpful - thankyou!</p>
<p>But so just to be clear, there is something in these
pipelines that you're sharing that regularly moves code
from one branch to another? And that's something that
CircleCI and RabbitMQ provide? Or these are pipelines
where the same code in the same branch is being moved
through a series of servers, based on tests and checks
passing at each server?</p>
<p>Many thanks in advance<br>
Best, Sam<br>
</p>
</div>
_______________________________________________<br>
Chat mailing list<br>
<a href="mailto:Chat@lists.lrug.org" rel="noreferrer
noreferrer noreferrer" target="_blank"
moz-do-not-send="true">Chat@lists.lrug.org</a><br>
Archives: <a
href="http://lists.lrug.org/pipermail/chat-lrug.org"
rel="noreferrer noreferrer noreferrer noreferrer"
target="_blank" moz-do-not-send="true">http://lists.lrug.org/pipermail/chat-lrug.org</a><br>
Manage your subscription: <a
href="http://lists.lrug.org/options.cgi/chat-lrug.org"
rel="noreferrer noreferrer noreferrer noreferrer"
target="_blank" moz-do-not-send="true">http://lists.lrug.org/options.cgi/chat-lrug.org</a><br>
List info: <a
href="http://lists.lrug.org/listinfo.cgi/chat-lrug.org"
rel="noreferrer noreferrer noreferrer noreferrer"
target="_blank" moz-do-not-send="true">http://lists.lrug.org/listinfo.cgi/chat-lrug.org</a><br>
</blockquote>
</div>
</blockquote>
</body>
</html>