In my company, it's common not to do any intermediate build to check how each feature/bugfix branch is merged in dev. There is only daily build, which always elicit a lot of test fails and build errors. I have been told that it's unreasonable to do build for each merge for over 1000 developers.

So I searched how CI is organized in companies that have that much developers or more (Microsoft, Facebook), and found nothing. Maybe, insiders can tell me then?

  • @gnat Are you adequate? How it's related? I asked for insider experience, and pointed companies just for example. I didn't asked any customer support.
    – Megamozg
    Aug 11, 2017 at 12:34
  • 11
    @gnat I don't see how it is related to that. Megamozg : CI is organized by module of projects, there is no module with 1000 developers. So if there are too much people, cut down your project/module in smaller part.
    – Walfrat
    Aug 11, 2017 at 12:35
  • @Walfrat it is totally related. This site is not for making surveys / polls of big companies insiders about how their companies do various things. If one is curious about stuff like that they should use support channels of these companies
    – gnat
    Aug 11, 2017 at 15:22
  • @gnat I really don't see how the link you provided applied, especially with the comment you provided in response to Walfrat. Based on that comment this IMHO would be the proper link (the part about poll type questions) softwareengineering.meta.stackexchange.com/a/6490
    – Newtopian
    Aug 11, 2017 at 16:41

2 Answers 2


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.


In addition to what @Vladimir_Stokic said, on some teams (mine has ~150 developers), we do builds more frequently than every 24 hours. Whenever a commit occurs, we start a 5 minute timer. After the 5 minutes are up, all commits that happened during the 5 minute interval are combined and built. The build is usually an incremental build. We have a separate builder that runs unit tests for each build that occurs. After the build is finished, if there were any more commits during the build (which takes between 1 and 45 minutes depending on what changed), any pending changes are built, and so-on. We also have a nightly (clean, full) build, but the builds that happen on each commit (roughly) tell us very quickly whether any tests fail.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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