[LRUG] Continuous * (Happy New Year!)

Mon Jan 7 04:00:10 PST 2019

Hi Sam,

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.

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 *What would it take to have a single pipeline that has
an end-goal of creating production builds*? Here is a pipeline example
which stops after it publishes a Docker image: changelog.com, CircleCI
<https://circleci.com/workflow-run/065467ef-87c0-4f5e-a2ab-5e11be12403f>.
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 changelog.com case, the Docker stack that captures
the entire deployment has an update component that is responsible for app
updates
<https://github.com/thechangelog/changelog.com/blob/cf2ebe0de0f35c96bf664b8bc9183bd1f3468565/docker/changelog.stack.yml#L15-L31>.
In this specific case, if the new app version starts and is healthy for 30
seconds, it gets automatically promoted to live. We have been using a
similar approach since October 2016 <http://changelog.com/podcast/254>, a
Docker stack just makes it easier.

I want to spur your imagination by sharing the pipeline that is responsible
for RabbitMQ v3.7.x
<https://ci.rabbitmq.com/teams/main/pipelines/server-release:v3.7.x>. This
pipeline captures what is possible if imagination is set free:

* tests & builds 30+ apps...
* on all supported major runtime version...
* and all supported OSes
* tests upgrades
* tests client support
* releases alphas, betas, RCs & GAs
* and publishes to all supported distribution channels

I hope this helps, Gerhard.

On Mon, Jan 7, 2019 at 9:52 AM Samuel Joseph <tansaku at gmail.com> wrote:

> Hi LRUG,
>
> Happy New Year!  Hope you all had a good one.
>
> Apologies in advance for what has become a bit of a long post, but I
> have a question about "Continuous *", i.e.
>
> * Continous Integration (C.I.)
> * Continous Deployment
> * Continous Delivery
>
> I think I understand Continuous Integration quite well.  I take it to
> mean that all tests are run whenever you commit code to version
> repositories in the cloud, and thus we talk about C.I. providers such as
> Travis, Semaphore, CircleCI, CodeShip etc.   I interact with Travis and
> Semaphore on a daily basis and see the results of automated tests run on
> all our pull requests and again when we merge them in.  I think
> technically the concept of C.I. originally means just having all
> developers getting their work merged in to the same place with high
> frequency, but anyway, I feel relatively comfortable with this term.
>
> The way I hear Continuous Deployment being used seems to be when the
> C.I. tests are set such that on a passing build, the code gets
> automatically deployed to a server.   We have a few pipelines where we
> have develop, staging and production servers, which are automatically
> deployed to as a result of passing builds on the develop, staging and
> master branches respectively.  These deployments are supported by hooks
> on Travis, Semaphore etc. and are very handy.  Continous Delivery I'm
> not so sure - I just found the term of google
>
> Of course I have read the wikipedia pages on all these terms:
>
> https://en.wikipedia.org/wiki/Continuous_integration
> https://en.wikipedia.org/wiki/Continuous_deployment
> https://en.wikipedia.org/wiki/Continuous_delivery
>
> and while I'd love to tune up my mental pictures of each, what I'm
> really looking for the right term for the practise of automatically
> moving code along a pipeline like the one I mentioned above: develop -->
> staging --> production.
>
> At the moment the process of running tests and deploying to each server
> for each branch is completely automatic.  However, the process of moving
> code from develop to staging, or staging to production is manual.  We've
> previously reached out to Travis, Semaphore and Heroku to ask about some
> process that would automate moves along the pipeline, but the
> conversation seems confused by the ambiguity in the technology and I'm
> left thinking they don't - but could be wrong.
>
> We've recenly moved one pipeline completely from heroku to azure/dokku
> and it seems like we can now create our own automatic pipeline
> progression with cron jobs so that, say, on Monday at noon, the develop
> code is rebased into staging, and at noon on wednesday the staging code
> is rebased into production, and in each cases tests and deploys would be
> kicked off.   My main motivation to automate this is to remove the
> manual step which is a chore and can get put off.  It's particularly
> highlighted by our use of dependabot, which is automatically putting in
> PRs based on library upgrades, so every week there is a several upgrades
> to go out along with the usual features and bug-fixes.
>
> I speculate that if we had such a setup, we'd get into the habit of
> being more careful with merging PRs (knowing they'd be automatically
> deployed to production) and regularly doing the few additional front end
> manual sanity checks when we're notified of staging and production
> deploys ...  Anyway, I'd love to know if there's a correct term to be
> using to describe the pipeline automation we want to set up, and whether
> there are any providers that make it easy to do.
>
> We hear all the time about facebook, netflix etc. deploying to
> production multiple times a day, but I'm very interested to hear about
> practices at all scales.  Sorry for the long post - here's wishing
> everyone a very prosperous 2019!
>
> Best, Sam
>
> _______________________________________________
> Chat mailing list
> Chat at lists.lrug.org
> Archives: http://lists.lrug.org/pipermail/chat-lrug.org
> Manage your subscription: http://lists.lrug.org/options.cgi/chat-lrug.org
> List info: http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lrug.org/pipermail/chat-lrug.org/attachments/20190107/223589e8/attachment-0002.html>