持续集成的简单说明

您将如何定义持续集成以及CI服务器包含哪些特定组件？

我想向市场部门的某人解释什么是持续集成。他们了解源代码控制-即他们使用Subversion。但我想向他们正确解释什么是CI。在维基百科的文章从来没有正确定义它，在Martin Fowler的文章仅给出以下，这基本上是同义反复其次是“一体化”的模糊解释：

持续集成是一种软件开发实践，团队成员经常集成他们的工作，通常每个人至少每天集成一次-导致每天多次集成。每个集成都通过自动构建（包括测试）进行验证，以尽快检测到集成错误。

更新：我给他们发了这张图片，我找不到一个更简单的图片。

更新2：从市场营销工作组反馈（针对存在3个问题的时间）：

我实际上很喜欢这三个答案–出于不同的原因。我想登录只是为了感谢所有人！

显然他不能-所以代表他:)

更新3：我已经了解了Wikipedia文章，其中确实包含一些原则，当您仅使用标题时，它们是一个不错的清单：

1. 维护代码库
2. 自动化构建
3. 使构建自检
4. 每个人每天都致力于基线
5. 每次提交（到基线）都应该构建
6. 保持快速构建
7. 在生产环境的克隆中进行测试
8. 轻松获取最新交付物
9. 每个人都可以看到最新版本的结果
10. 自动化部署

当某人更改了组成软件产品的文件，然后尝试将其检入（换句话说，尝试将所做的更改集成到主要产品代码中）时，您要确保仍然可以成功构建软件产品。

通常会有一个称为CI服务器的外部系统，它会定期或在每次更改时从版本控制中获取源文件，并尝试构建产品（编译/测试/打包）。如果CI服务器可以成功进行构建，则说明更改已成功集成。

如果构建失败或成功，CI服务器还必须能够广播，因此，像Jenkins（当今最常用的CI服务器之一）之类的系统将具有发送电子邮件/文本的方式，以及具有类似仪表板的Web界面的功能。有关当前和过去版本，谁签入代码，何时发生故障等的大量信息。（在上面的图片中，这就是“ 反馈机制”。）

CI很重要，因为它可以确保您连续获得有效的产品。这对于所有正在开发软件产品的开发人员以及所有想要访问软件产品的日常发行版（例如质量检查）的人员来说都非常重要。

我想对于您的市场部门来说，CI的工作原理并不重要，但CI对您的软件新发行版意味着什么。

理想情况下，CI意味着您可以每天制作一个潜在的可发行软件新版本，随时可以提供给客户或出售给客户，同时还添加了一些新功能，功能或错误修正。这并不意味着您必须每天交付新版本，但是可以根据需要提供。

例如，如果您计划为您的软件“ 2015”版正式发布新功能集，并且该功能集的某些部分已在今天进行了编码和集成，则营销人员可以采用您的当前版本软件，并或多或少安全地在2013年的下一次会议上展示它。没有CI，他们必须要求您的团队进行计划外的代码冻结，每个团队成员都必须将自己正在研究的半熟功能集成到产品，他们可能没有足够的自动测试准备，并且猜测会议将会发生什么-您的2015er版本的“ alpha版本”崩溃的风险要高得多，尤其是在演示新功能时，尤其如此。

除非您知道我们曾经做什么，否则您将无法知道CI是什么。想象一个由3部分组成的系统。有一个UI收集数据并将其放入数据库中。有一个报告系统可以从数据库中生成报告。还有一种服务器可以监视数据库并在满足某些条件时发送电子邮件警报。

很久以前，其内容如下：

1. 同意数据库的架构和要求-这将需要数周的时间，因为它必须是完美的，因为您很快就会知道为什么
2. 将3个开发者或3个独立的开发团队分配给这3个作品
3. 每个开发人员都会工作数周，并使用自己的数据库副本测试其工作数周或数月。

在这段时间内，开发人员不会运行彼此的代码，也不会尝试使用由其他人的代码创建的数据库版本。报告编写者只需手工添加一堆示例数据。警报编写者将手动添加模拟报告事件的记录。GUI编写者将查看数据库以查看GUI所添加的内容。随着时间的推移，开发人员会意识到规范在某种程度上是错误的，例如未指定索引或字段长度太短，然后在其版本中“修复”该规范。他们可能会告诉其他人，他们可能会对此采取行动，但通常这些事情会在列表中列出以备后用。

当所有三个部分都经过完全编码，并由其开发人员进行了测试，有时甚至由用户进行了测试（向他们显示报告，屏幕或电子邮件警报）时，就会进入“集成”阶段。这通常是几个月的预算，但仍会结束。开发人员1所做的字段长度更改将在此处发现，并且需要开发人员2和3进行大量代码更改，并且可能还会更改UI。额外的索引将对其造成严重破坏。等等。如果用户告诉其中一位开发人员添加了一个字段并做到了，那么现在是其他两个人也必须添加它的时候了。

这个阶段非常痛苦，几乎无法预测。因此人们开始说“我们必须更频繁地集成”。“我们必须从一开始就共同努力。” “当我们中的一个提出变更请求时（那是我们当时的谈话方式），其他人必须知道这一点。” 一些团队开始更早地进行集成测试，同时继续单独工作。一些团队从一开始就一直使用彼此的代码并一直输出。这就是持续集成。

您可能会认为我夸大了第一个故事。我曾经为一家公司做过一些工作，当时我的联系人让我为检查存在以下缺陷的某些代码而烦恼：

• 他未使用的屏幕上的按钮尚未执行任何操作
• 没有用户签署过屏幕设计（精确的颜色和字体；屏幕的存在，功能以及300页规格中的按钮）。

他认为在完成之前不要将任何东西放到源代码控制中。他通常每年进行一到两次签到。我们在哲学上有点不同：-)

另外，如果您很难相信团队会在诸如数据库之类的共享资源周围断开连接，那么您真的不会相信（确实是）采用相同的方法进行编码。您将要编写一个我可以调用的函数？太好了，继续进行，在此期间，我将只硬编码所需的内容。几个月后，我将“集成”我的代码，因此它将调用您的API，并且如果我传递null，它将发现它炸毁，如果返回null（它做了很多），我将炸毁它返回的东西太大了对我来说，它不能应付leap年，还有其他一千件事。独立工作然后进入整合阶段是正常的。现在听起来像疯了。