Workflow

木犀后端的技术经历了一个不断演进的过程，从最初的LNMP式的简单直接的部署方式，到Docker容器部署，到现在的Kubernetes集群部署。相比当年艰难的调试由于操作系统环境不同而导致的各种部署问题，现在的部署流程可以说是相当简单而且可靠的。这也要求我们有一套标准化的开发部署流程。 三个环境 在互联网公司，一个产品一般都部署了好几个版本，比如开发、测试、预发布等等。不同的版本对应开发周期不同时间点的产品状态。QA一般就是在部署好的这些环境中进行发布前测试的。 我们对环境的要求没有那么高，只要有本地、测试、线上三个环境就可以了。下面分别讲讲从本地开发，到部署测试版本，到新版本上线过程中一系列的标准流程。 开发分支与Pull Request 本地开发其实没有太多的限制，一般就直接在本地运行代码进行开发。需要注意的是我们的仓库中一般有主分支和开发分支，这个开发分支可以是按版本号，每次新版本时从主分支checkout出来。或者是一个持续使用的开发分支。所有人都不能直接向主分支提交代码。但可以直接向开发分支提交代码。 如果想讲开发分支中的代码合并到主分支，就要发起一个Pull Request。Pull Request在负责人code review（看情况）以及CI测试通过之后才能merge。 单元测试与CI 对于有明确输入输出的后端API来说，单元测试是必要的软件质量保障。也是协助开发的一个手段。 大家在本地提交代码之前先自己跑过测试，通过之后再提交。Pull Request时还会跑一遍CI，来确保代码功能的正确。比如这样： Github上使用的比较多的是Travis CI。Docker based的项目可以参考这个CI配置。 这里简单介绍一下CI。CI指持续集成，我们说的CI一般是指云端的CI runner。Travis CI本质上其实就是一个云服务。提供了一个虚拟环境来运行你指定的脚本。Travis支持很多语言环境，但最近Travis支持了Docker，所以环境也就不是问题了。要注意我们写测试时要写清进程exit时的状态码，非0的状态码代表非正常退出。Travis就是根据这个来判断测试或者其他错误是否发生的。这决定了这次CI运行是否成功。 测试环境的具体配置 在开发基本完成，代码merge到主分支之后，我们就可以尝试部署一个测试版本了。测试环境和线上的环境差别不大。测试环境部署在我们的测试集群（几台专有网络阿里云学生机）。 大家可以随意选一台机器然后部署。部署的时候，除了数据库之外的一般都用Docker部署。如果有多个容器需要部署，我们一般用Docker-compose来一键build&run。 数据库一般就使用某台机器上直接安装的数据库。在初次部署时大家要记得在容器中执行初始化数据库和用户角色命令（当然也可以写成脚本）。 测试环境有几个用处，首先是给前端提供联调的API。然后是给产品经理和设计师提供一个线上版本来进行初步测试。因此我们需要给测试环境配置一个域名。但如果直接在DnsPod等等线上解析，要解析的域名数量会很大，很不方便。所以我们采用修改本地hosts文件的办法。 比如： 120.77.8.149 test.share.muxixyz.com 注意域名是muxixyz.com的子域名，因为阿里云会检测DNS解析的域名是否备案。如果随便写一个域名是不行的（当然理论上你用baidu.com或者其他知名的域名也行）。 这个hosts文件的配置要写在Github文档中。Tower项目里最好也写一个操作指南文档给设计师和PM看。 上线 MAE发布后本节需要更新 上线一个版本，比如1.2版。首先在主分支打上这个tag。然后在阿里云的镜像仓库里build这个tag的镜像。 最后由负责部署的同学，SSH到集群更新Deployment配置文件中的image版本号。升级Deployment即可。 这一步在将来会由开发应用的同学自行在MAE上操作完成。目前暂时还是需要有人在服务器上部署。开发的同学只要交付镜像就可以了。 总结 相比于之前的工作流，目前的工作流不同的地方主要是，需要写单元测试，PR需要CI通过才能merge，大型的应用必须要部署测试环境并用本地DNS解析访问，进行部署时是用Docker镜像而不是在服务器build。这套工作流需要大家用微服务的观点去看待将来的开发。随着时间的推移，这套工作流也会不断的变化，大致还是朝Cloud Native的方向发展。