持续集成 - 回顾过去

尽管这并非发生在十年前，但对我而言，这仍是一个很好的案例，让我学习和认识到持续集成如何为我们的工作带来增值。

我记得当时的情况就像是他们青少年时期一样：几个团队在同一个应用程序的不同模块上工作，然后一起部署。

• 没有正式的构建流程
• 除了需要重大里程碑部署之外，没有构建
• 没有反馈、报告、审查等

因此，实际上没有构建生态系统。这意味着大量的沟通、成堆的故障排除、最后一刻的阻碍，以及极其不满的最终用户/利益相关者。

那么，到底出了什么问题？

• 没有配置控制，即无法确定哪些更改将包含在发布中，也没有控制来包含或排除它们。
• 没有状态记录，即没有整体产品的反馈或状态。
• 没有环境管理，意味着没有人知道他们正在使用什么硬件/软件，有时甚至不知道为什么。
• 没有任何团队合作，意味着没有指导流程、审查或问题和陷阱的可追溯性。

因此，发布日实际上是世界末日！

开发人员花了一些时间才意识到以下内容的重要性：

• 配置识别 - 我们正在使用什么代码？
• 配置控制 - 控制产品及其更改的发布。
• 状态记录 - 记录和报告组件的状态。
• 审查 - 确保组件之间的完整性和一致性。
• 构建管理 - 管理用于构建的流程和工具。
• 流程管理 - 确保遵守组织的开发流程。
• 环境管理 - 管理托管我们系统的软件和硬件。
• 团队合作 - 促进与流程相关的团队互动。
• 缺陷跟踪 - 确保每个缺陷都可以追溯到源头

毕竟，这需要一些时间，但日常流程如下图所示。

[下载图片] (/images/2008/11/build.png)

重要的是：

• 开发人员分布在不同地点的不同团队中。
• 有一个SCM团队负责SCM活动，即配置识别、控制、构建管理等。
• 所有开发人员使用一个单一的代码库。
• 定义了产品集成流程，并在有人签入时进行检查。
• 每小时进行一次构建，通过单元测试检查系统的健全性。
• 每晚进行一次完整的构建，包括全面的单元测试、覆盖率报告、自动化测试以及安装程序和升级包。
• 此外，所有以上内容都显示在FTP/HTTP站点上。FTP用于安装程序/二进制文件/归档文件的提取，HTTP用于构建/反馈等的详细视图。

所有以上内容意味着构建生态系统的强度和健康度。并且对系统有更多的信任，因为它会在过程中报告失败。