It is, basically, a scaling problem. You separate your work into modules, which can be different projects and/or different functionalities of your product.
You would have teams that cover sets of those modules. Each of those teams would have CI cycles set up for their scopes, and only after their respective cycles would pass, the code would be pushed to master repos, where the master CI cycle would be run.
The master CI cycle will most likely differ from team level CI cycles in these aspects:
- Team level CI cycles do not have to build the code of entire company, just those modules that they are responsible for and the dependent modules. If there are two modules that are completely independent and in different teams, they would not be part of the other team's CI cycle.
- Team level CI cycles can have much more detailed automated tests than master CI cycle. Master CI cycle would have sanity check tests and regression tests that would, depending on the size of the master solution, be run daily or even weekly, as these tests can sometimes take more than 24 hours to execute.
What you must do with this approach is to provide automated push from local repos to central repo once the local CI cycle passes, lest your developers spend enormous amounts of time to push the code to central repos.