<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? And from staging into production? If you can capture this in code, you can put it into a pipeline.</div><div><br></div><div>Why do you have 3 pipelines? Based on the questions that you're asking, I believe that it would help if you had a single pipeline. 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">changelog.com, CircleCI</a>. 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">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">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">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">the pipeline that is responsible for RabbitMQ v3.7.x</a>. This pipeline captures what is possible if imagination is set free:</div><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><br><div class="gmail_quote"><div dir="ltr">On Mon, Jan 7, 2019 at 9:52 AM Samuel Joseph <<a href="mailto:tansaku@gmail.com">tansaku@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);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" target="_blank">https://en.wikipedia.org/wiki/Continuous_integration</a><br>
<a href="https://en.wikipedia.org/wiki/Continuous_deployment" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki/Continuous_deployment</a><br>
<a href="https://en.wikipedia.org/wiki/Continuous_delivery" rel="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">Chat@lists.lrug.org</a><br>
Archives: <a href="http://lists.lrug.org/pipermail/chat-lrug.org" rel="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" 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" target="_blank">http://lists.lrug.org/listinfo.cgi/chat-lrug.org</a><br>
</blockquote></div>