|
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如日中天的今天，不懂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 欢迎大家多多交流。
后面有时间的话，还想给大家分享一下我对几大源码托管服务器的经验。 希望大家顶啊。。。。
http://byNeil.com
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如日中天的今天，不懂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 欢迎大家多多交流。
后面有时间的话，还想给大家分享一下我对几大源码托管服务器的经验。 希望大家顶啊。。。。
|
请发表评论