现在，我正在进行的一个项目已经达到了一个复杂程度，需要多个步骤（实际上它变得神秘！）才能生产出完整/可用的产品。不幸的是，我们一开始并没有采用 Continuos 集成的心态，所以你可以想象它有时会很痛苦，而在其他情况下，我很容易浪费半天时间来尝试获得一个干净/经过测试的构建。
无论如何，作为任何 HUGE 项目，它由许多不同语言的组件组成（不仅是企业风格的 Java 或 C#，例如），以及许多图形和文本资源。现在的问题是，当我寻找 Continuos 集成时，我总是会找到最佳实践和技术，假设人们正在从头开始一个新项目。然而，这不是一个新项目，所以我想知道有哪些好的资源可以主动开始从 Arcane Integration 迁移到 Continuos Integration :)
提前致谢！
这是两个简单的（哈哈）步骤。
这些步骤可以一次完成 1 个，有点像要遵循的路径。您将在每个阶段获得好处。例如，如果您根本不使用源代码控制，那么只需将代码放入源代码控制（无需其他任何东西）就是向前迈出的一大步。此外，如果没有自动化测试，那么开发人员就无法运行它们——但他们仍然可以获得先前的提交并让编译器检查他们的工作。
如果你能做到所有这些，你会得到一个很好的理智的地方。
目标是可重复的构建过程和开发人员，他们将插入他们的更改如何影响构建和其他开发人员。
然后，您可以通过建立更高的合规性来获得红利：
就像你吃大象一样（一次咬一口）；-) 持续集成需要自动化构建。从那开始。自动构建每件作品。Ant 或 NAnt 是执行此操作的好方法。让每个组件的构造成为 NAnt 任务。然后您的整个系统构建可以聚合这些单独的任务。
从那里，您可以添加用于部署、单元测试等的任务。如果您想使用 CI 技术，您可以将其连接到您的 NAnt 构建。
我会首先写下手动构建和测试所需的所有步骤。之后，您至少有一个以旧方式进行操作的指南，并且写下来让您有机会将其视为一个完整的过程。
然后寻找要编写脚本的部分。
理想情况下，您希望从代码提交触发构建和测试，并且只重建和重新测试更改的部分，可能每晚或每周进行一次完整的构建和测试。您将需要日志文件或数据库条目，并报告构建是否成功。
您需要搜索和评估预构建产品和开源构建您自己的工具包。您当然可以自己编写所有脚本和报告，但这需要一段时间，而且您最终可能会得到一个勉强够用的报告系统，因为您的工作是对产品进行编码，而不是对构建系统进行编码。:-)
我猜想迁移并不是一个真正的选择——半途而废的解决方案只会让情况变得更糟。
我的方法是找一位了解构建过程的创意工程师，让他坐下来说“修复这个”。给他一两个星期。
最终目标将是一个使用单个 make 命令从头到尾运行的进程。
我还推荐一个自动化的“设置”过程，您只需执行检查并从网络共享运行批处理文件来安装和构建您的所有工具。如果你引进新的程序员，这将节省的时间总量是惊人的。大多数项目需要一到三天的时间才能在新计算机上进行设置——而且总是“新”程序员不知道在自己的系统上进行安装时发生了什么……
简而言之：增量
选择一个适用于各种项目的框架。
一个一个，将组件添加到框架中。
如果您不熟悉框架，请先处理几个更简单的组件，以减少搞砸的风险。
如果您确实了解该框架，请先处理一些更困难和/或常用构建的组件，这样您的团队（和管理层）就会尽早体会到这些好处，并更多地支持这项工作。
一定要制定一个包含所有组件的计划，因为这样才能实现全部收益。
带上你的团队；确保您对这将是有价值的达成共识，否则人们不会在组件更改时维护它。