我们使用的是什么:
我们使用mercurial和bitbucket作为存储库。 Appveyor和kudu用于持续集成和部署。我们使用visual studio 2015作为IDE。
我们拥有什么:
我们有不同的网络项目。他们分享一些其他项目。所有的Web项目都有自己的解决方案。每个解决方案都有自己的存储库。
如果开发分支有变化。 Appveyor构建此存储库,测试并部署它。
如果默认情况下有变化,kudu会构建此存储库并部署它。
我们想要什么:
我们希望在一个解决方案中合并所有这些项目。但我无法弄清楚,我是如何实现持续集成或部署的。
如果我在webproject1上更改某些内容,我只想构建和部署webproject1。解决方案中的其他web项目既不应该构建也不应该部署。
答案 0 :(得分:0)
也许单个存储库可以帮助您。使用相对路径来包含来自不同应用程序的共享库。
每个应用程序仍然可以拥有自己的解决方案文件,并且您的CI设置也保持不变。更改的是,您在所有应用程序中共享的项目将使用相对路径进行引用。 E.g:
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进行了更改,并且App2也使用了Component1,则构建服务器将触发对App1和App2的构建,发出任何重大更改的信号。但是,如果App2不依赖于Component1,那么只会构建App1。 这是通过为应用程序配置构建触发器来实现的。
这个策略与单个.sln的一个好处是,您每次构建解决方案时都不必构建所有内容(也不需要在每次使用其他应用程序时配置要构建的项目)
另请注意,您可以使用多个存储库来实现此目的。但这意味着您需要在正确的位置检查它们,以便您的相对路径能够正常工作。它也非常模糊,因为如果你签出App1并尝试构建它。它只是不会工作,你必须弄清楚哪些其他的回收,等等。
你正在使用Mercurial,但使用GYI,使用Git处理的方式(其中之一)是submodules。