标签：程序 debian 市场 url 备份 原因 不同类 目的 roi
持续集成（Continuous Integration）是一种软件开发实践。
以上的技术选型，都是尽量使用 开源 且 主流 的系统，这样的好处如下：
在上一篇文章里面，对持续集成绘制过一个基本的结构图，如下：
基本流程如下：
开发人员推送代码到Git
Git通知Jenkins
Jenkins开启构建
Jenkins通知自动化发布系统
发布系统持续后续的任务……
这里面涉及的系统有：
关于 自动化发布系统 这个基本上属于运维方面的内容，在互联网产品领域情形和技术需求比较复杂，暂时不列入本部分的内容。但是Jenkins 能够有接口去通知相应的发布系统，以达到 事件信息流的连续性
本文则主要从技术角度来将这些系统联合起来。
关于 Jenkins 的下载及安装，可以参考其官网。
|
1
|
https://jenkins-ci.org/ |
直接下载Ubuntu/Debian版本，在Ubuntu服务器上安装即可。
由于过程比较简单，网上相关教程很多，此处也不再赘述。但是一般Jenkins安装完毕后，最初的权限配置会比较繁琐，所以本文重点从相应的使用场景出发，实现一个完整的带权限配置的解决方案。
对于只是在 内网 使用持续集成的团队来说，权限的配置就相对简单一些。因为只是在内网，所以可以将权限的要求放松，只要保证公司网络之外的人无法访问到 Jenkins 服务即可。
注意：如果要和git服务的webhook形成完整的事件流，则git服务也需要在内网，否则 构建事件 无法被 代码推送事件 给触发。
对 Jenkins 进行如下操作：
[系统管理]->[Configure Global Security]->[访问控制]->[授权策略]->[项目矩阵授权策略]
对 匿名用户 进行如下配置：
具体配置界面如下：
注意：如果不这样配置，则后面提到的基于git的构建触发器将无法通过调用指定的url接口来触发构建。因为webhook只能构造 单次 简单的http请求，无法构造由多个请求组成的会话，故而无法调用需要身份授权的接口。
一般情况下，构建都是以代码的发布作为起始事件点，所以需要和git服务器建立事件关联，在Jenkins具体的项目的配置界面中，对 构建触发器 进行配置。
目前网络上一般都是介绍的这种方式，具体的细节，此处就不再赘述，感兴趣的同学可以自行在网络上搜索。
基本原理图如下：
可以达到如下效果：
以上的内网方案的特点如下：
当然，对于 开发资源相对匮乏 的小团队而言，推荐通过以上方法 快速搭建 自己的内部的持续集成系统，毕竟先快速生产自己的特色产品才是最重要的事情。
对于前面的 内网持续集成系统 的优点和缺点都介绍之后，作为一个以 开放为主要精神 的互联网团队来说，肯定是无法满足这样一个 封闭的内部网络 系统的，所以下面就要隆重介绍 公网持续集成系统 。
对于 内网系统 在配置上进行了 偷懒 ，但是实际上却在其它地方付出了 巨大的代价 ，这些代价包括：
所以，如果配置人员拥有一定的系统设计能力和开发能力，还是建议搭建 公网持续集成系统 。
公网方案具有如下特点：
可扩展性强，理论上可以和任何的公共互联网服务进行对接
公网持续构建系统对权限控制有如下要求：
对 Jenkins 进行如下操作：
[系统管理]->[Configure Global Security]->[访问控制]->[授权策略]->[项目矩阵授权策略]
可以建立三类用户并进行权限配置：
登录后，可以查看相应的项目的名称及构建的状态（主要是基本的查看功能）
登录后，可以进行构建操作，对任务进行增加及删除等等高级操作（主要是项目管理功能）
未登录用户，不具备任何权限，只呈现登录界面
有了这样的登录授权机制，就不用再使用网络进行隔离了，此系统就可以放心地放到公网服务器上了。
前面提到的内网系统的解决方案，主要原因是：
如果部署到公网，则需要解决如上的矛盾之处。一个比较好的思路就是：
在兼顾Git的webhook的特点和Jenkins构建特性的情况下，可以提出如下所描述的解决方案：
使用web服务作为中间件，来模拟用户登录：将本来需要多个请求组成的会话变成单一的Http请求（可以在单次请求的url里面加入授权的token），这样就可以被Git的webhook所调用。
基本原理图如下：
主要的通讯过程为：
当然，由于 Jenkins 提供了Pyhon语言的SDK，所以以上 步骤2和3其实可以简化为对其SDK的调用了。
安装方法：
|
1
|
pip install python-jenkins |
最简单的使用示例如下：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
|
# coding:utf-8"""jenkins相关的工具函数及配置"""from dtlib.dtlog import dlogimport jenkins__author__ = ‘harmo‘jenkins_url =‘http://jenkins.xxxx.com‘jenkins_user = ‘jenkins_user‘jenkins_passwd =‘jenkins_user_password‘def build_job(project_name): """ 构建项目 :param project_name: 项目名称 :return: """ jen =jenkins.Jenkins(jenkins_url, username=jenkins_user, password=jenkins_passwd) jen.build_job(project_name) print("build %s succeed" %project_name)if __name__ == ‘__main__‘: build_job("your-project-name") |
开发人员只需要在自己的web程序里面集成此SDK，并进行参数化，即可完成webhook和jenkins的中间件。
可以达到如下效果：
使用中间件的好处是，对构建的事件有很好的订制性，包括分支监控，提交人权限等等。当然，也可以只使用最简单的功能：只要有人向 release 分支提交了代码，那么就会触发自动构建流程，这样就完成了整个流程了。
当然，构建成功之后到发布还有一些后续的流程，比如：
开发人员完成代码，自测完毕后，推送代码到 release 分支
触发自动构建，构建成功，并生成构建产物
将构建产物发布到 测试服务器
由 自动化发布系统 完成构建产物向生产服务器发布的过程
在得知Jenkins有Python语言的SDK之前，其实还有个其它方法也能够完成登录授权并调用构建接口。直接通过接口来模拟用户登录行为（因为Jenkins登录处不需要验证码），然后获取登录成功的sessionid ，以此作为授权token来调用构建的接口。
具体的技术实现的代码细节不在本文的讨论内容中出现，只要了解登录的原理，很容易就开发出来。
此处做一些说明的目的是，其实只要了解原理，即使官方没有提供一些工具，仍然也是有办法完成想要的功能的。
持续集成的平台搭建完毕后，关于其可应用的项目也进行一些简单的介绍。
基本上任何的软件项目，从生产到最终发布都可以划分为如下几个过程：
不同类型项目，无非就是构建过程不同而已，本文也简单的列举一下几类项目的应用方式的流程，关于具体的技术手段就由各人根据各自的项目去做相应的订制开发了。
主要的代表有：Php，Python等等。
它们的构建产物就本身的源代码，所以整个持续集成的过程如下：
主要的代表有：Java等。
过程如下：
主要代表有：Javascript,css等。
过程如下：
主要代表有：Android等。
过程如下：
开发人员发布代码到Git仓库
Jenkins同步代码到本地，并使用构建工具生成构建产物Apk
将构建产物统一备份到相应目录，做好发布产物的备份，方便回滚
安装到设备，执行测试
Jenkins系统运行界面：
Jenkins本身可以实现如下功能：
再通过文章前半部分提到的系统，团队就可以达到 持续交付 和 持续部署 的目的，从而实现项目的 快速迭代 。
持续交付：
持续部署：
当然，还有后续的更多的扩展功能，就需要测试开发人员去实现了。
此文作为 持续集成 系列文章的具体技术实现部分，介绍了一个通用的技术框架的解决方案。剩下的就是各种针对自己的工程特性是编写各种脚本和安装各种环境了。这样 理论加实践，就构成了能够提供生产力的 持续集成 系统，大家Enjoy it吧。
目前以 Google 为代表的大型的互联网公司，基本上都是保持着这样的开发节奏。《Google软件测试之道》里面提到了这样的生产方式，但是没有给出具体的技术解决方案，本文则将这种构想进行技术落地，并发布此方案，希望能够给后来者一些帮助吧。
（如果大家有兴趣，后面可以针对某个具体的项目，来一个完整的持续集成示例，包括构建代码的编写，及过程的截图等等。但是如果反响不大，就不再浪费时间了）
标签：程序 debian 市场 url 备份 原因 不同类 目的 roi
原文地址：http://www.cnblogs.com/tester-l/p/6045455.html
