[LRUG] Continuous * (Happy New Year!)

[Samuel Joseph]

Hi Murray,

On 08/01/2019 14:56, Murray Steele wrote:
> Someone already asked this, but what does “rebasing along the 
> pipeline” mean?  I’d expect to do some rebasing on my feature branch 
> to pick up changes to the main branch, but that deploys would be that 
> I merge my branch into master/develop/whatever and that goes 
> automatically to a develop/uat/preview environment.  Then <something 
> happens> and I do a merge-commit of that branch onto staging and it 
> goes automatically to the staging environment.  The <something 
> happens> happens again and I do a merge-commit of the staging branch 
> onto production and that goes automatically to the production 
> environment.  If you’re doing rebasing instead of merge-commits here 
> (or even ff merge’s) something seems complex as rebases aren’t 
> guaranteed to not need human intervention. Right?

I'm not sure about that.  I guess it depends what we're assuming about 
the branch we're merging or rebasing into.  I have often found that 
rebasing can be trickier than merging, but also that both both merging 
and rebasing can lead to conflicts that need manual intervention.    
I've almost never had a problem rebasing along the pipeline, and I think 
it creates a smoother git history that is then really easy to interpret 
in terms of what needs to be tested manually, i.e. what are the latest 
items going out.

But merge along the pipeline, rebase along the pipeline, whichever is 
fine; either way that's the manual step that I'm trying to avoid.  From 
your description above you've got manual merge steps (maybe you're just 
elaborating on my example?) but what I'm hearing in other threads is 
that folks have pipelines from staging to production all from a single 
branch with no git action involved in code being deployed first to 
staging and then production - that's a new model to me, and what I'm 
really keen to understand is in that case, what is the trigger for 
deployment to production?  Simply a successful deploy to staging?

>
> The other thing that confuses me is that it sounds to me that the 
> manual checks are the blockers, not the “rebasing along the 
> pipeline”.  As others have said, I’d be looking into automating those 
> steps as much as possible if I wanted to improve the process.  If they 
> can’t be then I’d look into automating a “hey the rebase onto 
> <environment> has happened, and you started it, so you should now do 
> those manual checks” notification to keep everyone on their toes.  
> Maybe also some “Hey, X commits are on "master" but not on 
> “production”, sort it out!” notifiers too.

That's a good suggestion, although that might work best if we had all 
paid developers to impose that on.  We do have some paid developers but 
many many open source volunteer contributors.  We would love to get them 
all involved in taking responsibility for taking their contributions all 
the way to production, but that's a bit of an uphill struggle :-/  Good 
suggestion though - my thought about automating the git moves along the 
pipeline is like, hey everyone, tuesday morning is the day we check 
staging, and thursday morning is the day we check production kind of 
thing ... it's out there on staging on Tuesday and if we don't check it 
will be on production on Thursday so better fix any issues or stop the 
deploy - but either way gotta be done ...

Anyhow as I was saying, we do have automated tests for all the things 
that we might check on staging as "sanity" checks, but this is what I've 
always found strange about the heroku model is that you can't run 
automated tests on the actual servers - or are you saying have some 
manual tests that poke production over http? Back in the day (2006) when 
we had our own servers we'd be running our tests on our servers in test 
mode (using the rails test db etc.) and I felt more confident that 
passing tests meant working server, but even then there was still room 
for slight changes in configuration to cause problems.

So maybe the solution is a better devops set up that allows us to match 
the prod configuration more precisely in CI or on the staging server - 
at the moment we've got staging rigged to be as close as production as 
possible, but then there are always some differences like intercepting 
emails and notifications etc.

Anyway, what I'm really interested to hear is about anyone's pipeline 
from dev to production that doesn't involve any manual steps at all, 
i.e. no git operations, no checking any servers, no testing any UIs; 
where code that gets merged will automatically end up on production with 
no eyeballs and no typing - or maybe no one has that ...?

Apologies if I'm being thick and/or dragging this out etc.  Feel like 
there's still a lot for me to learn/understand, get clear here ...

Thanks so much for everyone's input.

Best, Sam

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lrug.org/pipermail/chat-lrug.org/attachments/20190114/aed8d438/attachment-0003.html>