<div dir="auto"><div>If you'll pardon the metaphor, I think you're focusing on the trees at the expense of the wood. Your software can still be deployed automatically to certain environments by services like Heroku Pipelines (e.g. feature branches deployed as "review apps", master branch deployed after code merge).</div><div dir="auto"><br></div><div dir="auto">The semantics of what you're focusing on, i.e. promoting code through environments, is just part of the deployment process itself. This is generally the part in my experience which differs most per organisation (beyond a certain size) and generic solutions may not fit bespoke requirements.<br></div><div dir="auto"><br><div class="gmail_quote" dir="auto"><div dir="ltr">On Mon., 7 Jan. 2019, 22:20 Samuel Joseph <<a href="mailto:tansaku@gmail.com">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 Sasha,</p>
<p>Thanks for coming back to me on this. You say it's called
"Continous Deployment", but I'm pretty sure that is not what I
want, i.e. that we have Continuous Deployment already, and what I
want is more than the CD that most providers offer.</p>
<p>I've used Heroku Pipelines extensively and they are pretty cool,
but what they don't do (I think) is offer the ability to automate
the movement along the pipeline - that is still a manual step.
I've been in contact with Heroku support (as I have with Travis
and Semaphore) and automated movement along pipelines does not
seem to be supported.</p>
<p>But of course maybe I'm completely confused or mistaken, however
the fact that so many people come back to me and say, "oh yeah,
you want continuous deployment" makes me think that there is some
more fundamental misunderstanding here. It might well be me doing
the misunderstanding, or me just not finding the right swtich in
Heroku/Travis/Semaphore, but I remain confused ...</p>
<p>All the same, really appreciate you taking the time to reply.</p>
<p>Best, Sam<br>
</p>
<div class="m_8911671569690105972moz-cite-prefix">On 07/01/2019 11:14, Sasha Gerrand
wrote:<br>
</div>
<blockquote type="cite">
<div dir="auto">
<div>You're referring to "continuous deployment", which many
service providers like Heroku offer (Heroku call it
"pipelines").</div>
<div dir="auto"><br>
</div>
<div dir="auto">Note that an automatic deployment of code to a
staging environment needs additional steps to validate that
the chances are behaving as expected. Ditto for the production
deployment (s).<br>
<br>
<div class="gmail_quote" dir="auto">
<div dir="ltr">On Mon., 7 Jan. 2019, 20:52 Samuel Joseph
<<a href="mailto:tansaku@gmail.com" target="_blank" rel="noreferrer">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">Hi LRUG,<br>
<br>
Happy New Year! Hope you all had a good one.<br>
<br>
Apologies in advance for what has become a bit of a long
post, but I <br>
have a question about "Continuous *", i.e.<br>
<br>
* Continous Integration (C.I.)<br>
* Continous Deployment<br>
* Continous Delivery<br>
<br>
I think I understand Continuous Integration quite well. I
take it to <br>
mean that all tests are run whenever you commit code to
version <br>
repositories in the cloud, and thus we talk about C.I.
providers such as <br>
Travis, Semaphore, CircleCI, CodeShip etc. I interact
with Travis and <br>
Semaphore on a daily basis and see the results of
automated tests run on <br>
all our pull requests and again when we merge them in. I
think <br>
technically the concept of C.I. originally means just
having all <br>
developers getting their work merged in to the same place
with high <br>
frequency, but anyway, I feel relatively comfortable with
this term.<br>
<br>
The way I hear Continuous Deployment being used seems to
be when the <br>
C.I. tests are set such that on a passing build, the code
gets <br>
automatically deployed to a server. We have a few
pipelines where we <br>
have develop, staging and production servers, which are
automatically <br>
deployed to as a result of passing builds on the develop,
staging and <br>
master branches respectively. These deployments are
supported by hooks <br>
on Travis, Semaphore etc. and are very handy. Continous
Delivery I'm <br>
not so sure - I just found the term of google<br>
<br>
Of course I have read the wikipedia pages on all these
terms:<br>
<br>
<a href="https://en.wikipedia.org/wiki/Continuous_integration" rel="noreferrer noreferrer noreferrer" target="_blank">https://en.wikipedia.org/wiki/Continuous_integration</a><br>
<a href="https://en.wikipedia.org/wiki/Continuous_deployment" rel="noreferrer noreferrer noreferrer" target="_blank">https://en.wikipedia.org/wiki/Continuous_deployment</a><br>
<a href="https://en.wikipedia.org/wiki/Continuous_delivery" rel="noreferrer noreferrer noreferrer" target="_blank">https://en.wikipedia.org/wiki/Continuous_delivery</a><br>
<br>
and while I'd love to tune up my mental pictures of each,
what I'm <br>
really looking for the right term for the practise of
automatically <br>
moving code along a pipeline like the one I mentioned
above: develop --> <br>
staging --> production.<br>
<br>
At the moment the process of running tests and deploying
to each server <br>
for each branch is completely automatic. However, the
process of moving <br>
code from develop to staging, or staging to production is
manual. We've <br>
previously reached out to Travis, Semaphore and Heroku to
ask about some <br>
process that would automate moves along the pipeline, but
the <br>
conversation seems confused by the ambiguity in the
technology and I'm <br>
left thinking they don't - but could be wrong.<br>
<br>
We've recenly moved one pipeline completely from heroku to
azure/dokku <br>
and it seems like we can now create our own automatic
pipeline <br>
progression with cron jobs so that, say, on Monday at
noon, the develop <br>
code is rebased into staging, and at noon on wednesday the
staging code <br>
is rebased into production, and in each cases tests and
deploys would be <br>
kicked off. My main motivation to automate this is to
remove the <br>
manual step which is a chore and can get put off. It's
particularly <br>
highlighted by our use of dependabot, which is
automatically putting in <br>
PRs based on library upgrades, so every week there is a
several upgrades <br>
to go out along with the usual features and bug-fixes.<br>
<br>
I speculate that if we had such a setup, we'd get into the
habit of <br>
being more careful with merging PRs (knowing they'd be
automatically <br>
deployed to production) and regularly doing the few
additional front end <br>
manual sanity checks when we're notified of staging and
production <br>
deploys ... Anyway, I'd love to know if there's a correct
term to be <br>
using to describe the pipeline automation we want to set
up, and whether <br>
there are any providers that make it easy to do.<br>
<br>
We hear all the time about facebook, netflix etc.
deploying to <br>
production multiple times a day, but I'm very interested
to hear about <br>
practices at all scales. Sorry for the long post - here's
wishing <br>
everyone a very prosperous 2019!<br>
<br>
Best, Sam<br>
<br>
_______________________________________________<br>
Chat mailing list<br>
<a href="mailto:Chat@lists.lrug.org" rel="noreferrer noreferrer" target="_blank">Chat@lists.lrug.org</a><br>
Archives: <a href="http://lists.lrug.org/pipermail/chat-lrug.org" rel="noreferrer noreferrer noreferrer" target="_blank">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" target="_blank">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" target="_blank">http://lists.lrug.org/listinfo.cgi/chat-lrug.org</a><br>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
</blockquote></div></div></div>