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.
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. – Dan Cornilescu Apr 1 '17 at 3:59