Recentemente, migramos quase todo o código fonte da minha empresa para uma única solução.
Por quê?
Originalmente, tínhamos dezenas de soluções. Alguns projetos de uma solução reutilizaram projetos de outro e ninguém se preocupou em usar um gerenciador de pacotes. No dia em que você altera substancialmente um projeto usado em quase todos os lugares, espera horas e horas de trabalho perdido para toda a empresa nos próximos dias ou semanas. A pior parte é que você nem sabe o que exatamente seria afetado pela mudança.
Mesclar todo o código em uma solução era uma alternativa. Funciona bem no momento, e as dependências agora são fáceis de seguir. Deseja modificar um método, mas também acompanhar as repercussões que essa alteração pode ter em qualquer lugar da base de código? O Visual Studio pode fazer isso com facilidade. Para mim, é um sucesso.
Agora, a integração contínua também é mais fácil. Uma solução para compilar e implantar. Quase nada para configurar.
É escalável?
Em termos de desempenho, fiquei muito surpreso com o Visual Studio . Eu pensei que ele começaria a chorar com uma solução com, digamos, 50 projetos. Hoje, existem mais de 200 projetos; O Visual Studio parecia ser escalável o suficiente para gerenciá-los como se houvesse apenas 20 deles. Sim, há coisas que levam tempo. Se você recompilar todos os projetos, com contratos de código, análise de código ativada por padrão etc., espere que demore um pouco. Mas ninguém esperaria compilar 200 projetos tão rapidamente quanto 10 e, a propósito, você não deveria: esse é o papel do servidor de integração contínua. O tempo de inicialização (inicialização a frio e carregamento da solução) é impressionantemente rápido ; talvez não seja tão rápido quanto em 10 projetos, mas ainda seja muito aceitável (menos de 20 segundos em uma máquina comprada há mais de cinco anos).
Para ir ainda mais longe, o descarregamento sistemático de projetos é uma boa ideia (e muito fácil quando os projetos são organizados em diretórios na solução). Se alguém trabalha em algo que exige que apenas três projetos sejam carregados, não há necessidade de carregar todos os 200 projetos (a menos que, é claro, as dependências possam ser afetadas).
O controle de versão também funciona como esperado (estou usando um servidor SVN, se for o caso). Não trabalhei em um ambiente simultâneo real, com, digamos, dezenas de desenvolvedores frequentemente comprometendo código, mas imagino que isso não tenha muitos problemas. Apenas tenha cuidado com os casos em que muitos desenvolvedores adicionam novos projetos ao mesmo tempo: mesclar o arquivo .sln não é a coisa mais fácil de fazer.
Conclusão
Se eu tivesse que escolher a decisão novamente:
Eu ainda migraria tudo para uma única solução. Isso reduz enormemente a dor de dependências quebradas, e esse benefício por si só vale totalmente a pena. Ter um local centralizado para todo o código também é uma boa ideia; isso possibilita, por exemplo, procurar algo no Visual Studio. Também posso trabalhar em dois projetos fracamente relacionados e ainda ter apenas uma janela do Visual Studio aberta.
Eu também estudaria um pouco mais o NuGet e a capacidade de hospedar um servidor privado do NuGet. O gerenciamento das dependências através do NuGet pode resolver alguns dos problemas quando você não deseja mesclar alguns projetos na solução comum. Pessoalmente, não tive casos assim, mas imagino que outras empresas possam ter.
Finalmente, investir em um SSD para cada desenvolvedor pode fazer uma enorme diferença. Mas você não precisa e, no meu caso, a base de código ainda está armazenada em um disco rígido comum.