持续集成下的软件开发/简介

定义

首先，我们需要定义持续集成。维基百科给出了以下定义：

在软件工程中，持续集成 (CI) 实施了持续的质量控制流程——频繁地应用少量工作。持续集成的目标是通过在完成所有开发工作后应用质量控制的传统做法，来提高软件质量，并减少交付时间。

持续集成一词最早出现在极限编程 (XP) 中。Martin Fowler 和 Kent Beck 大约在 1999 年撰写了关于持续集成的文章。Fowler 的论文 是经常被引用的信息来源之一。Beck 的著作《极限编程解释》， 极端编程的原始参考文献，也引入了这个术语。

维基百科中给出的工作定义很好，因为它有助于消除持续集成仅仅是整个图景中的一项任务的错误观念（即，当人们想到“持续集成”时，他们往往会想到持续集成构建，而不是整个流程）。持续集成是一个涵盖软件开发工作的流程，而不仅仅是集成和构建代码的行为。这一点非常重要，请注意！

受监管项目中的持续集成

如何将持续集成应用于软件医疗设备的严格监管领域？让我从一个故事开始。

在监管环境中，例如 FDA 对软件医疗设备实施的监管，我们往往关注标准操作程序 (SOP)。这些 SOP 往往变得如此僵化，以至于束缚了我们的手脚，阻止了敏捷（小写 a）软件实施，并为官僚主义而引入了官僚主义。最终，那些花费了很长时间创建和（试图）执行的标准操作程序变得如此繁琐，以至于所有其他工作都变成了对万能流程的次要关注。好消息是，有人试图思考流程（如果真有好的消息的话）。坏消息是，没有人（包括作者）记得这些程序的确切内容。这就是所有软件开发中采用智能持续集成方法可以成为银弹的地方。

我第一次参与软件医疗设备项目的经历是在 2002 年。我之前的雇主，一家激动人心的互联网泡沫时代的企业，未能提供我预期的数百万美元。我当时还算是刚毕业不久，现实的冲击让我措手不及：那 10 万股股票将一文不值，我还要再开几年 1998 年的 Dodge Status 了。

面对我人生中第一次在失业队伍中的屈辱经历，我渴望接受第一个工作机会，很快我就发现自己在一个血液银行项目中担任软件质量保证工作。我不确定是什么让我这个傲慢的年轻软件开发人员更加屈辱：失业队伍，还是被迫编写测试脚本。但那是一份工作，而且作为成千上万正在寻找工作的软件开发人员之一，我接受了这份工作。

在我新工作的第一天，我了解到了一些奇怪的事情：我们编写的软件将由 FDA 定义的一套标准进行审核和控制。“FDA，”我问道，“是指食品药品监督管理局吗？”是的，就是那个 FDA。我被告知坐在我的隔间里阅读一个名为 CFR 的文件，重点关注第 11 部分和第 820 部分。内容很长，很无聊，很奇怪，我感到很恼火。我一直在打哈欠，强迫自己阅读。

我接下来的任务是阅读一大堆标准操作程序 (SOP)。读完一个 SOP 后，我会进行测试，回答关于 SOP 的几个简单问题。测试结果会被评分、签字，并存放在某个地方的永久文件中，作为我了解 SOP 的证明。在这一点上，我很快就忘记了 SOP 的内容。

我的工作很简单。我需要审查用例，为这些用例编写测试脚本（手动和自动），并运行这些脚本。完成一项任务后，我就会继续进行下一项任务（这项任务就是我的老板让我做的任何事）。很快，我在入职前几周阅读过的 SOP 就成了遥远的记忆。我没有理由重温它们。

但也许我应该重温一下。还记得我签署了一份测试，表明我阅读并理解了 SOP 吗？在我入职大约 6 个月后，项目开始进行内部审计。这次审计的目的是执行类似于 510k 实际 FDA 审计期间可能进行的活动。我被带到一个房间，接受审计人员的询问。

审计人员问我第一个问题，“所以 Matt，你做你的 were 时，你是怎么知道该做什么的？”

这个问题听起来很奇怪，但我礼貌地回答道，“嗯，我想，我做我的老板让我做的一切。”

错误的答案。

审计人员继续说道，“不，我的意思是，你怎么知道你应该创建什么？”

我开始有点坐立不安，“嗯，因为我的老板告诉我该怎么做……我阅读用例和需求，并编写测试。”

情况不太妙。

奇怪的询问持续了很长一段时间，直到最后审计人员放弃，告诉我我可以回到我的隔间。在短暂的一段时间里，我松了一口气。然后，项目经理知道了我在询问和回答时的口齿不清。

我有麻烦了。

我们是在谈论标准操作程序还是持续集成？

持续集成就是过程

我是在谈论两者！持续集成不仅仅是贡献到共享仓库并确保软件构建完整性。持续集成是一个流程，它会打造一个具有逻辑程序的协调一致的团队。持续集成意味着团队中的任何成员，从管理层到开发人员，都不能在真空中工作。工程高质量软件的流程是一个涉及所有角色的流程，它需要的不仅仅是简单地记忆曾经阅读过的一些程序。这些程序是日常工作活动中不可或缺的一部分。更重要的是，这些程序是有意义的。