How to work as a team on a big project?

Question

Work organization

Gentlemen, I will try to describe the question as accurately as possible.
There is a big project and a small team where everyone knows and trusts each other.
It's time to recruit additional staff, as it is physically difficult to work on a project that is constantly growing.
The most important thing that torments me is the preservation of the confidentiality of the performing part of the project. Yes, it may sound silly, but it will not be very pleasant if a new team member merges the project into the public or uses it somehow for their own needs.
Several questions arise:
1. How to organize teamwork so that everyone does their own thing and does not have access to the entire project?
2. If, let's say the front-end developer has updated the template code, how to make it so that the back-end is not constantly pulled to make these changes?
It comes to mind - deploy a copy of the project on the server, somehow delimit access to directories and project files for each employee and roll out updates to production by replacing files with updated ones.
There is another option, perhaps very stupid - to make a written non-disclosure agreement for the "stuffing" of the project. And give full access to the project files, which will be on the server for development.
I do not believe that in large projects, access to all the code was given to every back-end developer.
Some moments of the text will sound wild, which is why I want to hear the recommendations of more experienced developers on the organization of team development.
UPD: Many thanks to everyone who took part in the discussion of this issue! Your advice has been very helpful in clearing things up.
Good luck and good work!

Answer 1

1. Agreement - to anyone. To be able to bite.
In normal companies, security guards also hold regular town halls, especially for beginners, where they talk about security. And they give a couple of examples of how someone shared a piece of code, how he was sued for a lot of money and added to the blacklists of all companies.
This is for those who foolishly can.
2. Divide sources into parts. Automate the deployment so that the developer does not do it manually and does not climb anywhere - he made a commit - the CI server automatically downloaded everything needed from different repositories and deployed it. Several developers need it - make several test environments so that the developer can log into Jenkins or Teamcity, press one button and choose where to deploy. But he didn't have his own logins.
3. In any case, if someone wants to steal the code, he will do it. Making it so that there is no access for those who need this access will only harm the project.
Therefore, let normal HR work for you.
Let the team leaders look closely at people, do not bring them to conflicts.
Do not give access to everything before the trial period.
And it's still not a guarantee. Settle down =)

Answer 2

There is another option, perhaps very stupid - to make a written non-disclosure agreement for the "stuffing" of the project. And give full access to the project files, which will be on the server for development.
This is not stupid, but the only normal option.
All other attempts to hide something are doomed to failure.
For separation, you can use git submodules or just separate repositories of at least the front-back.
But doing this just to hide the code from each other is pointless.
You can code with modules, and in any way you like in general, but this is just a huge overhead for productive work.
And in the worst case, in general, you will only do what to fight this monster from a bunch of modules / repositories, instead of normal work on the product.
So most likely you have problems with the "architecture", if only the designer is a layout designer in html, and on the backend templates must also be integrated with logic / code, then it is logical to pass through backenders.
And if the designer is a frontender who makes the final piece of code, then the approach needs to be changed.
And in general with such questions - you need a project manager with technical skills or a team leader, since no one in the team has the competence to resolve these tasks.

Answer 3

1. The contract should be concluded with everyone
   
2. You must have a separate development server and production server. Only certain employees who are engaged in deployment have access to the second one.
   
3. The project itself should be divided into several subprojects. By type of back-end, interface app, api app and for each employee, issue access only within the subproject, punishing to monitor backward compatibility. So it will be easier for you, say, to write integration tests
   
4. A version control system is required. In many, as far as I know, you can restrict access for different employees
   

Answer 4

gitolite comes to mind. It is a tool for creating centralized repositories for collaborative development via git. Allows you to create modules that will look like top-level folders, create users and flexibly distribute rights.

Answer 5

The organization of the work of the project is carried out by the PM (project manager) with all the ensuing requirements for skills and abilities, you can google it.
Protection can be done in many ways. And in general, I'm sorry, the security guards are engaged in security . That is, ideally, it should be someone from your backbone of the team. Actually, if it’s not you, then send one of yours for training, even if it googles the topic and studies it on its own.
You can think of a lot of things. A written contract is useful as a safety net. And so you can use access control to files and folders, you can do something like an online editor (as I understand it, your project is a website). New features can somehow be run on separate pages, or maybe on a separate server, you can’t say so in advance without understanding the whole kitchen. In some organizations, for example, they prohibit access to the Internet and pull out all the USB connectors to make it impossible to copy. But once again I repeat - this is a separate work and responsibility. And a lot of subtleties. It's handled by a security guard. That is, for example, an employee without rights may well be able to make friends, and then ask a friend to lend access. A cool example can be seen in the series "24 hours" - there, about half the time, it is a struggle between the good and the bad with bureaucracy and access control, deceit, intrigue, exposure, the use of official powers, and periodically the bad are in power, and the good cannot get to them just because of these restrictions. The bottom line is that there is no perfect system, and neither you nor anyone else can control everything.

Answer 6

The most important thing that torments me is the preservation of the confidentiality of the performing part of the project. Yes, it may sound silly, but it will not be very pleasant if a new team member merges the project into the public or uses it somehow for their own needs.

1) To score. Domestic projects are generally in a state not suitable for public use.
2) Divide and conquer. Give everyone access only where they need to go. And nowhere else.
Such things as key/passwords, of course, should not be sewn up in the code and should not be in turnips in an accessible form either.
Well, for example, is a project for 60 developers a big one?
Everyone has access to everything. In addition to keys / passwords for payment services.
This is just a large amount of work that is tied to the specific specifics of the business and is of no interest to anyone else. Even competitors. Because there is no real data.
IMHO, in a large organization, automatic deployment processes should be established even before the time comes to take care of the secrecy of the code.
In the Russian Federation, it works only as a "take on a fright."
In Russia, the NDA does not really function. For it is impossible just to write in the contract "it is forbidden to disclose everything." You need to list specific things that have not yet been created. And in addition to the contract to sign individual acts on these specific things.
Even large firms like Yandex flew into this.
And courts were not won when it came to the code. They won only when the code from Yandex was submitted along with the "calibration" data for search.

Answer 7

Security must be handled by a security guard. As a rule, one of the most trusted members of the team becomes the security guard, because usually the verification pyramid ends there ("I control everyone, nobody controls me")
The project manager should be in charge of managing the project.
Access should be given only to that part of the code to which you need. In large commercial projects, they do not use open source git, which is not intended for this, they use VCS with the ability to distribute access to part of the project.
Of course, the contract can be concluded. True, there will be little sense in it, well, unless you take it up and really raise a complete trade secret regime that complies with the law. It's possible, but very tricky. And so - this is from honest people.
You can also put SMP. This is again a post-fact protection - that is, it will not save you from leaking the source code, but it will set fire to the "slivak".