基于Docker的Jenkins持续交付实践(3)

A5：一个系统由若干的方法组成,单元测试就是测试你写的方法是否符合你的业务要求.所以先写合理的单元测试,只要你的方法通过了这个单元测试就表示你写的这个方法是正确的,单元测试代码是需要开发人员编写的,每种语言有不同的单元测试框架例如Nodejs的mocha,Golang 的go test.自动化测试由测试人员编写.单元测试应该需要脱离外部因素,不依赖数据库、不依赖外部API.

Q6：怎么触发工作流的?

A6：Jenkins pipeline 提供了三种方式(如果安装了SCM的插件可能有其他的方式触发),进入到pipeline的设置页面中的分别有.wbhook(触发远程构建 (例如,使用脚本))、定时触发(Build periodically)、代码更新触发(Poll SCM).

Q8：Jenkins的编译环境是怎么处理的,实际用户的编译需求和环境都不一样?

A8：用户需要清楚你使用的编译环境的基本情况,例如golang的编译环境,容器中的GOPATH是在什么位置.你需要将你的代码ln到什么目录才能进行编译,等这些细节都是需要用户提前知晓.

Q9：Jenkins里的有用户权限管理吗,贵公司的CI/CD是怎么实现用户隔离的,每个用户只能看到自己的项目.

A9：Jenkins当中并没有用户权限.公司在研发的产品中,有一个虚拟的概念叫用户组,对应的是k8s中的一个或多个namespaces.管理员将成员用户添加到这个用户组中,组内成员创建的资源(pipeline、集群、服务,等)在组内是可见,用户组来进行逻辑概念上的隔离

Q10：贵公司Jenkins和Kubernetes是怎么结合使用的?是什么的部署形式?如何回滚?

A10：我看到很多朋友都提问了,Jenkins如何跨主机部署或者如何部署到Kubernetes集群,如何回滚.Jenkins对这方面的能力比较弱,仅仅能够支持kube-api-server的调用而已,如果完全依靠Jenkins是很难完成需求,所以我们的产品当中有一个专门对接kubernetes的deploy的模块,一个应用商店的模块,一个封装了Jenkins的uflow模块,uflow模块向应用商店获取模板并根据当前编译构建出来的镜像tag号替换模板,并交付给deploy模块创建.回滚和升级都由deploy模块负责.这样各自分开,各司其职.

Q11：多个PHP项目,在Docker 应用中,需要逐个拆分吗?一个项目对应一个镜像管理?还是使用文件夹映射的方式构建镜像?

A11：多个项目服务是放在一个容器中还是分开容器中,这个并没有强制的限定.但是建议还是分为多个容器进行部署.Docker的理念就是一个容器完成一个单独的事情.

Q12：Jenkins PIpeline input指令可以复杂的参数化么?

A12：input是一个比较强大的指令,可以在pipeline的运行过程中确认操作,字符输入,文件上传等功能.详细的可以看下jenkins的pipeline-syntax有使用说明和脚本的生成.

Q13：Jenkins自动触发job到build docker image,自动触发是怎么实现的,wedhook 定时触发有没遇到过问题?不能正常触发的?

A13：自动触发的原理的原理是,我们在pipeline中配置一个定时器,这个定时器是用cron表达式表示.例如你设置了 “* * * * * ”就表示每分钟检查一次,那么检查什么呢,检查每次提交的ID,例如git的commit ID .只要检测到了这个ID和上一次的不一致就会触发pipeline的构建.从目前使用并没有出现过不能触发的情况.如果出现了请检查是否是配置的错误.

Q14：CD过程中,重造的轮子和开源组件是一个什么样的比例?个人推崇哪个?

A14：自己重复造轮子和开源组件应该如何选择,这个是很有意思的一个问题.因为开发者都说不要重复造轮子,这是因为很多轮子经过了很多项目考验和众多开发者提交代码和fix的bug.这些项目肯定是比自己从头开始造一个轮子更加有效率而且使用风险低,毕竟所有人都想完成工作上的任务早点下班.但从个人发展来说,有些轮子还是值得自己去制造一次的,这样子你才会了解到这个组件的工作原理、底层的东西.所以我个人的推崇的是,假如你找到了合适接近完美的轮子那就直接用,如果找到了一个可用但总觉得用起来不太爽的组件,那你就把轮子造起来吧.

文章来自微信公众号：DBAplus社群

（编辑：ASP站长网）