提升软件质量是我们一直追求的理想，但软件开发唯一不变的真理就是变，为了应付变化多端的软件开发过程，敏捷开发提倡了一种拥抱变化的软件开发理念，少说也替软件开发人员带来了不少小确幸。
这些软件开发模型与方法论，最终的目的在于软件开发管理与质量的提升，与其说质量提升倒不如说是维持一定的水平。虽然敏捷开发有很多不同的方法论 (例如 Scrum, XP 等等)，但我们注意到这些方法论都一定会提到「持续整合 (Continuous Integration)」这个概念。持续整合到底是何方神圣？让它在软件工程中被如此受重视。换个方式来说，我常把敏捷开发比喻为武功心法，心法是虚的，代表方法论核心的理念，其招式才是起作用的媒介，然而持续整合便是敏捷开发实现的武功招式之一。
先不管敏什么捷开什么发了，先说说为什么要推荐各位「持续整合」这个招式。在软件开发一定相当重视项目管理，因为软件在建构的过程中含有太多不确定的因素，项目永远 Delay。经常发生在产品开发后期，系统渐渐开始浮现各种 Bug 与不稳定的征兆，越后期的版本提交期限 Delay 机会越高。持续整合就是为了避免这样的情形发生，我认为持续整合最大的好处在于能够「掌握软件开发节奏」！
蛤？什么是软件开发节奏？这其实表示着我们对软件开发项目的掌握性，能够确保软件在承诺的时间下，交付出合乎规格与质量要求的产品。在持续整合的过程中，我们会随时将软件当下的健康状态透明化，这些状态一旦透明化，问题就容易被显现，问题进而容易被掌握与排除。而不是交付到客户手上，才发现某个功能有问题。通常的软件开发项目都有以下几个愿望：
· 程序设计师想踏实地写程序
· 项目经理想确实地掌握时程
· 组织想降低成本与开发风险
· 客户想拿到质量优良的产品
我们也希望藉由掌握软件开发节奏让这些愿望实现！
若是我们长期参与低劣的软件开发过程，久而久之就容易失去信念，失去对软件质量的坚持，这对于组织与团队的伤害相当大，但也因为不易根除，往往日久为患。工程师为了项目时程而加班，PM 为了时程牺牲品质。程序设计师渐渐为了赶紧搞定眼前的难题，开始不踏实地建构软件，开始用一些奇怪的方法 (Dirty Hard Code) 解决系统自动产生的 Bug...。我想您应该明白这些奇怪的方法指的是什么？时间一久，我们对软件的感情就淡了，反正有了摩菲定理的加持，项目一定延迟，Bug 永远改不完。我们面对软件开发的复杂性，不知不觉已经由病转疾，病可以医的好，疾就只能控制病情了。
假设我们能随时掌握软件的状态，让开发中软件一切的状态变得透明，那不是很好吗？回到「持续整合」这个议题，简单从字面上解释「持续」就是「不间断、不停地、一直、有事没事就做一下」大概这样的意思；那「整合」呢？在软件开发中的整合不就是「把大家写的 Code 在一起跑看看有没有错！」。以此类推「持续整合」四个字的意思就是「有事没事就把大家写的 Code 在一起跑看看有没有错！」，听起来很简单吧!?
我们先来讲讲持续整合的用意好了，我们常接触的敏捷开发 (Agile)，为了快速适应变化，常常在很短的周期 (Scrum 大约两周) 就会发布一个新版本，这件事在 XP (极限编程) 中称为 Small Release。然而每一个版本发布重视的不是新增的多少功能？而是产生一个逐渐接近市场的产品。注意喔，每次发布的软件都必须是可以被正确执行的！在很多敏捷开发方法论都提到，可正确执行的程序码胜过一切，当然也胜过那些该死的文件。
问题来了，要如何在短时间验证软件是可以正常运作的呢？如果一开始功能少还可以花点时间手动测，到后期功能多就没办法了，更不用说除了测试新版本的功能，还要确保既有的功能能够运作正常。这时候「持续整合」就是发挥效用的时候了。回到刚刚提到的：「有事没事就把大家写的 Code 在一起跑看看有没有错！」这样的事情对我们而言，其实就是自动地从版本控制系统拉 Code 进行建置与测试，一旦我们不停的在开发的过程中持续地进行这件事，当软件发生不稳定时就可以立即察觉，将能够大幅降低整合测试的风险与时间，因为我们随时随地都在进行整合测试！
上述提及的测试并非手动测试或半自动测试，而是全自动测试。在必须反覆且密集测试的过程中，我相信你不会想要手动测试的 (花钱找工读生测也不是办法)，而且只要是人做的都有机会错！自动化测试会是比较好的方法。
在实际上，对于「撰写测试」这件事，大概是整个持续整合过程中最难推动的，常因为我们的教育一开始就没有让新手程序设计师明白测试程序的重要性，日常的工作也都是在追求功能的实现，而不是功能正确无误地实现，往往只重视在程序本身的执行结果 (用眼睛看)。在敏捷开发中，也曾提到测试驱动开发 (TDD, Test-driven development) 这样的概念，但如果您开发的系统没有经验老道的软件架构师，那么这个模式在实务推行上将更为困难，因为常发现根本没办法在既有的软件架构设计自动测试，要改就得大改，实行测试的信心与意念就被消灭了。
在实作测试的过程中，其实有些重新审核系统的味道，象是我们都可以发现更多软件设计上的缺失，发现更多可以改进的设计，象是利用解耦合、物件抽象化、资料连结层 (Data Access Layer)、Mock Object、Dummy Data 等等技巧对架构进行软件重构。实行测试还有另一种很棒的方法，就是实行「结对编程 (Pair Programming)」，但这跟测试有什么关系呢？我们先想想，在结对编程中常常一位写程序另一位写测试，这样的过程迫使我们能够设计出可被其他程序测试的程序码，间接达到自动化测试。许多组织高层的观念必须调整，有的老板很难理解为什么要两个人做同一件事，但公司却要付两个人的薪水！
实行自动化测试困难重重，但这些都不是我们逃避的原因，其实一开始不用急着提高测试覆盖率，先从基本的功能测试开始。大致上有两个方向可以慢慢实现：
1. 先进行基本功能的正确性测试，至少保证功能可以被执行（虽然不一定对）。
2. 当系统出现 Bug 时，解 Bug 前撰写复制错误的测试程序，接着才修正 Bug 确保未来同样的 Bug 不会一再发生。
这两点对于已经开发中的系统特别有效，可以慢慢搭建起自动化测试的工作，有了开始就容易多了。我曾经看过实际的例子，在一个开发已久的软件后期才加入自动化测试，虽然覆盖率不到 30%，但是管理者做了一个很有约束力的决策，就是整合版本控制系统，未来 Commit 的程序码不能降低整个系统的覆盖率。所以每次 Commit 后就会进行自动测试，约束未来加入的程序码必须强制撰写自动化测试，保证产品的质量不会越来越糟。
测试的模式与种类繁多，试着找出适合自己产品的自动化测试手段即可，并没有一定的标准答案。最后，尽管我们可以达到的测试覆盖率有限，或者当下复杂的软件架构导致难以撰写测试，但这些都不是借口，必须先开始才会有进步的空间。
前面提到，由于持续整合系统无时无刻都在进行系统整合与测试，当持续整合发现软件不稳定时（指的是建置或测试失败），就会发出警示给予开发者。这个行为我们称为「Feedback 系统反馈」，系统反馈是持续整合系统中相当重要的一件事。当我们收到系统给予我们这样的反馈时，应当立即着手处理，而不是拖到接近产品释出期限，才开始面对持续整合早就给予我们的警示，造成产品时程与质量的忧虑。
最容易实现系统反馈的方法可以透过「每日建置」来完成，每日建置通常在晚上执行 (或称为 Nightly Build)，由于通常身心正常的程序设计师会在下班前提交比较稳定的程序码，在夜深人静的时候进行整合测试是一个好方法。由于系统每天晚上会更新最新的程序码进行建置，当遇到问题时就会发出「系统反馈」警示，通常是发出 Email 告知几位相关衰人，好让事主在隔天一早上班就可以着手处理问题，尽可能让我们所建构的软件在软件开发过程中，能够随时保持稳定的状态。若是在合理的测试覆盖率下，甚至可以随时发布开发中的系统，「快速适应变化」这不就才是敏捷开发的精神吗？
由于每个软件项目都不尽相同，软件建构流程并没有绝对的标准答案，只有做适合团队的对应作法。实务上建置持续整合系统，确实要花上不少功夫撰写 Script 建置脚本，特别在测试环境的自动化建置与执行测试等等工作。虽然方法不同，但是所有的概念还是环绕在「自动化＋测试＋系统反馈」这三个精神上。我认为我们都需要一种义无返顾的勇气，好让我们持续在持续整合工作上投入心力，让软件变得更好！我相信我们都能打造出让自己也能骄傲的软件！
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
