作为一名开发人员，我对在正常开发过程中使用连续集成非常陌生。然而，我的任务是将ci引入我们的软件团队，因此我做了一些尝试来实现这一点。
目前，我们有以下产品：0.BitBucket作为我们的源回购1.球队所在城市2.ProGet服务器3.八达通部署4.开发测试vm5.UAT测试vm6.生产vm
一般来说，这个过程是
- 列出项目
- 查看BitBucket的解决方案
- 进行更改
- 提交到Bitbucket
- 团队城市建筑
- Team City将工件作为nuget包推送到ProGet
- TeamCity在OctopusDeploy中创建发布，并触发对DevelopmentTestvm的自动部署
- 手动八达通推送至UAT
- 手动八达通推送生产
除了我们开发人员之外，顶级的一切对每个人来说都很好。
我们的问题不在于概念，而在于与过程共存。原因是我们有两个解决方案，其中第二个引用了来自ProGet服务器的第一个解决方案的nuget包。这意味着，每次从属解决方案需要在第一个解决方案中进行修改时，我们都必须等待循环发生，然后在第二个解决方案更新nuget包以完成所需的更改。
当这个周期需要在达到所需结果之前多次发生时，这真的会令人沮丧。
我希望在开发者的pc上开发这两种解决方案，而无需等待ci构建并发布更改后的包。我认为这意味着第一个解决方案的dll将在本地引用，但我如何更改这一点，使最终引用来自ProGet服务器，并建立在CI框上？
有人能告诉我怎么做吗？
此工作流程可能非常具有挑战性；我们看到很多用户迁移到一种更加"基础设施即代码"的方法。
请考虑本教程"使用Otter部署ASP.NET和Windows服务应用程序"--其思想是，通过MSBuild（在工作站上的Release模式下或在TeamCity中）构建解决方案会创建一个包文件（UPack或NuGet无关紧要）。
然后，作为开发人员，您可以添加一个步骤，使用Otter Romp在本地配置/部署该包，并使用常规Otter确保该包/配置存在于其他环境中。这样，从本地到开发，从测试到生产，这是一种一致的方法。
不管怎么说，这描述了一种非常不同的方法，所以它可能不是你问题的好答案，但你问了一个流程变化，所以这是我经常看到的。
另请参阅：KB#1114-比较：章鱼部署与水獭
__
免责声明，我的日常工作在Inedo：）