创业工具包

Table of Contents

1 持续集成(continuous integration)

1.1 概念

持续集成指的是,频繁地(一天多次)将代码集成到主干。

它的好处主要有两个。

  1. 快速发现错误。每完成一点更新,就集成到主干,可以快速发现错误,定位错误也比较容易。
  2. 防止分支大幅偏离主干。如果不是经常集成,主干又在不断更新,会导致以后集成的难度变大,甚至难以集成。

持续集成的目的,就是让产品可以快速迭代,同时还能保持高质量。它的核心措施是,代码集成到主干之前,必须通过自动化测试。只要有一个测试用例失败,就不能集成。

1.2 流程

根据持续集成的设计,代码从提交到生产,整个过程有以下几步。

1.2.1 提交

流程的第一步,是开发者向代码仓库提交代码。所有后面的步骤都始于本地代码的一次提交(commit)。

1.2.2 测试(第一轮)

代码仓库对 commit 操作配置了钩子(hook),只要提交代码或者合并进主干,就会跑自动化测试。测试有好几种。

单元测试

针对函数或模块的测试。

  • 持续测试(continuous testing)

    敏捷活动的核心特点是 “经常发布”。很多小的发布其目的是给开发者尽早的,经常性地提供反馈。为使得项目完全符合需求尤其是用户和客户需求,它允许用户做变更。事实证明,经常发布是一种能够用来改善产品的手段,敏捷从业人员意识到它对开发团队成员来说也一样。也就是说,如果开发者很快完成了编码并且立刻开始非编码活动,他们能够就刚才所做的事情得到最及时的反馈。

    单元测试就是一个用来提供反馈的绝好工具。比如说:你编码,测试,找出破绽,并且决定如何对付测试的反馈信息。你可能突然发现如果你天真地继续顺着某条思路走,你将因为错失了关键问题而越走越远。你小心地备份(通过测试反馈,你能知道需要备份多少东西),并且发现了一条不同的能够解决刚才标注的系列问题的方法,这一切都充分地利用了测试。另外的相似例子都表明在你编码后,越早进行测试,那么你就能越早的解决问题并且做必要的调整。

    越早的对测试过的代码进行回归测试,就越容易解决问题,我们要尽早地把问题分散。就像我之前的文章讨论过的,持续集成软件能够监控源代码库,并且每次代码做 check in 的时候都会建立一个新项目。这使得开发者在最短的时间里知道哪些需要重建。一个项目可能整天都在做却没有每天 build,甚至好几天都没有。因此当 build broke 的时候,大家想起来做的只是有限的拖延交付时间。但是如果能够找到几小时前代码 check in 记录的话,开发者将能快速的找到错误代码并修复。

    一个叫做持续测试的新趋势出现了,当开发者编码的时候在 IDE 中运行单元测试。不同的产品,它有着各自的方法用来做测试。有些产品,能够依据开发者自己的需求及偏好,用红 / 绿条不同的颜色在 IDE 里进行区分。这种思想再一次用来测试新的代码,进行单元测试或者特性测试,用来跟踪范围的变更。通过经常性地运行测试,大大缩短了反馈环节,开发者能够更好的顺着思路去做决策。依据 David Saff 对 MIT 的研究发现,坚持用持续测试的开发者总是能按时交付,即使出现了变更。因此,我认为这一切都是因为他们从来没有对意想不到的变更采取视而不见的态度。

    连续测试还有其它的优势:如果采用传统的非 TDD(Test Driven Development) 模式,开始是写代码,然后测试,有代码更改的话则再次测试。那么在大型项目里,运行测试需要一段时间,这意味着运行测试的时候,开发者将分心去做其它的事情,比如说处理 Email,回复即时短消息等。如果测试信息能及时反馈,就不会这样。而且,持续测试屏弃了传统的在测试前写海量代码的行为。

    如今,有在 Java 两种重要的持续测试产品,分别是 Ben Rady 的 Infinitest 和 Kent Beck 的 JUnitMax。两者都可以用来做为 Eclipse 的插件,并且 Infinitest 可以用做其它的 IDE,对于 Ruby 语言写的程序,ZenTest 是唯一目前我知道的工具。

集成测试:针对整体产品的某个功能的测试,又称功能测试。
端对端测试:从用户界面直达数据库的全链路测试。

第一轮至少要跑单元测试。

1.2.3 构建

通过第一轮测试,代码就可以合并进主干,就算可以交付了。交付后,就先进行构建(build),再进入第二轮测试。所谓构建,指的是将源码转换为可以运行的实际代码,比如安装依赖,配置各种资源(样式表、JS 脚本、图片)等等。

常用的构建工具如下。

Jenkins
  • Install
    wget -q -O - http://pkg.jenkins-ci.org/debian-stable/jenkins-ci.org.key | sudo apt-key add -
    
    su root
    echo "deb http://pkg.jenkins-ci.org/debian-stable binary/" > /etc/apt/sources.list.d/jenkins.list
    
    apt-get update
    apt-get install jenkins
    exit
    

    Jenkins Travis Codeship Strider Jenkins 和 Strider 是开源软件,Travis 和 Codeship 对于开源项目可以免费使用。它们都会将构建和测试,在一次运行中执行完成。 4.4 测试(第二轮) 构建完成,就要进行第二轮测试。如果第一轮已经涵盖了所有测试内容,第二轮可以省略,当然,这时构建步骤也要移到第一轮测试前面。 第二轮是全面测试,单元测试和集成测试都会跑,有条件的话,也要做端对端测试。所有测试以自动化为主,少数无法自动化的测试用例,就要人工跑。 需要强调的是,新版本的每一个更新点都必须测试到。如果测试的覆盖率不高,进入后面的部署阶段后,很可能会出现严重的问题。 4.5 部署 通过了第二轮测试,当前代码就是一个可以直接部署的版本(artifact)。将这个版本的所有文件打包(tar filename.tar * )存档,发到生产服务器。 生产服务器将打包文件,解包成本地的一个目录,再将运行路径的符号链接(symlink)指向这个目录,然后重新启动应用。这方面的部署工具有 Ansible,Chef,Puppet 等。 4.6 回滚 一旦当前版本发生问题,就要回滚到上一个版本的构建结果。最简单的做法就是修改一下符号链接,指向上一个版本的目录。

Travis
Codeship
Strider

1.2.4 测试(第二轮)

构建完成,就要进行第二轮测试。如果第一轮已经涵盖了所有测试内容,第二轮可以省略,当然,这时构建步骤也要移到第一轮测试前面。

第二轮是全面测试,单元测试和集成测试都会跑,有条件的话,也要做端对端测试。所有测试以自动化为主,少数无法自动化的测试用例,就要人工跑。

需要强调的是,新版本的每一个更新点都必须测试到。如果测试的覆盖率不高,进入后面的部署阶段后,很可能会出现严重的问题。

1.2.5 部署

通过了第二轮测试,当前代码就是一个可以直接部署的版本(artifact)。将这个版本的所有文件打包(tar filename.tar * )存档,发到生产服务器。

生产服务器将打包文件,解包成本地的一个目录,再将运行路径的符号链接(symlink)指向这个目录,然后重新启动应用。这方面的部署工具有 Ansible,Chef,Puppet 等。

1.2.6 回滚

一旦当前版本发生问题,就要回滚到上一个版本的构建结果。最简单的做法就是修改一下符号链接,指向上一个版本的目录。

2 持续交付(continuous delivery)

持续交付指的是,频繁地将软件的新版本,交付给质量团队或者用户,以供评审。如果评审通过,代码就进入生产阶段。

持续交付可以看作持续集成的下一步。它强调的是,不管怎么更新,软件是随时随地可以交付的。

3 持续部署(continuous deployment)

持续部署是持续交付的下一步,指的是代码通过评审以后,自动部署到生产环境。

持续部署的目标是,代码在任何时刻都是可部署的,可以进入生产阶段。

4 代码审查

4.1 Gerrit

Gerrit,一种开放源代码的代码审查软件,使用网页界面。利用网页浏览器,同一个团队的软件程序员,可以相互审阅彼此修改后的代码,决定是否能够提交,退回或是继续修改。它使用版本控制系统,Git 作为底层。

5 项目管理

5.1 JIRA

JIRA 是一个缺陷跟踪管理系统,为针对缺陷管理、任务追踪和项目管理的商业性应用软件。

6 知识管理

6.1 Conflence

Confluence 是一个专业的企业知识管理与协同软件,也可以用于构建企业 wiki。通过它可以实现团队成员之间的协作和知识共享。

7 日志处理

7.1 ELK

7.1.1 continuous code quality analysis

Author: lsl

Created: 2017-08-30 三 16:06

Emacs 25.2.2 (Org mode 8.2.10)

Validate