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.

  • 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 (...), and auto deploy to production as soon as your commit passes as tests on stage - that's opinion based ;) IMHO it's much more difficult to ensure success with independent service deployment than with a monolithic approach: softwareengineering.stackexchange.com/a/342346/187812. And with true CI (no feature/integration branches) you shouldn't have to wait for a week. Apr 1, 2017 at 3:59
  • A good CI system should help - everyone makes mistakes, not just the juniors. And breakages don't necessarily mean developers made mistakes or didn't do their job properly, see How can successfully pre-verified changes cause regressions which should have been caught? Apr 1, 2017 at 4:06

6 Answers 6


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).

  • 1
    I am worried that using feature branches and pull requests makes it less of continuous deployment. On of aspects that I want to solve is compatibility between components. I'm sure they do work together after I make one change in one of services. I feel stressed when we have to push all together after many changes. If I review changes before they join master branch then I might even confuse order of changes as components are in different repos.
    – doker
    Mar 31, 2017 at 12:09
  • @doker If you are worried about having to push a lot of services together, then don't. Make sure each service (and the changes made to it) stand on their own. If service A is changed, do a quick code review to make sure it will work with the new changes and can be deployed on it's own. If breaking changes are made, use the code review as a place to enforce API versioning. If service B depends on service A, do the work on A first then get that out. Then work on B. If a junior hands you changes to A, B, C and D and they are all interdependent, they need to document that so you can review.
    – Becuzz
    Mar 31, 2017 at 12:57
  • 1
    @doker These kind of scenarios are why continuous deployment/delivery people are often very pro-feature-switches. If your changes are typically behind feature switches (not necessarily every little change), then you can deploy pieces whenever with the features off, turn them on when all the pieces are in place, and turn them off if you find a significant problem. Apr 2, 2017 at 5:32

Continuous deployment will work well if you have a good set of automated tests.

Junior developers can get excited about their own task and don't see that they break things around. You can fix this with some automation. Set up a build server that will run tests all the time, and get them a tool like CatLight build notifier. It will give them a quick and clear feedback when they break things.

CatLight build status icon

They will fix small problems as they happen and keep your continuous delivery running.


The only way to learn good habits is to practice them, so yes junior developers can also practice continuous deployment. You might want give some thought to adding steps into the pipeline to do things like check test coverage and possibly run a static code analysis, and fail the build if test coverage isn't high enough. That will ensure that junior devs understand the expectations before something is considered complete.


Not only that you can do this with junior developers but it is required of you. First, you'll reduce your software quality otherwise, and secondly this helps junior developers learning good software development skills.

As an analogy: Would you like your doctor to not practice medicine to the best of his knowledge because he'll be afraid of young apprenticeship errors? How does doctors deal with the potential damage?


From past experience with a Big Ball Of Mud code-base which evolved naturally over many years at the hands of many unsupervised junior developers, I would like to point out what happens when you don't practice CI with those developers.

Edit/Update: As per RubberDuck's comment; this answer assumes that your merge target for integration is a development branch rather than an evaluation or release branch.

  • Obviously there needs to be a lot more control over code for release and live deployment; if there isn't a separate production branch then it would be worth considering a change to your branching/merging strategy to run a master development branch (which is used for integration testing and never for release) alongside the master release branch. This keeps all the benefits of CI and frequent merges without risking breaking production code.

1. Junior developers are less likely to communicate with their co-workers or supervisor

Continuous integration is not simply a matter of merging in code, it is a point in time whereby a developer is forced to interact with other stakeholders.

Communication is important, and without wishing to over-generalise, it tends to be a learned skill which arrives less naturally to inexperienced developers than to those who are used to working in a team environment.

If you allow junior developers to sit in their cubicle and bash away at code for weeks without being asked for frequent reports/reviews, then they are more likely to avoid communication altogether.

2. The code they are producing is likely to need more rigorous review

Have you ever reviewed something which was so bad that you wished you'd picked it up earlier and prevented it from ever having been written? This happens a lot.

You cannot prevent bad code from being written, but you can limit the time wasted. If you commit to frequent reviews and merges, then you minimise the scope for wasted time.

The worst-case-scenario is that you may leave a junior developer alone for several weeks on their own miniature project, and when they are finally ready for the code review, there simply isn't enough time remaining for them to throw the whole mess away and start again from scratch.

Many projects become a big ball of mud simply because a whole load of bad code got written when nobody was paying attention until it was too late.

3. You should be less-certain that a junior developer or other new team member has understood the requirements

Sometimes a developer might build the perfect solution to the wrong problem; this one is sad because it's usually down to simple misunderstandings which would be so easy to avoid if only somebody had asked the right question(s) earlier on in the process.

Again, this is a problem which is more likely to affect inexperienced developers who are more likely to accept "bad" requirements at face value instead of pushing back and questioning the wisdom of the requirement.

4. They are likely to be less familiar with common patterns, with the architecture of existing code, and with well-known tools and solutions

Sometimes a developer spends a whole load of time re-inventing the wheel unnecessarily simply because they didn't know that a better solution even existed. Or they might spend days trying to hammer a square peg into a round hole without realising what they're doing wrong.

Again, this sort of thing is more likely to happen to inexperienced developers, and the best way to address the issue is to ensure regular reviews.

5. Long periods between code commits/merges makes defects harder to identify and fix

When a bug emerges immediately after many weeks worth of code changes have been merged into the master branch, the challenge of identifying which change may have caused the bug gets more difficult.

Obviously your overall branching strategy also comes into play here; ideally all of your developers will either be working in their own branches, or within feature branches (or both), and will never work directly off the master/trunk.

I've seen situations where entire teams are all working directly into the master/trunk at the same time, and this is a terrible environment for CI, but luckily the solution of pulling everybody away from master/trunk generally provides enough stability for individual work items/tickets/etc.

It should always be "OK" for any developer to break the master/trunk branch, with the understanding that merging should happen on such a regular basis, that breaking changes and defects should be identified more quickly, and therefore resolved more quickly too. The worst defects are typically those which remain undetected for months or even years.

In summary; the main advantages of continuous integration / continuous deployment are:

  • Communication among your team improves
  • Code quality is generally maintained at a higher standard
  • Requirements are less likely to be missed or misinterpreted
  • Architecture and design issues should be detected more quickly,
  • Defects are more likely to be detected and fixed at an earlier stage

So if you're not practising CI with your junior developers, then you are accepting a lot of significant unnecessary risk, as these are the members of your team who need it more than the rest.

  • OP is talking about a model where commits to master trigger an actual deployment into production. So, no. It's not okay to break the master branch in that model.
    – RubberDuck
    Apr 2, 2017 at 15:47
  • @RubberDuck good point, added a comment to make it clear that this approach is for integration testing and not for pushing new code changes directly to a production branch. Apr 2, 2017 at 20:35

Yes, you can practise CI with junior developers. It would be stupid not to in the current development climate. It's insanely useful to be able to push to repo and then have that be automatically merged into staging code -- and to watch it all in real-time in Travis (or Bamboo, Pipelines etc...)!

Take your DevOps guy and have him go through the process with them, plus a senior dev on standby just to watch over things and link it up with their code reviews (you do those, right?)

If your concern is that shite code is going to get through, that isn't on the CI and it's not on the juniors: it's on you.

So help them get better and used to deploying stage/prod code quicker. You'll thank yourself in the long-run.

  • 1
    OP is talking about Continuous Deployment not Continuous Integration / Delivery
    – RubberDuck
    Apr 2, 2017 at 15:45

Not the answer you're looking for? Browse other questions tagged or ask your own question.