2011，持续集成理想照进现实

糖糖糖糖糖糖糖糖糖糖糖糖糖糖糖糖糖糖

于 2012-01-21 02:22:00 发布

阅读量103

点赞数

本文链接：https://blog.csdn.net/cpongo4/article/details/89145385

版权

持续集成的理念在我们国内已经深入人心，很多软件企业已经自发或者在持续集成教练的带领下，为自己的项目和产品搭建起日趋成熟的持续集成平台，改进团队软件开发过程和协作，提高系统质量，为软件上线和发布提供保障，增强信心。

在2011年，持续集成领域所涉及的理论和实践也开始发生变化，尤其作为行业内事实上的实践指导标准——Martin Fowler的持续集成论文发布了第二个版本。ThoughtWorks高级咨询师肖鹏为此撰写了《持续集成理论和实践的新进展》，其中值得关注是对持续集成成熟度模型的阐述，为指导和建设持续集成能力建立了可以参照的标杆。

在2011年InfoQ推出的持续集成专题内容中，最为重要的就是来自百度的也是《持续交付》的作者乔梁撰写的持续集成专栏。他通过角色扮演和故事推进，用多篇幅内容详细描述了持续集成实践的方方面面，内容涉及分支策略、依赖管理、自动化部署等八个方面，而且还未结束。

\
尽管Thoughtworks的首席科学家Martion folwer 为“持续集成 ”下了定义，但由于自身背景与经历的不同，每个人对其都有不同的理解。从狭义上讲，持续集成可以认为是一种基于某种或者某些变化对软件系统进行的经常性的构建活动（注：这里的构建活动不仅指编译打包工作，还包含各类自动化测试、部署及发布活动）。然而，它忽视了一点，即：任何实践中都应该包含“与人的交互”这一因素。因此，从广意上讲，持续集成应该是软件开发团队在上述活动的约束下所采用的整个开发流程及活动。它强调开发团队与持续集成系统之间的互动性。我们既见过持续集成做得非常成功的团队，也见过效果不佳的持续集成，甚至失败的案例。
\
那么，到底如何从持续集成中得到最大的收益呢？这要从持续集成所涉及的诸多方面进行分析，并根据团队具体情况（比如团队规模、人员组成以及是否为分布式团队等）及所开发软件自身的特点（是企业应用软件，还是中间件？是嵌入式软件，还是互联网产品等）制定实践策略与实现步骤。本专栏将与大家共同探讨与持续集成、持续部署及持续交付相关的方法、工具与经验。作者本人在Thoughtworks公司曾参与的一款持续集成与发布管理产品Go的交付和对外咨询服务为专栏提供了很有素材。
\

持续集成中的一个实践是自动化测试，包括自动化单元测试、功能测试、集成测试等等。Ranjan D Sakalley在他的《测试自动化和持续交付》一文中重点阐述了他认为自动化测试在持续集成中的重要性，

\
软件测试和验证是细致活也是辛苦活，需要模仿最终用户尝试各种用法和输入场景、比较并断言所期望的行为。而这些细致的辛苦活是可以让计算机程序去做的。自动化测试套件中那些可编程部分对于大规模软件交付是非常有帮助的。在我做过的大部分项目里，有些测试是可以自动化的，也有些不能。不过，只要有自动化测试套件，我的团队都将倚重于它，而将精力集中在那些没有自动化的功能测试。而且，自动化测试还让我们能够满足客户快速变化的需求，并使我们达到了一个更高的层次，使得每次构建（即使只是微小变动）都是经过测试和验证的稳定版本。正如Jez有关持续交付的文章中所言，自动测试“让交付团队超越了基本的持续集成”并走上持续交付的康庄大道。实际上，我觉得自动化测试是非常重要的，如果你要实践持续交付，就必须在自动化测试上进行投入。
\

国内著名的Maven技术专家许晓斌在他的Maven实战专栏中，描述了完全由Maven驱动持续集成的可行性，用经验证明用得好自己工具箱里称手的工具，胜过一切理论。