持续集成及部署利器:Go
Go是一款先进的持续集成和发布管理系统,由ThoughtWorks开发。(不要和Google的编程语言Go混淆了!)其前身为Cruise,是ThoughtWorks在做咨询和交付交付项目时自己开发的一款开源的持续集成工具。后来随着持续集成及持续部署的火热,ThoughtWorks专门成立了一个项目组,基于Cruise开发除了Go这款工具。
Go的官方网站是http://www.thoughtworks.com/products/go-continuous-delivery/,其文档是http://www.thoughtworks.com/products/docs/go/13.3/help/welcome_to_go.html。
在我目前的项目中,持续集成及部署工具使用的就是Go这款工具。使用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。
在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作为开源软件,虽然免费,但是出现问题要么自己动手解决,要么等待维护社区修复。 Jenkins作为开源产品,社区比较活跃,文档资料和插件都比较多,而Go的文档或资料较少。
Go的设计思想还是挺前卫的,在别人还在做持续集成这一步时,它已经做到了持续部署这个层次。但是目前就国内而言能做到持续部署的公司真的不多,甚至很多公司连持续集成这个实践都没有达到。所以Go作为一款收费产品很难在国内打开市场。
我觉得Go可以做出一个免费版来让个人试用,提供一些基本功能。然后为企业应用定制一些高级功能,放置到收费版中,可以扩大自己的市场占用率。
学一点Git--20分钟git快速上手
在Git如日中天的今天,不懂git都不好意思跟人说自己是程序猿。你是不是早就跃跃欲试了,只是苦于没有借口(契机)。 好吧,机会就在今天。 给我20分钟,是的,只要20分钟, 让你快速用上git。
我们废话不多说,直接来干货。
我们将会介绍一下几点:
一, 什么是git
二,使用git的一般开发流程
三,快速安装新建项目。holloword。
开始:
一,什么是git。
阅读本文的前提是你知道或者用过至少一种源代码管理工具,比如:SVN, CVS 或者TFS等等。 你必须知道什么是源代码管理。如果这些都不满足。请直接跳过本文。
了解陌生事物的最好办法,是和已知事物类比。 ---孔子
我们以svn为例。 我们都知道传统的源代码管理都是以服务器为中心的:
每个开发者都直接连在中间服务器上, 本地修改,然后commit到svn服务器上。
这种做法看似完美,但是有致命的缺陷:
1. 开发者不能本地跟踪代码版本。 所有的信息都是在服务器上。 你把本地的代码改了很多,但是又不能提交。通常,本地只能缓存一个版本。对于小项目无所谓, 但是项目一复杂,人员多就麻烦了。 通常你本地的代码都全是红色的。自己都不知道今天修改了什么, 有哪些修改是真正应该提交给svn的。
2. 因为第一点,一旦离开服务器, 程序猿将无法正常工作。 因为本地不能跟踪代码版本。 你的(几乎)任何操作都必须连上服务器。比如, show log, blame,show history等等。
3. 中央服务器压力过大。 因为每个人都必须把代码提交到服务器,并且做daily build。
4. 对于大型项目, svn几乎不可用。 例如linux内核项目, 开发者何止几万? 都直接提交给svn服务器的话还不乱套了。
5. 对于个人的私人项目而言(或者对于小公司的项目), 不用版本控制当然不行,但是为了用版本控制而专门假设svn服务器有有点舍不得。
有没有能解决上述几个问题的东东呢? 恩, 答案是肯定的。
Linux内核的作者也遇到了这些问题,于是他决定再一次改变世界, 重写一个可以本地使用的svn。
对, 这就是git。 分布式代码版本管理系统。(说人话 :就是不用服务器的svn)
我们来看git的结构:
git没有中央服务器。 你装上git软件之后,你就可以指定本地的文件夹进行版本控制了。你可拔掉网线,然后在本地修改, commit,revert(rollback), branch, restore, show log, blame, history 等等, 全部你之前在svn里面可以用的操作。 简单的说,你就完美了。
你可能意识到一个问题了。 就是天下大乱了。
每个人都自顾自的开发,怎么协作呢? 恩,通常git比svn会多出两个操作, 就是 pull 和push。
我们看一个复杂一点的图:
开发者之间通过 pull和push操作, 把别人的修改拉过来,或者把自己的修改推给别人。
恩,你可能还是觉得有问题,我们生产 环境中, 以谁的代码为最终版本呢?
这个问题确实比较棘手,因为,从单纯的技术上将,每个开发者的机器都是对等的。 没有主次之分。
我们还有办法:
技术上不能解决的问题,我们从制度上解决. ---- 孟子
从分布式环境中我们模拟出一个中心来:
我们引入Leader这个角色。 他的机器是最终版本。 每个开发者都必须把最终的修改版push给leader。 leader会review然后提交。他就是最终版本。
恩, 我们好像还漏掉一个大问题, 说git,怎么漏掉了github呢。 github是什么。
我们知道,如果每个人都本地修改的话,本地可能不安全,(硬盘坏了,笔记本被偷了。。。。)
我们可能需要一个安全的服务器来存储/备份代码。对于开源的项目,可能是需要一个地方分享你的代码,你不可能24小时开着笔记本,让别人从你这pull代码。
于是, 网上所有的源代码托管网站就冒出来了。 github就是这样的。
看这个图, 我只修改了其中一个地方, 就是把leader的机器换成了。 github.com 提供的在线账户。
所以没有git和 github没有必然联系。
这里有几个常用的在线托管地址, 有兴趣自己看看:
1. github.com, 大名鼎鼎。 免费,只支持开源项目, 不支持私有项目。
2. bitbucket.com ,同样大名鼎鼎。 免费, 支持开源项目和私有项目。 免费用户最多5个。项目无限。
3. git.oschina.net, 国内顶尖托管平台, 我本人正在用的就是这个。 支持开源项目和私有项目。 成员无限, 项目1000个。 使用的是阿里云服务器, 速度极快。 本人推荐5颗星。
二, git开发的一般流程。
上面其实已经涉及了使用git的一般结构。 那么生产环境中, git是如何应用的呢。
本人知道的模型如下:
每个开发者都向自己的项目服务器(leader)提交代码, leader向公司服务器提交。 当然这个leader是可有可无的。如果项目小的话, 开发者可以直接向公司服务器提交。 公司的服务器就是最终版本。 一般公司还会有持续集成CI服务器。 我们可以在公司的源码服务器上设置git的hook。 自动触发CI服务器工作。 这是后话,不多说了。
三, 前面的概念弄清楚之后, 上手就容易多了。 我们helloword。
1. 这是git的官网:http://git-scm.com/ 去下载windows客户端。
如果是linux的话, sudo apt-get install gitcore
2. 注意, 官网的客户端都是命令行的。 命令行是高阶用法。不在这里说了。 我们下个gui。
我用的是TortoiseGit。 https://code.google.com/p/tortoisegit/ , 大家恐怕都熟悉svn时代的乌龟爬。上手快。 我们下面的操作都是gui上的。
安装过程不说了。 一路next。 我们跳过。 直接到最后。假设你现在已经安装完成了。
比如我已经有一个工程, helloworld:
这是工程文件的内部结构:
现在我们想让helloworld用上git怎么做呢, 在工程根目录下,点击鼠标右键。
选择 Create repository。
这个选项不要勾上。 稍后我们会解释什么是 Bare。
然后就完成了。
里面多出了一个 .git目录。 当前的目录(及其所有子目录)已经在git的监视之中了。 但是当前的代码还没有添加到git的跟踪数据库中。 简单的说,git还没有储存任何版本信息。 我们需要进行第一次提交:
git默认你本地会有一个主分支master。
我们写一些注释, 并且勾上想要添加到git的文件。 (如果有子目录的话, 它都会显示在这里。)
提交完成, close。 这个push按钮,稍后再说。
好了,这个时候我们在回到文件夹,看看有什么变化:
现在这些文件就添加进git了。
剩下的你就可以为所欲为了。 想svn一样,自己试试几个命令吧: 修改, difference, commit, revert,
到这你已经入门了。
最后我们来介绍两个重要的概念。
1. “git目录”, 就是指上图中,项目根目录下生成的 “.git” 文件夹。 用过svn的同学都知道, svn有‘.svn’文件夹。 他们的作用差不多。 这里保存了git的本地数据库资料。就是所有的版本信息。 跟svn不一样的地方就是,git中,只有根目录下有这个目录, 所有的子目录下都没有, 也就是每个工程只有一个.git目录。
2. “git工作目录”, 其实就是你的工程目录, 比如上图中的工程跟目录:H:\mycode\helloworld\ 。 问什么有这个工作目录呢。 就是你工作在这个目录下, 你可以修改编辑里面的文件,最后把修改提交给git目录。 这个共组目录还有一个神奇的地方就是, 你可以创建不同的branch(你默认工作在master下), 当你切换不同的branch时, 你的工作目录(工程目录)里的所有文件都会变成当前branch对应的文件。 这个不展开了。
最后再解释上面留下的两个问题:
1. “Bare” 创建Bare的意思是: 你只想要git的数据库(即上图中的 “.git”文件夹。), 而不想要当前的文件。 这通常用在公司的中央服务器上。 它不需要当前项目的实际代码,只需要保留git数据库信息就行了。
2. 在commit之后的对话框中的 push的意思。 正如之前介绍的。 push的意识是把你的修改push给别人(或者给公共服务器)。 commit的意思只是提交到本地的 .git 数据库。 并没有更新别别人。 所有提交完之后, 乌龟很贴心的给我们一个push按钮。 通过它你可以快速把刚刚的修改push给别人,或者给服务器。
总结, 这不是一本完全的git手册,但至少能让你消除git恐惧症,快速入手。
这里是gitbook的中文版: http://gitbook.liuhui998.com/ 他是真正的大而全。 为什么最后才说它呢? 因为它就像是一本 牛津大辞典, 全面,权威。 但是对于幼儿园小朋友学英语,就不能一上来就背它吧。 先跟着别人说,上手要紧。 之后有什么不会的,再去查字典。
好了。 就到这。 欢迎大家访问我的个人独立博客: http://blog.byneil.com 欢迎大家多多交流。
后面有时间的话,还想给大家分享一下我对几大源码托管服务器的经验。 希望大家顶啊。。。。