如何从“奥术整合”迁移到持续整合？
现在我正在进行的一个项目已经达到了复杂程度，需要超过几个步骤（实际上它变得神秘！）来生产完整/可用的产品。不幸的是，我们并没有从Continuos Integration的思维开始，所以你可以想象它有时会带来痛苦，而在其他情况下，我可以轻松地浪费半天的时间，试图获得一个干净/经过测试的版本。如何从“奥术整合”迁移到持续整合？
反正任何HUGE项目都包含许多不同语言的组件（不仅仅是企业风格的Java或C＃），还有许多图形和文本资源。现在的问题是，当我寻找连续性集成时，我总是会找到最佳做法和技术，假设从头开始一个新项目。然而，这不是一个新项目，所以我想知道什么是一些好的资源来主动开始从奥术集成向Continuos集成迁移:)
在此先感谢！
这里有两个简单的步骤。
- 去的重复建设：
- 使用源代码控制，获取所有代码签入
- 建立和文件全部用于构建工具（主要是，该编译器版本）。为这些工具进行可重复部署并建立流程。
- 清楚地建立并记录任何需要构建但未签入的资源（第三方安装，服务包等）。有一个可重复的部署和设置这些依赖关系的过程。
- 之前commiting到源代码管理，开发人员必须
- 更新他们的工作副本
- 成功打造
- 运行，并通过自动化测试
这些步骤可以做到1一次，有点路要走。你会在每个阶段获得好处。例如，如果您根本不使用源代码管理，只需将代码放入源代码管理（没有其他任何内容），这是向前迈出的一大步。另外，如果没有自动化测试，那么开发人员不能运行它们 - 但他们仍然可以获得先前的提交并让编译器检查他们的工作。
如果你能做到所有这些，你会得到一个很好的理智的地方。
这些目标是可重复的构建过程和开发人员，这些过程和开发人员可以接受他们的更改如何影响构建和其他开发人员。
然后，你可以通过建立较高的依从性牟取奖金：
- 开发者建立一个经常犯的习惯。工作副本中的代码永远不会超过1天。
- 自动构建过程监视签入的源控制，并将结果提供给用户可以接受它们的位置（例如测试环境，预览网站，甚至只需将.exe放在用户可以找到它的地方）。
我猜想迁移不是一个真正的选择 - 半驴解决方案只会使情况变得更糟。
我的方法是让一位了解构建过程的创意工程师坐下来说“解决这个问题”。给他一两个星期。
最终目标将会是一个始终以单个make命令开始运行的进程。
我还推荐一个自动的“安装”过程，您只需执行一次结帐并从网络共享中运行批处理文件即可安装和构建所有工具。如果你引入新的程序员，这将节省整体的时间是惊人的。大多数项目需要一到三天的时间才能在新电脑上安装 - 而且它总是“新”程序员，他不知道在自己的系统上进行安装是怎么回事......
以同样的方式你吃大象（一次咬一口）;-)持续集成需要自动构建。从那开始。自动化每件作品的建筑物。 Ant或NAnt是一个很好的方法来做到这一点。每个组件的构建都是NAnt任务。然后你的整个系统构建可以聚合这些单独的任务。
从那里，您可以添加部署，单元测试等任务。如果您想使用CI技术，可以将它连接到您的NAnt构建。
简而言之：增量
选择一个框架，跨越各种不同的项目。
一个接一个地向框架添加组件。
如果您对该框架不熟悉，请首先处理一些更简单的组件，以降低风险。
如果您确实了解该框架，请首先处理一些较为困难和/或通常构建的组件，以便您的团队（和管理层）能够尽早了解这些优势，并为此付出更多努力。
一定要有一个计划，包括所有你的组件，因为那是什么时候才能实现全部好处。
带上你的团队;确保你有共识，这将是有价值的，或者人们不会保持它随着组件的变化。
我会先写下所有需要手动完成构建和测试的步骤。在此之后，你至少有一个以旧的方式去做的指南，写下来让你有机会把它看作一个完整的过程。
然后查找脚本部分。
理想情况下，您希望从代码提交中触发构建和测试，并且仅重建和重新测试更改的部分，可能每晚或每周都进行完整构建和测试。您需要记录文件或数据库条目，并报告构建成功或缺失。
您需要搜索并评估预构建产品和开源构建您自己的工具包。你当然可以编写所有的脚本和报告，但是这需要一段时间，而且你可能会得到一个几乎没有足够好的报告系统，因为你的工作是编码产品，而不是对编译系统进行编码。 :-)
也许是脱离主题，但... 我曾参与过几个项目，这些项目都有关于设置dev的特别指南。框。 每位新开发人员获得的第一项任务是使指南保持最新状态，通过贯穿指导，发现任何问题并纠正下一位新开发人员的指示。 – Oddthinking 2008-11-19 02:15:52