持续集成

郑昀 创建于2016/6/18 最后更新于2016/6/19 点击查看我的《 如何从零搭建一个技术平台 》，这是一个系列。转载时请注明“转载自旁观者-博客园”或者给出本文的原始链接。 本文档适用人员：技术人员 何谓 ACP？ 阿里协作平台 是也。 自动化测试、自动化构建、自动化运维、环境维护、资源申请和释放、虚拟机集群、容器集群……对于一支庞大的技术团队，这些名词术语意味着生产效率，意味着快速迭代，意味着研发、测试、运维 All in，当然也可能意味着混乱，有操不完的心，有维护不完的事，工程越多，并行项目越多，麻烦越大。 去年年底，我们的一支小分队与支付宝一起并肩作战了三个月，近距离观察了他们的研发协作和应用发布过程。回来后，志全、老白、明骏给大家分享了所见所闻，我们试图从中找到云纵研发协作和持续集成的未来之路。不久之后，田志全明确了切入方式，云纵 CloudEngine 开始开发。 我们先来看一眼 CloudEngine 的庐山真面目： 图0，云纵 CloudEngine 首页-管理员身份 下面先介绍一下蚂蚁金服的玩法。 蚂蚁金服的研发协作是怎么运转的 一套精密的体系 如下图1所示，我们可以把庞大的蚂蚁金服研发支撑体系浓缩为这四个平台： ACP，阿里协作平台 九州资源管控平台 AQC，蚂蚁质量基础设施平台 Zpass，蚂蚁集团发布部署平台 ACP 是总驱动方。九州，AQC

写在最前的总结：Jenkins其实就是一个工具，这个工具的作用就是调用各种其他的工具来达成你的目的。比如你要获取Subversion上最新的源代码，Jenkins会去调用SVNKIT(插件的核心Jar的名称)。然后你需要编译源代码(假设是用maven编译)，Jenkins会去调用maven的插件。最后你可能需要发布程序到服务器上(假设是使用的Tomcat提供服务)，你可以通过Tomcat自己的API发布程序(有个插件就是通过这个功能实现的发布)，你也可以通过ssh通道自己写shell脚本去实现。总之，Jenkins就是一箱工具，在它能力范围内你想干什么都可以。 Q:Jenkins是什么？ A:百度一下你就知道！ Q:Jenkins有哪些版本？ A:这个版本太多了，具体去看官网吧！www.jenkins-ci.org Q:应该选择哪个版本的Jenkins？ A:如果你是公司正式使用推荐长期支持版(LTS)，原因：稳定。如果你是学习，随便哪个版本都可以。 Q:JDK应该安装哪个版本的？ A:推荐安装JDK7，原因：某些插件必须要求JDK7的支持。比如： Monitoring 插件 Q:Tomcat应该用哪个版本的？ A: Tomcat6或者7都可以。如果你要用Tomcat5.5的版本，我劝你趁早扔掉。不然一堆稀奇古怪的错误，看得你头晕。 Q: 可以直接用命令启动么？ A: 可以。命令

Sonar是一个用于代码质量管理的开放平台，通过插件机制，Sonar可以集成不同的测试工具、代码分析工具以及持续集成工具。与持续集成工具（如Hudson/Jenkins等）不同，Sonar并不是简单地把不同代码检查结果（例如：FindBugs、PMD等）直接显示在web UI界面上，而是通过不同的插件对这些结果再加工处理，通过量化的方式度量代码质量的变化，从而可以方便地对不同规模和种类的工程进行代码质量管理。 在对其他工具的支持方面，Sonar 不仅提供了对 IDE 的支持，可以在 Eclipse 和 IntelliJ IDEA 这些工具里联机查看结果；同时 Sonar 还对大量的持续集成工具提供了接口支持，可以很方便地在持续集成中使用 Sonar。 此外，Sonar 的插件还可以对 Java 以外的其他编程语言提供支持，对国际化以及报告文档化也有较好的支持。 Sonar 的功能就是来检查代码是否有 BUG。除了检查代码是否有 bug 还有其他的功能，比如说：你的代码注释率是多少，代码有一些建议，编写语法的建议。所以称之为质量管理。 一、部署Sonar 接下来的配置是基于博文 部署Jenkins+Gitlab实现持续集成 的环境进行部署 所有的源码包及插件都可以在此 链接 （提取码: t976）下载 [root@jenkins ~]# unzip sonarqube-5.6.zip

背景 在目前快节奏生活已经成为社会风潮的大背景下，越来越多的互联网公司为了其应用产品能更快的掌控风向脉搏，抢占市场红利，需要更快速的应用产品开发上线，在市场的反馈下，不断的迭代新功能。在此需求下，持续集成，持续部署，持续交付被越来愈多公司所推崇，DevOPS文化的兴起，一方面是实践打破运维与研发的堡垒之墙，另一方面也是敏捷开发过程中的必要产物。 提高软件开发效能，快速迭代、快速试错，以及根据自己开发团队特点，使用怎样的技术手段，才能是软件开发效能最高，更为快速敏捷，以及怎样才能满足产品能在最短周期、高质量的交付业务的诉求？ 本专栏在此背景下为大家提供Gitlab CI持续集成方案，通过一些列实战，让各位能够能直观清晰的理解这种模式，本专栏为抛砖引玉，各位结合，读者可以结合自己实际的生产环境来考虑是否引入此中模式，优化交付流程，释放研发最能大潜能，与此同时，读者可以在本专栏体验端到端的 CICD 的如丝般顺滑的CI体验，并且无论运维人员还是开发人员都能够在本专栏更系统宏观的了解和学习Gitlab CI的流程及具体操作方式。 一、 Gitlab 提到Gitlab CI，大家可能都会想到Gitlab，其作为目前最火的开业git托管服务端，相较于Github，各企业可以进行私有化部署，服务器自己维护，项目数据更加安全更可控，网络也更快及更安全。 Gitlab 为用户提供友好的web界面

3 月，跳不动了？>>> CI，Continuous Integration，持续集成，是一种软件开发实践，即团队开发成员经常集成它们的工作，通过每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译，发布，自动化测试）来验证，从而尽早地发现集成错误。 持续集成工具有很多，用过jinkens、瓦力，今天看到了阿里的reliable，挺有兴趣的，研究了一下，记录之。 **说明一下我的环境：阿里云centos7 x64 ** reliable官方主页： reliable-master 依赖环境：Node.js、MongoDB（数据存储）、Redis（缓存）, Docker reliable是运行在docker中的，使用docker-compose可以直接下载各个已经配置好的组件，无需自己安装了。所以只需要安装docker和docker-compose即可。 1、docker vim /etc/yum.repos.d/docker.repo #写入以下内容 [dockerrepo] name=Docker Repository baseurl=https://yum.dockerproject.org/repo/main/centos/$releasever/ enabled=1 gpgcheck=1 gpgkey=https://yum

TFS持续集成的就是跟踪代码变更，合并，能够自定义脚本，任务进行自动化测试，发版，部署，有点像docker的味道。在这个代理服务器分布式中tfsserver起着能够随时拿去最新代码能够统一执行任务的角色，所不同的是代理服务器仅仅是执行具体的编译，而tfs起着统一管理，调度，安排的作用。 那么tfs持续集成是怎么实现的？ 1 来看一篇博客 http://www.cnblogs.com/zjoch/p/5741499.html 先要理解tfs的持续集成的架构，即分布式架构，一个服务器可以配置多个代理池，每个代理池可以注册不同的代理服务器，每个代理服务器可以被定义多个任务 那么首先来解释一下代理池是什么？ 代理池其实就是一个容器与线程池的机制类似，他动态的监视代理服务器的状态，当还有任务需要执行，在代理池中分配空闲的代理服务器给任务进行执行，就是这么简单的理解就可以了 2 代理服务器 是的代理服务器，就是相当于公司部署了一个tfsserver，比我这个server是12的地址，有一天我自己下载一个代理服务器包到本地执行相关的配置命令然后搞一个windows服务器启动起来去tfsserver认证就可以了，其实认证的时候也就注册了，两边分布式的进行，注册上了就可以给代理池使用了。 3 注册代理服务器的过程蛋疼的事儿 不得不说windows ms应该是一直以来都没有把权限机制吃透

Gitlab 是一个利用 Ruby on Rails 开发的开源应用程序，实现一个自托管的 Git 项目仓库，可通过Web 界面进行访问公开的或者私人的项目 Gitlab 拥有与 Github 类似的功能，能够浏览源代码，管理缺陷和注释。可以管理团队对仓库的访问，他非常易于浏览提交过的版本并提供一个文件历史库。他还提供一个代码片段收集功能可以轻松实现代码复用，便于日后有需要的时候进行查找 一、环境准备 如果是测试环境，其内存建议2G及以上，可以去 清华开源镜像站 下载所需gitlab版本，其安装后，会自动安装nginx提供web界面，所以要避免80端口占用。 二、安装部署gitlab 1. 安装gitlab [root@git /]# mkdir git [root@git /]# cd git/ [root@git git]# wget https://mirrors.tuna.tsinghua.edu.cn/gitlab-ce/yum/el7/gitlab-ce-11.9.8-ce.0.el7.x86_64.rpm [root@git git]# rpm -ivh gitlab-ce-11.9.8-ce.0.el7.x86_64.rpm #当gitlab安装完毕后会有一个大狐狸头 #由于我不打算做域名解析，所以需要修改其配置文件 [root@git git]# vim /etc

Jenkins介绍 Jenkins 只是一个平台，真正运作的都是插件。这就是 jenkins 流行的原因，因为 jenkins 什么插件都有Hudson 是 Jenkins 的前身，是基于 Java 开发的一种持续集成工具，用于监控程序重复的工作，Hudson 后来被收购，成为商业版。后来创始人又写了一个 jenkins，jenkins 在功能上远远超过hudson。 1、什么是集成？ 指的是代码由编译、发布和测试、直到上线的一个过程。 2、什么是持续集成？ 高效的、持续性质的不断迭代代码的集成工作。 3、如何高效准确的实现持续集成 必不可少的需要一套能自动化、并且可视化的平台来帮助我们。 根据以上几点来看，Jenkins就是一个可以实现持续集成的平台。 4、为什么是Jenkins来帮助我们实现持续集成？ 1）Jenkins是一个开源的、且基于JAVA代码开发的持续集成系统 因为含有非常丰富的插件支持，所以我们可以方便的打通版本库、测试构建环境、线上环境的所有环节。并且丰富友好的通知使用者和开发、管理人员。 2）安装维护简单 安装Jenkins，不太复杂。而且支持通用的平台。 3）Java应用常用 在企业的软件构建过程中，JAVA的应用工程稍显复杂，由于复杂构建和代码上线、并且服务的重启。整个过程下来，消耗的时间较多，Jenkins却能很好的集成maven的编译方式

go docker kubernetes 软件生产线的问题、持续集成，持续发布，以及DevOps中的技术必须通过PaaS 分布式服务化的问题。 分布式服务化的服务高可用、服务编排，服务调度、服务发现、服务路由、以及分布式服务化的支撑技术完全PaaS的菜 paas platform-as-a-Service 平台即服务 2019-04-08 整理后的服务，发现了一个极其优美的图形化结构，各个节点的边界清晰，职责分明；节点间的链路畅通，协议规整。这时我们知道我们终于走在了正确的道路上。 服务一定是围绕业务的 服务的交互是标准的 保证单一业务服务高效聚合 降低服务间的相互调用 协议标准、框架标准、 接口标准 : 接口分两种：业务内部接口，业务服务接口。无论哪种接口同样遵循标准化原则 认证鉴权协议 加密解密协议 内部接口交互协议 外围接口服务协议 各个协议各司其职，用来支撑服务通信的标准化 真正的restful： 请求参数涵盖默认语义，包括：Get（获取信息），Post（创建），Put（全量修改），Patch（部分修改），Delete（删除） https://www.infoq.cn/article/D-cBEauI4oTVqwUsx5Fk https://www.infoq.cn/article/Zo-0vtAzNStPZBFVEP4g 2019-04-04 yum install

写在前面 自从参加了4月份的QCon以后，持续集成的念头一直在脑海中浮现。时隔四个月之后，终于有了实践的机会。在此，首先应该感谢头儿们的大力支持。记得参加Scrum的培训时，最开始提到的一个障碍就是来自上层。因为上层希望看到的是实实在在的成果，如果现有的开发模式和质量管理系统已经有了比较好的效果，他们就不太愿意尝试新的模式。而这次正是有了头儿们的理解和支持，我才能放开手脚、“无所顾忌”地尝试这些新手段。其次，应该感谢我的天才同事们。因为，每次即使小小的改动都会给他们的开发带来一些不便，但是他们都会毫无抱怨地接受，并且总能给出一些我意想不到的想法，帮助我不断地改善这个系统。 虽然当前的CI系统还存在诸多问题，但是应该是时候做个总结了，记下这个过程发生的点点滴滴。还是那句话，能帮助看到这些文章的同学解决一些实际的问题。 CI运行的操作系统是： 64位的Cent OS 版本控制系统是CI中不可缺少的一环，在前面的两篇文章中已经记录了Subversion在CentOS下安装和配置过程： Cent OS上配置Apache2 + SVN Cent OS上配置Apache2 + SVN（续）实现对目录访问的精确控制 这次就从Maven开始。 第一次和Maven的交战，我铩羽而归。这次做好了打持久战的准备。 一、安装（与Eclipse集成） 在Eclipse下使用Maven，需要安装