持续集成及部署利器:Go

Go是一款先进的持续集成和发布管理系统,由ThoughtWorks开发。(不要和Google的编程语言Go混淆了!)其前身为CruiseControl,是ThoughtWorks在做咨询和交付交付项目时自己开发的一款开源的持续集成工具。后来随着持续集成及持续部署的火热,ThoughtWorks专门成立了一个项目组,基于Cruise开发除了Go这款工具。ThoughtWorks开源持续交付工具Go,Go的官方网站是http://www.go.cd/,其文档是http://www.thoughtworks.com/products/docs/go/13.3/help/welcome_to_go.html。使用Go来建立起一个项目的持续部署pipeline是非常快的,非常方便。

Go的架构设计

Go使用了Server-Agent的模式。Server用来展示和配置pipeline的DashBoard,并存放构建出来的Artifacts(存档文件,比如一个war包); Agent则用来执行真正的构建操作,一个Server可以和多个Agent建立连接,Agent支持多个主流的操作系统。

这样的好处是:

测试可以运行在不同的平台上,保证你的软件在多个平台都能良好的工作;

你可以将测试划分为不同的群组并并行的运行在多个Agent上,节省运行测试时间;

可以方便的管理Agent,及时响应不同的环境要求。

Agent的lifecycle

下图是Agent工作的生命周期。

每一台Go的构建节点机器上都需要安装Go Agent软件(这个名字蛋疼,不是FQ的那个软件),其用来建立起与Go Server的连接。 Go Agent会以轮询的方式来询问Go Server是否有当前有构建工作。如果有的话,Go Server会将其分配给处于ready状态的Agent。该Agent会在自己机器目录上创建一个目录,并下载同步最新的材料(比如配置的SVN repo地址),然后执行指定的task,比如构建项目,运行单元测试或功能性测试等。如果配置了artifacts(比如构建的结果,一个war包),Agent执行完毕后将这个artifacts发布到Go Server上,这样artifacts就会被接下来的stage用到。

Go中的一些概念

Go对复杂的构建和部署活动进行了合理的抽象,并提供了GUI和XML两种方式来配置pipeline。

GoConcepts

在Go的世界中,多个pipeline可以共同组成一个group,这叫做pipeline group。没个pipeline又由多个stage组成。假设一个pipeline需要做如下事情: 构建项目->部署到测试环境->部署到生产环境。那么每一个环节都可以设置为一个stage。而一个stage则由1个或多个job组成。比如构建项目这个stage,可能会分为编译及验证->功能性测试,每一步可以作为一个job。job则由一个或多个task组成。比如功能性测试这个job可以分为两个task来完成,先将artifacts部署到测试机上,再运行功能性测试。

Go和Jenkins的比较

Go在设计之初就是一款持续部署工具,而Jenkins其实只是一款持续集成工具,如果要实现持续部署需要安装相应的插件。 Go和Jenkins都是开源软件,虽然免费,但是出现问题要么自己动手解决,要么等待维护社区修复,Go可以向ThoughtWorks购买支持服务。 Jenkins作为开源产品,社区比较活跃,文档资料和插件都比较多,而Go的文档或资料较少。

Go as continuous delivery tool for .NET

迈出持续交付的第一步

时间: 2024-09-19 20:38:39

持续集成及部署利器:Go的相关文章

初创公司应该如何做好持续集成和部署?

作者介绍 裴双才,Geekwolf,现MAKA运维负责人,博客: http://www.simlinux.com.<FastDFS分布式存储实战>作者,<Ansible中文手册>译者.RHCA/RHCVA,混迹各种开源社区,专注高效运维.DevOps.性能优化.Docker.MySQL等方向,热衷技术分享,欢迎一起讨论技术,互相学习,共同进步. 前言 持续集成和部署是每一个互联网开发团队都必须要面对的问题,特别是在初创公司,由于业务和技术团队快速增长,技术积累较弱,所以一个高效的,

linux下持续集成自动部署脚本,自动从jekins拉取war包并重新部署 (我去,一个大坑,if中的变量要双引号引起来,不然始终是true)

[root@localhost tomcat-gl-8082]# cat deploy.sh  rm -rf webapps/gl/* rm -rf gl.war wget -qc "http://192.168.0.102:9000/jenkins/job/gl/ws/gl.war" echo "正在解压" unzip gl.war -d webapps/gl >/dev/null 2>&1 cp -r /configbak/gl/* weba

微服务的持续集成,四步“构建”一个代码世界

本文讲的是微服务的持续集成,四步"构建"一个代码世界,大师Martin Fowler对持续集成是这样定义的:持续集成是一种软件开发实践,即团队开发成员经常集成他们的工作,通常每个成员每天至少集成一次,也就意味着每天可能会发生多次集成.每次集成都通过自动化的构建(包括编译,发布,自动化测试)来验证,从而尽快地发现集成错误. 今天我们就来聊一聊微服务的持续集成. 目录 一.持续集成之构建 二.持续集成之部署 三.持续集成之测试 四.持续集成之发布 五.总结 一.持续集成之构建 当微服务产生

通过Docker容器运行持续集成/持续部署

本文讲的是通过Docker容器运行持续集成/持续部署,[编者的话] 对于Docker主流的应用场景:持续集成和持续部署(CI/CD)大家也许并不陌生.这篇文章从独特的视角阐述了如何利用各种云平台构建属于自己的CI/CD容器,笔者还自己扩展了Gitlab CI引擎,对CI感兴趣的同学对这个文章应该很感兴趣. 我曾经使用Docker了一段时间,在过去的一年里伴随着众多的Docker容器涌入,帮助用户们更容易的部署Docker容器到生产环境中.一些工具是第三方公司提供,当然也包括Docker公司自己的

什么是持续集成?持续交付?持续部署?

作者: 阮一峰 互联网软件的开发和发布,已经形成了一套标准流程,最重要的组成部分就是持续集成(Continuous integration,简称CI). 本文简要介绍持续集成的概念和做法. 一.概念 持续集成指的是,频繁地(一天多次)将代码集成到主干. 它的好处主要有两个. (1)快速发现错误.每完成一点更新,就集成到主干,可以快速发现错误,定位错误也比较容易. (2)防止分支大幅偏离主干.如果不是经常集成,主干又在不断更新,会导致以后集成的难度变大,甚至难以集成. 持续集成的目的,就是让产品可

《移动App测试的22条军规》——第23章,第22节实现微信App的持续集成和持续部署

23.22 实现微信App的持续集成和持续部署由于我们并没有微信App的代码,所以我们不能部署微信App的持续集成环境,但是我们可以部分实现微信App的持续部署. 为了实现Android版本微信App生成安装文件并部署到设备上的过程,我们可以首先把微信App的安装文件复制到电脑上的Dropxbox文件夹下(如图23.64所示). 通过以微信App的测试为例,我们实际演练了如何使用移动App测试的22军规来指导测试.虽然笔者演示的内容相对基础,但是相信大家在了解到如何使用这22条军规之后,可以结合

谈谈持续集成,持续交付,持续部署之间的区别

经常会听到持续集成,持续交付,持续部署,三者究竟是什么,有何联系和区别呢? 假如把开发工作流程分为以下几个阶段: 编码 -> 构建 -> 集成 -> 测试 -> 交付 -> 部署 正如你在上图中看到,「持续集成(Continuous Integration)」.「持续交付(Continuous Delivery)」和「持续部署(Continuous Deployment)」有着不同的软件自动化交付周期. 持续集成 持续集成是指软件个人研发的部分向软件整体部分交付,频繁进行集成

持续集成:从六个层次加速测试执行

在持续集成领域,一个产品的发布往往都有自己的过程周期(lifecycle),大体都会划分为:构建->部署->测试->发布等几个重要阶段,其中测试是发布产品前不可或缺的重要阶段,是产品质量的保证.而能让持续集成奏效,除了要求测试脚本更充分健壮,还要求测试脚本运行得更快更好.这点对于小型项目而言可能显得无关紧要,毕竟大多小项目的测试脚本不过百条,验证点不过千"点":但对于一个大型项目而言,测试代码源文件可能成百上千,执行完所有的测试可能要等很久,而苦等之后的结果却可能是满

另一个关于持续集成和版本分支的故事

经典书籍<持续交付>[1]的作者曾就分支合并和代码演化等问题详细地讨论 过滥用分支对持续集成的负面影响.而我今天要说的是这样一个故事,一个只能 申请到非常有限的硬件设备的团队,他们是如何在多分支策略下实践持续集成的 . 一个团队接手了一个项目,需要在开发新特性的同时维护几个发布分支.团队 计划实践持续集成,但手头的硬件资源严重不足,无法满足所有分支的部署流水 线同时运转. 流水线分为三个阶段,分别是: commit 编译.单元测试和部分集成测试并打包 at 部署应用程序并运行自动化验收测试 u