0

作为开发人员，我对在正常的开发过程中使用持续集成非常陌生。然而，我的任务是将 ci 引入我们的软件团队，因此我做了一些尝试来实现这一点。

目前我们有以下内容： 0. BitBucket 作为我们的源代码库 1. Team City 2. ProGet 服务器 3. Octopus Deploy 4. 开发测试虚拟机 5. UAT 测试虚拟机 6. 生产虚拟机

一般来说，这个过程是

  1. 项目清单
  2. 从 BitBucket 查看解决方案
  3. 做出改变。
  4. 提交到 Bitbucket
  5. 团队城市建设
  6. Team City 将工件作为 nuget 包推送到 ProGet
  7. Team City 在 Octopus Deploy 中创建发布并触发自动部署到 Development Test vm。
  8. 手动八达通推送到 UAT
  9. 手动八达通推送到生产

除了我们开发人员之外，顶层的一切看起来都很好。

我们的问题不是概念，而是与过程共存。原因是我们有两个解决方案，其中第二个从我们的 ProGet 服务器引用第一个解决方案的 nuget 包。这意味着每次依赖解决方案需要在第一个解决方案中进行修改时，我们都必须等待循环发生，然后在第二个解决方案中更新 nuget 包以完成所需的更改。

当这个循环需要多次发生才能达到所需的结果时，这真的很令人沮丧。

我希望在开发人员的电脑上开发这两种解决方案，而无需等待 ci 构建和发布更改的包。我认为这意味着第一个解决方案中的 dll 将在本地引用，但我如何更改它以便最终引用来自要在 CI 框上构建的 ProGet 服务器？

谁能告诉我该怎么做？

4

1 回答 1

-1

这个工作流程可能会变得非常具有挑战性；我们看到很多用户正在迁移到更多的基础设施即代码方法。

考虑本教程使用 Otter 部署 ASP.NET 和 Windows 服务应用程序——想法是，通过 MSBuild（在工作站上的发布模式或 TeamCity 中）构建解决方案会创建一个包文件（UPack 或 NuGet，不会事情）。

然后，作为开发人员，您可以添加一个步骤以使用Otter Romp在本地配置/部署该包，并使用常规Otter以确保该包/配置存在于其他环境中。这样，从本地到开发到测试到生产，这是一种一致的方法。

无论如何，这描述了一种非常不同的方法，因此它可能不是您问题的一个很好的答案，但是您询问了流程更改，所以这是我经常看到的一个。

另请参阅：KB#1114 - 比较：Octopus Deploy 与 Otter

__

免责声明，我的日常工作是在 Inedo :)

于 2016-05-12T13:50:00.090 回答