《持续交付》- 持续集成

作者: 司鑫 | 来源:发表于2017-06-06 15:05 被阅读6次

    一 持续集成是什么


    持续集成是一种软件开发实践,即团队开发成员经常集成他们的工作,通过每个成员每天至少集成一次,也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建(包括编译,发布,自动化测试)来验证,从而尽早地发现集成错误。

    对于很多软件项目来说,开发人员虽然可以做到在提交代码后对代码进行自动化的单元测试, 但基本上没人会在试运行环境中去启动并使用它。这样便可能会发生一些潜在的问题。比如当开发结束后需要留出很长时间去集成,这个阶段往往会很费时间,最糟糕的是没人知道这将会花费多长时间才能完成集成。

    所以我们应该尽早去做持续集成,而持续集成的目的就是让软件一直处于可工作的状态。

    二 实现持续集成


    1、准备工作

    • 版本控制:任何项目都应该使用版本控制
    • 自动化构建
    • 团队意识

    2、一个基本的持续集成系统

    • 查看一下是否有构建正在运行,如果有的话,等它完事,如果它失败了,就和团队的其他人把他一起修复,然后再提交代码
    • 一旦构建完成且测试完全通过,就从版本控制库中将该版本的代码更新到自己的开发环境上
    • 在自己的开发机上执行构建脚本,运行测试,以确保在你机器上的所有代码都正常工作
    • 如果本地构建成功,提交代码
    • 然后等待你这次提交的构建结果
    • 如果失败了,停下手中的活,修复问题,转到步骤3
    • 如果成功,开始下个任务

    三 持续集成的前提条件


    1、频繁提交
    2、创建全面的自动化测试套件

    自动化测试的套件包括:

    • 单元测试:用来测试应用程序中某些小单元的行为(方法、函数...),通常不需要启动整个应用程序,也不需要连接数据库、文件系统或网络。
    • 组件测试:用于测试应用程序中几个组件的行为。它也不需要启动整个应用程序,但有可能需要连接数据库、访问文件系统或其它外部系统或接口。
    • 验收测试:用来验证应用程序是否满足厌恶需要所定应的验收条件,包括应用程序提供的功能,以及其它特定需求。一般会将整个应用程序运行于类生产环境的运作方式。

    3、保持较短的构建和测试过程
    4、管理开发工作区

    当开发人员开始工作的时候,应该总是从一个已知正确的状态开始。

    四 应该遵守的实践


    • 构建失败之后不要提交新代码
    • 提交前在本地运行所有的提交测试,或者让持续集成服务器完成此事
    • 等提交测试通过之后再继续工作
    • 回家之前,构建必须处于成功状态
    • 时刻准备着回滚到前一个版本
    • 按照持续集成的流程,前一个版本肯定是没有问题的
    • 在回滚之前规定一个修复时间
    • 不要将失败的测试注释掉
    • 为自己的导致的问题负责
    • 测试驱动开发

    相关文章

      网友评论

        本文标题:《持续交付》- 持续集成

        本文链接:https://www.haomeiwen.com/subject/pivgfxtx.html