There is a moment when you begin to understand that, in micro service architecture, it is more scary to wait a week to deploy all micro services at once to make sure that everything works together, than to strictly enforce api versioning, write lots of automatic tests (a bit of each: unit and exploratory, integration), and auto deploy to production as soon as your commit passes as tests on stage.
Now, it looks like a great idea as long as you remember to write tests, test you changes before committing, know how to use API versioning, and you are not going to drop database in your incremental db update script that's executed on deployment (which is not a big issue as it should fail on stage).
But is it feasible to do it with junior programmers? Maybe I will have to implement pull-request schema. This would make it less like continuous deployment (that's my guess)?
I hope this is not opinion based and I can count on you sharing your experience, thanks.
Please note, I'm not asking about CI nor about continuous delivery. We already have that. What we are trying now is to make it continuous deployment which means having it all on production just after code check-in.
Best Answer
Why not? Any of the things you describe would be a problem whether you use continuous deployment or not. The problem, it seems, is that you are worried the juniors will make a catastrophic mistake. And that that mistake will be rushed into production before anyone can catch it.
That's why you do code reviews and do testing. Before anything gets merged into your master branch and slated for release, require it be code reviewed, both by some other juniors (so they get experience) and by senior developers (to use their expertise to make the code better). Everyone should be looking for these catastrophic bugs. And it should stop them. If it doesn't, you probably need some better QA / testing on a staging environment (and maybe some better developers if code reviews miss these things).