我们使用什么：
我们使用 mercurial 和 bitbucket 作为存储库。Appveyor 和 kudu 用于持续集成和部署。我们使用 Visual Studio 2015 作为 IDE。
我们有什么：
我们有不同的网络项目。他们分享了一些其他项目。所有的 Web 项目都有自己的解决方案。每个解决方案都有自己的存储库。
如果开发分支有变化。Appveyor 构建此存储库，对其进行测试和部署。
如果默认值有变化，kudu 会构建这个存储库并部署它。
我们想要什么：
我们希望将所有这些项目合并到一个解决方案中。但我不知道如何实现持续集成或部署。
如果我在 webproject1 上进行更改，我只想构建和部署 webproject1。解决方案中的其他 webprojects 既不应该被构建也不应该被部署。
也许单个存储库会对您有所帮助。使用相对路径来包含来自不同应用程序的共享库。
每个应用程序仍然可以拥有自己的解决方案文件，并且您的 CI 设置也保持原样。不同的是，您在所有应用程序中拥有的共享项目将使用相对路径进行引用。例如：
Repository root\Core\Component1\Component1.csproj
Repository root\Core\Component2\Component2.csproj
Repository root\Applications\App1\App1.sln
Repository root\Applications\App1\Domain\Domain.csproj
Repository root\Applications\App1\Web\Web.csproj
Repository root\Applications\App2\App2.sln
Repository root\Applications\App2\Domain\Domain.csproj
Repository root\Applications\App2\Web\Web.csproj
现在，您的不同应用程序可以通过使用相对路径将现有项目添加到解决方案来包含他们需要的 Core\Components。
您的持续集成系统将使用 VCS 触发器监视应用程序和依赖项，因此只有相关的更改才会触发构建。因此，如果 App1 开发人员对 Component1 进行了更改，并且 Component1 也被 App2 使用，则构建服务器将触发对 App1 和 App2 的构建，发出任何重大更改的信号。但是，如果 App2 不依赖于 Component1，则只会构建 App1。这是通过为您的应用程序配置构建触发器来实现的。
与使用单个 .sln 相比，此策略的一个好处是您不必在每次构建解决方案时都构建所有内容（也不必在每次使用不同的应用程序时配置要构建的项目）
另请注意，您可以使用多个存储库来实现此目的。但这意味着您需要在正确的位置检查它们，以便您的相对路径有效。它也很模糊，因为如果您检查 App1 并尝试构建它。它根本行不通，您必须弄清楚要签出的其他存储库等。
您正在使用 Mercurial，但仅供参考，使用 Git 处理的方式（其中一种）是使用submodules。