阿里技术专家：持续交付与微服务背后的实践逻辑

关于代码改动,测试也要跟着改的问题,我想说两点：

那么有了这些测试之后,我应该什么时候运行它们呢.是迭代结束时吗?不!我们应该在每次提交时都完整的运行一遍这些测试.这样一旦出了问题我就可以第一时间知道.这就是持续集成的基本概念.

每次提交代码触发编译、测试、静态检查、打包归档、然后再运行验收测试(AT),然后再部署到类生产环境进行性能测试,再部署到端到端测试环境运行端到端测试.并且把每一步的结果反馈给开发团队.

我们把上图称为持续集成流水线.可以使用很多工具来实现,比如最常见的开源工具Jenkins.或者我目前所负责产品：crp.aliyun.com.

关于更多的持续集成的实践和流水线设计,因为内容很多,这里只讨论几个要点.

1. 代码仓库： 每个开发要及时的提交代码,不要把代码长期留在本地,一天至少提交一次.不要开长时间的分支.越频繁的提交代码,就能得到越及时的反馈.
2. 构建脚本： 构建脚本必须要放在代码库,切忌把它们放在只要少数人能够访问的神秘的地方.
3. 软件包服务器： 每次构建的产出物,必须要按照一定的版本规则存放起来,以供后续的步骤使用,比如做测试和部署.软件包的形式是多种多样的,比如Java的jar、war,Ruby的gem,操作系统的rpm等等.甚至是最通用的tar,也可以成为你的软件包形态.
4. 分stage： 大家可以看到上面这个流水线是分stage的,每个stage是顺序执行的.越往前的 stage检测越快,并越简单.越往后的stage检测越耗时.任何一个stage运行失败,后续的stage都不会再继续进行,本次流水线的进行就失败了.所以流水线运行到越往后的阶段,我们对于本次构建是可以上线的信心就越强.

我们使用自动化测试加持续集成解决了第一个发布前回归测试耗时的问题.

（编辑：厦门网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!