自动化发布

持续集成

本文所有持续的含义，可以理解为自动化，即没有人工干预的环节

集成

持续集成的含义：git工作流，协作开发，每次提交都要跑完所有单元测试，通过后会发布版本，实现快速迭代，没有人等待的环节

持续集成包含了Design、Delvelop、Test、Realese这样几个步骤

其中测试环节指的是开发人员的代码单元测试

持续集成的步骤

其中源代码到构建(build)的环节，有部分开源产品可以完成，比如 Jenkins 和 Strider， Travis 和 Codeship，他们都会降构建和测试，在一次运行中执行完成。

根据测试的环节，可以调整构建的顺序，考虑是否先进行构建

需要强调的是，新版本的每个更新点都必须测试到，测试覆盖率代表了产品的稳定性

交付

之后的会是交付环节，交给质量人员评审，测试部门进行测试，持续支付的该步骤是自动化的

扫描二维码关注公众号，回复： 3100565 查看本文章

部署

得到发布的指令后，下一个步骤就会是进入生产阶段，持续部署的该步骤是自动化的

持续交付和持续部署之间的关系

这个时候就会涉及到一些持续集成的开源产品，了解到阿里云平台的codepipeline
持续集成工具，然后涉及到了知识盲点

后续跟进持续集成的历史，以及步骤

涉及到自动化测试的部分，需要编写erlang单元测试的代码

单元测试也有很多的种类，需要优选一种方案出来

部署不成功的时候，需要回滚到上一个版本，最简单的是修改符号链接，指向上一版本目录即可

白鹭引擎

配合后端erlang开发的步骤

EUnit单元测试

在模块中添加 -include_lib("eunit/include/eunit.hrl"). 就会在模块内自动生成 test/0 函数并export，如果已有test函数，则不会覆盖。

简单的测试函数

函数名以 _test() 结尾，为最简单的测试函数，没有参数，用赋值 = 做模式匹配，异常为测试不通过

用assert宏判断

比如

length_test() ->
    ?assert(length([1,2]) == 3).

如果宏内的函数结果不是true，则会抛出异常，否则会宏会返回ok。

测试的生成函数

当多个test函数存在的时候，由于一个终止，会覆盖不到其他的测试函数，所以需要另想办法，提高测试效率

函数名以 _test_() 结尾的，被认为是一个生成函数，会为函数体列表里面的每个函数生成一个简单测试。

xx_test() -> assert(A==B).
xx_test_() -> ?_assert(A==B).

单条测试的话，上面两个是等价的

?_assert(A==B) 是 xx_test_() 的生成器，底层就是以 fun() -> ?assert(A == B) end 的方式实现的。

当测试模块内有 xx_test_() 类似的测试生成函数时，xx_test() 函数不会被 _tests 模块发现。

测试函数的所有测试体要放在一个列表内返回，才可以看到每个的结果

关闭测试

erlc -DNOTEST my_module.erl

或者

-define(NOTEST, 1). // 1 or true 都可以

忽略tests模块的方法

保证即使是一个编译不通过的测试函数，也不会影响到到代码的编译

-ifdef(TEST).
   -include_lib("eunit/include/eunit.hrl").
   -endif.