[LRUG] Continuous * (Happy New Year!)

Mon Jan 7 03:55:47 PST 2019

> automatically moving code along a pipeline like the one I mentioned above: develop --> staging --> production.

What are the criteria for moving between stages here? Having a pipeline usually entails deploying to one stage, then doing something, then moving to the next stage if that thing is successful.
With automated tests it's easy to understand - you can deploy to develop without running the tests and then promote to staging if the tests pass. Heroku pipelines kinda support this, but rather than have one 'develop' stage you have different review apps per PR. Other than that, I don't really understand why you would want to deploy to any stage if the tests are not passing.
For moving automatically from staging to production - why? Or rather, what would 'moving' entail here? You could set up your production app(s) to automatically deploy under the same criteria as staging. But typically the point of having a staging environment in a pipeline is to do some additional checks in a production-like environment prior to pushing changes live. This means that typically you don't want things to move automatically.
If you just want to keep staging and production in sync then you don't want a pipeline. In heroku, just put multiple apps into the same pipeline stage. (I do this to keep production and demo environments in sync.)
Continuous deployment is relatively easy. With heroku there is a link for each app in a pipeline to configure automated deploys when a branch changes. Other PaaS would doubtless have something similar. Automated pipelines are more difficult because you need to understand the rules for advancing along the pipeline, and those rules tend to be bespoke (as Sasha pointed out).

On Jan 7 2019, at 11:20 am, Samuel Joseph <tansaku at gmail.com> wrote:
>
> Hi Sasha,
> 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.
> 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.
> 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 ...
> All the same, really appreciate you taking the time to reply.
> Best, Sam
> On 07/01/2019 11:14, Sasha Gerrand wrote:
> >
> > You're referring to "continuous deployment", which many service providers like Heroku offer (Heroku call it "pipelines").
> >
> > 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).
> > On Mon., 7 Jan. 2019, 20:52 Samuel Joseph <tansaku at gmail.com (https://link.getmailspring.com/link/1546860212.local-c804a13b-3075-v1.5.5-b7939d38@getmailspring.com/0?redirect=mailto%3Atansaku%40gmail.com&recipient=Y2hhdEBsaXN0cy5scnVnLm9yZw%3D%3D) 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://link.getmailspring.com/link/1546860212.local-c804a13b-3075-v1.5.5-b7939d38@getmailspring.com/1?redirect=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FContinuous_integration&recipient=Y2hhdEBsaXN0cy5scnVnLm9yZw%3D%3D)
> > > https://en.wikipedia.org/wiki/Continuous_deployment (https://link.getmailspring.com/link/1546860212.local-c804a13b-3075-v1.5.5-b7939d38@getmailspring.com/2?redirect=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FContinuous_deployment&recipient=Y2hhdEBsaXN0cy5scnVnLm9yZw%3D%3D)
> > > https://en.wikipedia.org/wiki/Continuous_delivery (https://link.getmailspring.com/link/1546860212.local-c804a13b-3075-v1.5.5-b7939d38@getmailspring.com/3?redirect=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FContinuous_delivery&recipient=Y2hhdEBsaXN0cy5scnVnLm9yZw%3D%3D)
> > >
> > > 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 (https://link.getmailspring.com/link/1546860212.local-c804a13b-3075-v1.5.5-b7939d38@getmailspring.com/4?redirect=mailto%3AChat%40lists.lrug.org&recipient=Y2hhdEBsaXN0cy5scnVnLm9yZw%3D%3D)
> > > Archives: http://lists.lrug.org/pipermail/chat-lrug.org (https://link.getmailspring.com/link/1546860212.local-c804a13b-3075-v1.5.5-b7939d38@getmailspring.com/5?redirect=http%3A%2F%2Flists.lrug.org%2Fpipermail%2Fchat-lrug.org&recipient=Y2hhdEBsaXN0cy5scnVnLm9yZw%3D%3D)
> > > Manage your subscription: http://lists.lrug.org/options.cgi/chat-lrug.org (https://link.getmailspring.com/link/1546860212.local-c804a13b-3075-v1.5.5-b7939d38@getmailspring.com/6?redirect=http%3A%2F%2Flists.lrug.org%2Foptions.cgi%2Fchat-lrug.org&recipient=Y2hhdEBsaXN0cy5scnVnLm9yZw%3D%3D)
> > > List info: http://lists.lrug.org/listinfo.cgi/chat-lrug.org (https://link.getmailspring.com/link/1546860212.local-c804a13b-3075-v1.5.5-b7939d38@getmailspring.com/7?redirect=http%3A%2F%2Flists.lrug.org%2Flistinfo.cgi%2Fchat-lrug.org&recipient=Y2hhdEBsaXN0cy5scnVnLm9yZw%3D%3D)
> >
> >
> >
> >
>
> _______________________________________________
> 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/52544cee/attachment-0003.html>