Controlling and managing separate git repos on Azure DevOps for code security

Question

My company is about to onboard some junior devs for the first time, and we want to limit their access to just the presentation layer. As it stands, everything is in one Git repo. The current plan is to fork the main repo, and modify it such that only presentation layer and the compiled assembles will be left. The new devs can then branch from there. The lead dev can just do the merge himself.

Is there a better and optimal way to approach this?

Answer 1

Some options:

1. Merge request reviews can be a great way to enforce the team's standards for quality, security, etc. across the board, and to ensure that only code of sufficient quality ends up in the repository. Seniors should review juniors' code, but juniors should also review seniors' code. Both can learn from each other, because being senior doesn't mean you know a superset of everything a junior knows.
2. CI pipelines enforce those parts of the coding standard which it can be easy to automate: running tests, linting code, packaging deliverables, and deploying. Running the CI pipeline successfully must of course be a requirement for merging anything to the main branch, and any changes to the CI pipeline itself must be scrutinized extra carefully.
3. Code review checklists can be a good way to onboard someone to what is expected in the project. In my experience each team and usually each project ends up with a different idea about what is considered the minimum quality. These checklists should be amended whenever the team agrees on some improvement they want to see in all new code, and should ideally be reviewed by at least a senior and junior developer, to make sure everybody is on the same page.

I would recommend using all of the above. Some caveats:

1. Make sure that no single person has to review everything. They will probably end up doing very superficial code reviews, resulting in a bad code base over time, a terrible bus factor and people not learning as much as they could from the reviews. Alternatively they will be stuck doing nothing but code reviews, and will probably leave because that would be career suicide.
2. Trust is essential to programming projects. Trust people to do the best possible job given the available knowledge, tools and other resources. Breaking software is so easy that otherwise you might as well do the job yourself.