[LRUG] Continuous * (Happy New Year!)
tansaku at gmail.com
Mon Jan 14 02:14:01 PST 2019
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Chat