设置持续集成的秘密
一些简单的技巧，应该有助于您在考虑设置 CI 时。
引言
我在我过去的两份工作中都设置了持续集成（CI），并且花了一些时间来简化这个过程，我想分享一些关于成功设置 CI 的“秘诀”。
什么让设置 CI 更容易
1. 生成您的构建文件
我编写了自己的代码生成器，它可以搜索我整个开发目录中的项目文件（我使用 .NET，所以它只查找*.csproj文件），并为每个项目文件生成一个 NAnt 构建文件。我还生成了master.build文件。如果还没有类似功能的 CodeSmith 模板，那么创建自己的生成器（代码生成器 = 花哨的字符串构建器）并不难。如果您有兴趣，我很乐意分享这个生成器（将发布在 CodePlex 上）。
生成构建文件也很重要，因为这样您就知道所有项目都以一致的方式构建。而且，当您使构建文件更智能时，您可以轻松地通过一次按钮（也许是几次按钮）将这些更改应用于所有构建文件。
花了一段时间，但我终于在 CodePlex 上公开了我的源代码。
2. 自动化和控制您的数据库更新过程
这是一个独立的主题，但我会尽量保持简短（当然，如果您的应用程序不访问数据库，可以忽略这一点）。您将面临的最大挑战是如何有效地处理数据库更新。您的构建服务器、测试服务器和生产服务器都有自己的数据库，理想情况下，每个开发人员都会运行自己的本地副本（除非大小不允许）。问题是，当开发人员提交包含数据库更改（例如，新表和一些数据）的工作单元时，当构建启动时，您如何确保这些数据库更改在构建服务器的数据库上运行？
您必须有一个自动运行任何新脚本的程序，并且这个程序必须是您构建过程的第一批运行项之一。那么，如果其中一个脚本失败了怎么办？理想情况下，您的程序将在一个事务中运行所有脚本，并且如果任何脚本失败，只需回滚事务。这在 SQL Server 上会奏效，但在 Oracle 上，任何 DML 脚本都会导致事务提交，因此您必须找到另一种方法（例如，先备份，失败时恢复）。
开发人员使用相同的程序来更新他们的本地数据库，并且在迁移到其他环境时也使用该程序。当您将其应用于生产环境时，您可能会有成百上千个脚本（根据我的经验），因此请确保您有一个良好的命名约定（或其他技术），以确保脚本按正确的顺序运行。
对数据库的所有更改都必须通过脚本完成，没有例外。（这不是一条新规则，但令人惊讶的是有多少人没有遵守它！）
我编写了自己的程序来处理这个问题，并且我很想听听其他人是怎么做的。我早就想把源代码（C#）放到 CodePlex 上了，如果您有兴趣，请告诉我，我会在上传时通知您。
请参阅 CodePlex 上的《自动化数据库更新程序》链接！
3. 在开始之前获得“支持”
从开发人员到首席信息官（CIO）。首席信息官需要了解这个新流程将带来的好处，因为它需要时间和金钱来设置（这些金钱和时间最终会得到回报）。
CI 强制实施更严谨的软件开发方法，一些开发人员会不喜欢，所以让他们理解新流程将带来的好处很重要（例如，知道获取最新版本总会得到一个可用的源代码副本！）。如果开发人员不正确地理解新流程并且不断破坏构建，他们会感到恼火。
4. 获取一台像样的构建服务器
我们仍然在使用一台老旧的台式机。构建速度较慢，而且我们不得不经常清理它，因为它很快就会被填满。令人沮丧！
5. 从第一天起制定规则
- #1 - 如果您破坏了构建，那么修复它将成为您的首要任务。
- #2 - 如果构建被破坏，在修复之前不允许进行任何进一步的签入（当然，修复者除外）。
- #3 - 不允许“临走前提交”……意味着在您下班前不要只提交代码（这条规则是唯一可以灵活调整的）。
6. 清洁构建
如果您删除构建服务器上开发目录中的所有内容（即所有源代码所在的位置），然后开始构建，那么……它应该可以工作！如果不行，那么某个依赖项没有包含在源代码控制中。
摘要
我与之交谈过的所有使用过 CI 的开发人员都告诉我，他们无法在不使用 CI 的环境中工作，因此设置它可能存在一些挑战，但它绝对值得！
如果您还没有做 CI……您还在等什么！
兴趣点
我还应该提到，这是我正在撰写的几篇关于构建流程和“简化枯燥的工作”的文章之一，这样您就可以专注于您真正喜欢的事情……编写酷代码！其他文章