喜欢CI的原因：我喜欢Jenkins主要是喜欢他自动化测试和通知、自动化部署和持续交付、代码质量检测三点。
[产品需求+开发阶段是没办法自动化，所以自动化在测试和运维部署出现]
严重警告：最好有Java基础来看和运行这本书案例。
由于这本书都是使用Java，基于Java开发的经验和知识可以探索这本书的精微，
使用其他语言反而容易在各种不同中读起来费劲，但是大体设计思路可以窥见。
注意事项：构建项目名称时候绝不可包含空格。
第一章 Jenkins简介
自动化构建的演变
第一阶段：手动构建(很多小公司正处于这个阶段)
团队没有中央构建服务器。软件在开发者手中手工触发构建。计划发新版本之前，手动集成代码改动。
第二阶段：夜间构建
团队有一个构建服务器，计划定期（夜间）触发自动化构建，一般只是代码编译，没有可靠可重复的单元测试。即便有自动化测试，也有可能运行不正确。
第三阶段：夜间构建+自动化测试
构建运行脚本去编译应用程序 + 自动化单元/组件/集成/接口测试 + 及时通信或者发邮件（想想这样也就差不多了）
第四阶段：自动化构建加入指标
运行自动化代码质量检查；测试代码覆盖率检查；
自动为应用程序生成API文档；测试质量下降警告；
项目状态仪表盘视图—》屏幕给团队成员。
第五阶段：自动化构建更深度的测试
测试驱动开发模式。
编译测试后，通过指标，自动部署到应用服务器进行更全面的端对端测试和性能测试。
第六阶段：自动化验收集成
在前面阶段的基础上进行自动化验收测试和自动化部署
发布测试报告
第七阶段：持续部署
第二章 迈入Jenkins的第一步
配置Jenkins，打开网页
配置：安全配置，构建工具，电子邮件，版本控制，第三方集成
构建作业是Jenkins构建过程的核心。
是以任务为单位。
比如：
构建作业编译源代码。
构建作业运行单元测试。
构建作业运行集成测试。
构建作业测量代码覆盖率。
构建作业检测代码质量。
构建作业生成技术文档，接口文档。
构建作业将应用程序部署到web服务器。
真实项目需要许多独立但是相关的构建作业或者构建任务。
构建方式：
实时构建常见方式：需要告诉Jenkins多久检查一次更新，这是Jenkins监控仓库，任何更改被提交时，就开始构建。
固定时间：每天一次；
手动触发
SCM(软件配置管理)使用提交后(post-commit)钩子远程触发构建
poll SCM：
unix - cron
min hours day month year
第三章 安装Jenkins
略
Linux
Mac
Windows
Mac-Jenkins-docker 这个比较简单，前提是你要安装docker。
由于Mac直接装Jenkins，Java版本不兼容，担心影响Mac系统对某些Java的支持，所以思考之下采用docker方式下载Jenkins做持续集成和持续发布。
在Linux Jenkins默认把数据（包含管理员密码）放在/var/jenkins_home。我Mac就放在/Desktop/jenkins_home。
docker安装就几步很简单。
1
docker pull jenkins 。拉取镜像Jenkins，名字叫做jenkins。
2
sudo docker run -d --name myjenkins -p 8099:8080 -p 50000:50000 -v /Users/Alex/Desktop/jenkins_home:/var/jenkins_home jenkins。
上面的命令给容器起来的名字是myjenkins，端口将内部的8080端口映射到我Mac的8099端口，把数据挂载到本地的桌面的jenkins_home文件夹，
制定的镜像是jenkins，即我们刚才docker pull拉下来的镜像。
3
http://localhost:8099会出现Getting Started。这个密码不是让你设定自己的密码，是要让你输入秘钥。
4
docker logs myjenkins 可以看到秘钥，复制并粘贴到网页里面或者
docker exec -t myjenkins /bin/bash 直接进入。
5 安装建议插件还有自定义插件。
6 下一步，创建管理员用户。
7 然后进入界面构建新项目，如果Jenkins要部署一个项目，一般通过git来获取源代码，因此如果部署有权限，开发者只要提交到git就会触发构建。
8
docker start myjenkins。 当docker停止后的重启。
第四章：配置Jenkins服务器
1 Jenkins ——系统管理——系统设置----
全局配置：管理员邮件地址：12243xxxxx@qq.com
smtp服务器 ：
smtp.qq.com（以QQ邮箱为例，port一般是463）邮件通知—高级----使用smtp认证：点击应用，先看看有没有收到邮件
2 新建一个自由风格的应用
配置github;
构建触发器，配置触发条件
构建环境
构建-增加构建步骤
保存或者应用
3 点击配置可以修改我们的配置
4 点击控制台输出（如果找不到就点击）
第四章 配置Jenkins服务器
基本都在配置系统那个栏目里面
第五章 设置构建作业
构建作业是Jenkins构建过程的基本职能。
是以任务为单位。
比如：
构建作业编译源代码。
构建作业运行单元测试。
构建作业运行集成测试。
构建作业测量测试代码覆盖率。
构建作业检测代码质量。
构建作业生成技术文档，接口文档。
构建作业将应用程序部署到web服务器。
真实项目需要许多独立但是相关的构建作业或者构建任务。
基本就是代码审查（python一直使用pylint），测试覆盖率，技术文档生成。
自由式构建作业是通用的构建作业，为什么称为自由式，因为提供了最大的灵活性。
监视外部作业：非交互的比如定时脚本crontab
多组态作业：不同配置运行相同的构建作业。用于不同的环境，不同的数据库，甚至不同构建机器上测试应用程序。
你希望如何处理构建历史？
构建历史会消耗大量的磁盘空间，存储构建的产物，比如二进制文件。比如生成随着时间推移静态分析和代码覆盖率度量的报告的代码质量度量作业，可能要为整个项目生成记录，当然对于自动部署应用程序到测试服务器的构建作业不太重要。
discard old builds: 允许构建历史记录的作业数。
throttle builds: 构建节流阀（throttle有勒死，节流阀门之意）
设置构建作业基本流程：
构建项目的基本信息——》版本控制工具——》设置触发构建的策略——》构建的具体步骤——》构建后的测试报告和技术文档
（1）general：项目的名称，描述，源码地址
（2）source code management：版本控制管理工具，git（ssh密钥配置）
（3）build triggers：触发构建的策略。基本git插件提供了定时基础上Poll SCM的能力，即随时轮询发生变化就构建（Gerrit Trigger有利于对托管在git版本控制系统的项目源代码进行代码审查）
（4）build steps：如何具体的构建。现在Jenkins知道从哪里获取源代码了。这个地方让你准确的告诉Jenkins你到底想如何构建项目。
maven ,ant or shell or windows batch cmd
（5）actions after build:,聚合下游测试结果，构建完毕的测试结果发送邮件,归档人工制品工件(archive the artifacts)，需要提供文件的完整路径
第六章 自动化测试
第一 自动化单元测试和集成测试
Coverage是一种用于统计Python代码覆盖率的工具
自动化测试并且生成测试覆盖率代码报告，测试报告和代码覆盖率，unittest报告并没有测试覆盖率
想要搞Jenkins的目的就是自动化测试生成带有代码审查，自动化测试和有测试代码覆盖率和用例通过的详细报告
如果不使用自动化测试，你就必须自己保留构建版本并且手动测试他们，这违背持续集成的理念。
写出高质量的测试，最有效的方法就是先写测试，使用TDD(测试驱动开发)或者BDD(行为驱动开发)等敏捷开发的技术。
持续集成需要快速反馈。
关注测试运行结果反馈：
（1）代码覆盖率：代码覆盖率可以作为一个测量实际开发实现情况的合适指标。
这个是一个cpu和内存密集型过程，会降低构建作业的速度，你需要单元测试和集成测试成功后在单独的Jenkins构建作业中运行代码覆盖率度量。
（python中,unittest和coverage可以做到）
（2）成功率，失败率
（3）运行时间：单元测试应该设计为快速运行，时间过长可以作为性能问题的一个标志。比如1000个unit/5min,如有必要一定要调查。
（4）结果报告
（5）邮件发送
第二 自动化验收测试：强调展示给非开发人员。
详尽的测试用例应该在开发者测试阶段完成。BDD(行为驱动开发)有助于生成验收测试面向公众化。
要确保一个专有的构建测试作业，以便于非开发人员能够查看和专注于业务聚焦的测试，而不被低级的活着技术性的问题所打扰。
其实就是比如unittest 生成的html报告。如果要archive为pdf可以使用插件。
第三 自动化性能测试
性能测试是测试一个非常重要的领域。
被检测出来的越晚，修复就要花费越多的时间。
要精确找出性能下降的地方。
这里推荐Jemeter。Jemeter又是一个很严肃的东西。
[对于python，一般的接口单元测试使用requests+unittest+HTMLTextrunner,对于性能测试使用jemeter线程组，全都放在Jenkins中集成]
一个构建失败的消息越晚报告给你，越没有价值，越难以修复。尽可能尽自己最大的努力让测试尽可能的快速。
自动化测试是持续集成环境里非常关键的一部分，应该严肃对待，尤其是快速反馈。
第七章 Jenkins安全
主配置界面
Enable security
Jenkins基于身份认证和授权的安全模型灵活可拓展。
Jenkins安全矩阵。
定义用户的安全域，允许他们做什么（授权）。
jerkins监控一个提交到源码的变更时自动添加所有的的SCM用户进入这个数据库。
许多机构使用LDAP目录来存储应用程序用户账户和密码，Jenkins很好的集成了LDAP，无须特殊的插件，检查组成员和获取用户电子邮件。
Jenkins 可以使用unix用户和用户组。需要为每一个Jenkins新用户创建并设置新的用户账号。
servelet容器授权。
基于项目的安全。
基于角色的安全。
审计日志，跟踪用户的行为。
第八章 通知
提高项目健康状况的信息流程，比如单元测试和集成测试套件的回归测试失败。
被动策略：开发者自觉查阅最新构建状态。
主动策略：在构建失败时主动提醒开发人员。
邮件是CI最明显和最常见的形式。
电子邮件的通知策略：
（1）快速构建（单元/集成测试，runtime < 5 min)： 通知发给组长以及提交更改的开发人员。
（2）慢速构建（快速构建完成以后，验收测试构建): 发给组长，测试人员和提交更改的开发人员。
（3）每晚构建（在其他正常的基础上，QA质量保证度量，性能测试）：所有团队成员，日常状态会议前，提供项目状态快照图。
对于特别关键的作业，短信通知是最优秀的策略。
第九章 代码质量
高质量的代码包括功能上更少的bug , 易于阅读，易于维护。
遵循编码标准。
设计编码美学。比如代码布局和格式化，命名规则。
Jenkins使用插件规范代码质量，报告代码复杂度。
第十章 高级构建
可以根据不同的参数运行相同的构建作业
参数化构建作业：
1 在你构建作业的时候选择 This build is parameterized——Add Parameter
2 为构建适配参数化构建脚本比如shell
第十一章 分布式构建
使用Jenkins建立个管理大量的构建服务器。
如何进行分布式构建：
Jenkins主节点使用SSH从节点代理
开箱即用在Jenkins里面加入New Node
如果网络架构禁止使用SSH，在每个从节点放salve.jar，然后命令行启动从节点
节点监控策略和监控要素：
Jenkins 不仅仅只是分派构建作业到代理，他主动监视你的从节点机器，如果该节点不能完成一个构建就将此节点脱机。你可以从manage nodes即管理节点精确微调Jenkins监控到内容。
监控响应时间
监控临时目录空间（构建作业会消耗大量磁盘）
监控swap空间
监视系统时钟（时钟不同步，会发生奇怪的错误）
如果没有达到标准，Jenkins将自动让服务器下线。
云计算：云计算使用因特网资源扩展或者替换本地计算架构。包括电子邮件和文件共享，异地数据存储，技术服务比如源代码库（GitHub）。
当选择基于云的CI架构时，某些资源无法从互联网访问，则会限制你的选择。
持续集成中，分布式构建是真正可拓展架构的关键。一旦开始分布式构建，基于云的分布式构建是一个非常合乎逻辑的延伸，把构建放在云端可以使你需要时更容易，更加方便的拓展。
第十二章 自动化部署和持续交付
持续集成本质就是精益流程的持续改进这种哲学理念。
持续交付：把整个部署过程自动化起来，一键触发。
一般意义上部署之后，用户可以用。
自动化部署：开发完毕部署，测试人员测试
持续交付：测试完毕，交给用户
冒烟测试：这一术语源自硬件行业。对一个硬件或硬件组件进行更改或修复后，直接给设备加电。如果没有冒烟，则该组件就通过了测试。
即基本的电路通电测试，对于软件就是保证基本没有功能问题，然后继续下一步的自动化测试和性能测试。
回归测试：修改了bug以后，再测一遍。
回滚更改
自动化部署的高级形式为持续部署，持续交付，这被认为是现代持续集成基础设施的高峰。
第十三章 Jenkins的维护
一 监控和限制磁盘空间
如何分给Jenkins足够的内存
discard old builds: 设定历史构建量为20或者时间限制30天以内，超过就会删除旧的构建，会保留最后一次成功的构建
使用disk usage插件
二 监控服务器负载
总执行器数量：指主从节点上所有执行器的数量。
繁忙执行器数量：被占用的执行器数量。
队列长度：等待执行的构建作业数量。
三 备份配置
周期性备份Jenkins_home
四 构建迁移
如何将Jenkins从一台服务器迁移到另一台服务器
/Jenkins_home/jobs
通过Jenkins实例间复制或移动构建作业目录来拷贝作业。
将构建作业目录直接复制到运行中的Jenkins实例也是安全的，无需重启查看导入结果，在 管理Jenkins界面重载磁盘配置，就可以把新作业显示在Jenkins仪表盘。
如果要删除原有服务器上构建的作业目录，要先关闭服务器上的Jenkins服务。
如果你想把作业迁移到全新的Jenkins配置，记得安装迁移原有服务器的插件。plugins目录下，可以简单复制所有文件，复制到新实例对应的目录下。
读书结语：
对于不同的编程语言，不同的测试方式，不同的部署方式，在Jenkins集成上插件选择上，都在构建作业上有相当明显的不同。
因此，在阅读这本书只不过简略介绍了Jenkins，如果要完全掌握它，那么对于你所掌握的语言，插件，测试方法，部署方式都要有足够的精熟。
安装Jenkins，直接操作Jenkins，持续集成，时间积累，经验堆砌，才可以更加明确你业务的需要和技术的满足。
扫一扫
2850
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
