devops 自动化流水构建（gitlab+gerrit+jenkins+sonar）
摘要：关于当下较为流行的devops概念，有了docker 容器之后，才能够真正的让开发人员快速和方便的掌握服务运维的方式，并且用搭建自动化流水构建，节省许多运维成本和开发效率。本文介绍主要架构及部署方式，是以自己公司的实战经验为总结，不一定很准确，但是能够提供一个大致的方向。
什么是devops？
按照惯例，先介绍概念。
DevOps（Development和Operations的组合词）是一种重视“软件开发人员（Dev）”和“IT运维技术人员（Ops）”之间沟通合作的文化、运动或惯例。透过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。
来自wiki百科：https://zh.wikipedia.org/wiki/DevOps
最重要的一点就是，通过自动化的发布，使得开发与运维人员可以更加敏捷和频繁的发布应用。
如何做到自动化发布，就是今天的内容。
自动化流水持续集成的架构
这是当前较为主流的方案，也是我们公司近两年一直在使用的
- gitlab ： 私有化的gitlab 代码仓库，拥有私有化的代码仓库是最基础的一步。
- gerrit： gerrit 做代码审查，每个成员往gitlab提交的代码，需要codereview权限和verify 权限的人同意才能往分支上推送，质量差或者有问题的代码可以及时退回，开发人员提交代码的时候更加的谨慎，保护代码质量
- jenkins： 代码合格后，通过jenkins的持续集成，定时或者手动或者触发器的方式，将代码构建成镜像文件，最后通过脚本部署到docker服务器或者kubernetes集群中
- sonar： 与阿里巴巴代码规范检查插件一样，jenkin构建后会将代码推送至sonar服务器，评审代码的质量，也可以自定义代码规范
通过以上的步骤，全部自动化直到镜像的构建和应用的发布，无需运维人员参与，即可完成应用发布，减少很多重复的劳动和时间。
简单部署和注意事项:
所有k8s的部署文件yaml，放在github上，docker部署都比较简单
gitlab部署： 注意事项，三个挂载卷必须挂在，不然数据丢失或者各种问题，三个开发端口，443，80，22
对应的映射端口可以自己选择，80对应web端口，22对ssh端口，即提交或者clone使用端口，443就是https
我们使用的是ce版本 9点多，较老，数据迁移时，需要一样的版本才行，选择版本看情况
gerrit 部署： 直接启动没什么好说，如何要和gitlab做同步，需要使用replication插件，replication文件修改，在gitlab上注册一个gerrit用户，配上gerrit公钥，执行同步，可以参考我的另一篇文章
xxxxxxx
jenkins部署：docker单机启动问题不大，在kubernetes上的话，build任务执行，需要新建一个building job pod ，直接挂载 pod所在node的docker.sock文件 运行build任务，相当于在容器里执行容器，具体的看我的yaml文件如何写，如果需要配置sonar，则需要sonar插件，在jenkins构建后执行推送至sonar服务器评审。
参考文章： xxxxxxxx
sonar部署：配置不多，就是最好学会自定义代码检查规则的做法
参考文章: xxxxxxxx
