<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">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" target="_blank">https://en.wikipedia.org/wiki/Continuous_integration</a><br>
<a href="https://en.wikipedia.org/wiki/Continuous_deployment" rel="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" 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" target="_blank" rel="noreferrer">Chat@lists.lrug.org</a><br>
Archives: <a href="http://lists.lrug.org/pipermail/chat-lrug.org" rel="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" 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" target="_blank">http://lists.lrug.org/listinfo.cgi/chat-lrug.org</a><br>
</blockquote></div></div></div>