如何从“奥术整合”迁移到持续整合？

Question

现在，我正在开展的一个项目达到了复杂程度，需要多个步骤（实际上它变得神秘！）才能生成完整/可用的产品。不幸的是，我们并没有开始使用Continuos Integration的思维模式，所以你可以想象它有时会很痛苦，而在其他人看来，我可以轻松地浪费半天时间来试图获得干净/经过测试的构建。

无论如何，任何巨大的项目都包含许多不同语言的许多组件（例如企业风格的Java或C＃），以及许多图形和文本资源。现在的问题是，当我寻找Continuos Integration时，我总能找到最佳实践和技术，假设一个人从头开始创建一个新项目。然而，这不是一个新项目，所以我想知道什么是积极开始从奥术整合迁移到Continuos集成的一些好资源：）

提前致谢！

Answer 1

这是两个简单的（哈）步骤。

1. 寻找可重复的构建：
   1. 使用源代码管理，检入所有代码。
   2. 建立并记录用于构建的所有工具（主要是哪个编译器版本）。为这些工具进行可重复的部署和设置过程。
   3. 明确建立并记录构建所需的任何资源，但不进行检入（第三方安装，服务包等）。为这些依赖项进行可重复的部署和设置过程。
2. 在开始使用源代码控制之前，开发人员必须这样做
   1. 更新他们的工作副本
   2. 成功构建
   3. 运行并通过自动化测试

这些步骤可以一次完成1个步骤，这是一个可以遵循的路径。你会在每个阶段获得好处。例如，如果您根本不使用源代码控制，只需将代码放入源代码控制（没有任何其他内容）是向前迈出的一大步。此外，如果没有自动化测试，那么开发人员就无法运行它们 - 但是他们仍然可以获得先前的提交并让编译器检查他们的工作。

如果你能做到这一切，你就会到达一个理智的地方。

目标是可重复的构建过程和开发人员，这些过程和开发人员将了解他们的更改如何影响构建和其他开发人员。

然后你可以通过建立更高的合规性来获得奖金：

• 开发人员建立了频繁的提交习惯。工作副本中的代码不应超过1天。
• 自动构建过程监视签入的源代码控制，并将结果发送到用户可以接受它们的位置（例如测试环境，预览网站，甚至只需将.exe放在用户可以找到它的位置） ）。

Answer 2

与吃大象的方式相同（一次吃一口）;-)持续集成需要自动构建。从那开始。自动构建每件作品。 Ant或NAnt是一种很好的方法。让每个组件的构造成为NAnt任务。然后，您的整个系统构建可以聚合这些单独的任务。

从那里，您可以添加部署任务，单元测试等。如果您想使用CI技术，可以将其连接到您的NAnt构建。

Answer 3

我首先要写下你手动完成构建和测试所需的所有步骤。在那之后，你至少要有一个以旧方式去做的指南，写下来让你有机会把它看作一个完整的过程。

然后查找脚本部分。

理想情况下，您希望从代码提交中触发构建和测试，并且仅重建和重新测试更改的部分，可能每晚或每周进行完整构建和测试。您将需要日志文件或数据库条目以及有关构建成功或缺少构建成功的报告。

您需要搜索并评估预构建的产品和开源构建您自己的工具包。您当然可以自己编写所有脚本和报告，但这需要一段时间，因为您的工作是对产品进行编码，而不是对构建系统进行编码，因此您最终可能会得到一个刚刚好的报告系统。 ： - ）

Answer 4

我猜想迁移不是一个真正的选择 - 半屁股解决方案只会让情况变得更糟。

我的方法是聘请一位了解构建过程的创意工程师，让他坐下来说“修复此问题”。给他一两个星期。

最终目标是使用单个make命令从头到尾运行的进程。

我还建议使用自动“设置”程序，您只需执行结帐并从网络共享运行批处理文件即可安装和构建所有工具。如果引入新的程序员，这将节省的总时间是惊人的。大多数项目需要一到三天的时间才能在新计算机上安装 - 并且它总是“新”程序员不知道在他自己的系统上进行安装会发生什么......

Answer 5

简而言之：增量

选择适用于各种项目的框架。

逐个添加组件到框架中。

如果您不熟悉该框架，请先解决几个较简单的组件，以降低搞砸的风险。

如果您确实了解该框架，请首先处理一些较为困难和/或通常构建的组件，以便您的团队（和管理层）尽早体会到这些优势，并更多地支持这些工作。

请确保计划包含所有组件，因为这样才能实现全部优势。

带上你的团队;确保你已经达成共识，这将是有价值的，或者人们不会随着组件的变化而维护它。