持续集成

时间 2019-11-08

标签持续集成繁體版

原文原文链接

持续集成基础概念

随时随地将代码合并，这种方法叫作持续集成。html

开发写代码的演变：前端

一我的开发单打独斗，撸代码、开发网站、自由自在
多个开发同时开发一个网站，同时改一份代码。可是同时改一个网站会致使冲突
分支结构，天天上班第一件事就是克隆代码，下班前最后一件事，合并代码
好景不长，开发愈来愈多，大妈稳健愈来愈多。天天下班前合并代码，发现不少失败的文件。最后加班3小时人工合并代码。
解决办法：将代码的周期缩短，之前一天，如今一小时，半小时...

1、持续集成

Continuous integration （CI）java

持续集成是一种软件开发实践，
即团队开发成员常常集成他们的工做，一般每一个成员天天至少集成一次，也就意味着天天可能会发生屡次集成。
每次集成都经过自动化的构建（包括编译，发布，自动化测试)来验证，从而尽快地发现集成错误。
许多团队发现这个过程能够大大减小集成的问题，让团队可以更快的开发内聚的软件。

持续集成强调开发人员提交了新代码以后，马上进行构建、（单元）测试。
根据测试结果，咱们能够肯定新代码和原有代码可否正确地集成在一块儿。
持续集成的好处主要有两个:
一、快速发现错误
每完成一点更新，就集成到主干，能够快速发现错误，定位错误也比较容易
二、防止分支大幅偏离主干
若是不是常常集成，主干又在不断更新，会致使之后集成的难度变大，甚至难以集成。

持续集成的目的，就是让产品能够快速迭代，同时还能保持高质量。
它的核心措施是，代码集成到主干以前，必须经过自动化测试。
只要有一个测试用例失败，就不能集成。

2、持续交付

Continuous delivery（CD）node

持续交付在持续集成的基础上，
将集成后的代码部署到更贴近真实运行环境的「类生产环境」（production-like environments）中。
好比，咱们完成单元测试后，能够把代码部署到链接数据库的 Staging 环境中更多的测试。
若是代码没有问题，能够继续手动部署到生产环境中。

频繁的讲软件的新版本，交付给质量团队或者用户，以供评审。
若是评审经过，代码就进入生产阶段。

持续交付能够看作是，持续继承的下一步
它强调的是，无论软件怎么更新，软件是能够随时随地能够交付的。

3、持续部署

Continuous deployment（CD）python

持续部署则是在持续交付的基础上，把部署到生产环境的过程自动化。linux

持续部署的目标是，代码在任什么时候候都是能够部署的，能够进入生产阶段。nginx

持续部署的前提是，能自动完成测试、构建、部署等步骤git

4、持续继承的通常流程

根据持续集成的设计，代码从提交到生产，整个过程有如下几步。web

提交

　　流程的第一步，是开发者向代码仓库提交代码。全部后面的步骤都始于本地代码的一次（commit）正则表达式

测试（第一轮）

　　代码仓库对commit操做配置好了钩子（hook），只要提交代码或者合并进主干，就会跑自动化测试

构建

　　经过第一轮测试，代码就能够合并进主干，就算能够交付了。

　　交付后，就先进行构建（build），再进入第二轮测试。所谓构建，指的是将源码转换为能够运行的实际代码，好比安装依赖，配置各类资源（样式表、JS脚本、图片）等等。

　　经常使用的构建工具以下。jeknins、Travis、codeship等。

测试（第二轮）

　　构建完成，就要进行第二轮的测试。

　　若是第一轮已经涵盖了全部测试内容，能够省略第二轮，固然，这时的构建步骤也要移到第一轮测试前面。

　　第二轮是全面测试，单元测试和集成测试都会跑，有条件的额haul，也要作端对端测试。全部测试以自动化为主，少数没法自动化的测试用例，就要人工跑。

部署

　　经过了第二轮测试，当前代码就是一个能够直接部署的版本（artifact）。将这个版本的全部文件打包（tar filename.tar *）存档，发到生产服务器。

　　生产服务器将打包文件，解包成本地文件，再将运行路径的符号连接（symlink）指向这个目录，而后从新启动应用，这方面的部署工做有Ansible，Chef，Puppet等。

回滚

　　一旦当前版本发生问题，就要回滚到上一个版本的构建结果。最简单的作法就是修改一下符号连接，指向上一个版本的目录。

认识DevOps

DevOps是什么？

开发的考核标准是：实现了多少功能，写了多少代码。

运维的考核标准是：系统有多稳定。

因此，在现实中.....他们之间有巨大的鸿沟

DevOps 一词的来自于 Development 和 Operations 的组合，突出重视软件开发人员和运维人员的沟通合做，
经过自动化流程来使得软件构建、测试、发布更加快捷、频繁和可靠。
目前对 DevOps 有太多的说法和定义，不过它们都有一个共同的思想：
“解决开发者与运维者之间曾经不可逾越的鸿沟，加强开发者与运维者之间的沟通和交流”。
而我我的认为， DevOps 能够用一个公式表达：
文化观念的改变 + 自动化工具 = 不断适应快速变化的市场 强调：
DevOps 是一个框架，
是一种方法论，
并非一套工具，他包括一系列的基本原则和实践。 其核心价值在于如下两点： 更快速地交付, 响应市场的变化。
更多地关注业务的改进与提高。

为何须要DevOps？

一、产品迭代

在现实工做中，每每都是用户不知道本身想要什么，
可是当咱们设计完一个产品后，他告诉咱们他们不须要什么，
这样咱们的产品须要反复的迭代，并且过程多是曲折的，
那咱们有什么好的办法快速的交付价值，灵活的响应变化呢？
答案就是 DevOps。由于 DevOps 是面向业务目标，助力业务成功的最佳实践。

二、技术革新

如今的IT 技术架构随着系统的复杂化不断的革新，从最期的全部服务在一个系统中， 
发展到如今的微服务架构、从纯手动操做到全自动流程、从单台物理机到云平台，

技术永远在更新，永远在学习

DevOps如何落地

落实DevOps的指导思想

　　高效的协做和沟通、

　　自动化流程和工具、

　　迅速敏捷的开发、

　　持续交付和部署

　　不断学习和创新。

咱们来看一张来自devops经典著做《success with enterprise dev-ops-whitepaper》的介绍图

敏捷管理：一支训练有素的敏捷开发团队是成功实施 DevOps 的关键。
持续交付部署：实现应用程序的自动化构建、部署、测试和发布。经过技术工具，把传统的手工操做转变为自动化流程，这不只有利于提升产品开发、运维部署的效率，还将减小人为因素引发的失误和事故，提前发现问题并及时地解决问题，这样也保证了产品的质量。下图展现了 DevOps 自动化的流程：

IT 服务管理：可持续的、高可用的 IT 服务是保障业务正常的关键要素，它与业务是一个总体。IT 服务管理（ITSM），它是传统的“IT 管理”转向为“IT 服务”为主的一种模式，前者可能更关注具体服务器管理、网络管理和系统软件安装部署等工做；然后者更关注流程的规范化、标准化，明肯定义各个流程的目标和范围、成本和效益、运营步骤、关键成功因素和绩效指标、有关人员的责权利，以及各个流程之间的关系等，好比创建线上事故解决流程、服务配置管理流程等。
精益管理：创建一个流水线式的 IT 服务链，打通开发与运维的鸿沟，实现开发运维一体化的敏捷模式。精益生产主要来源于丰田生产方式 (TPS)的生产哲学，它以下降浪费、提高总体客户价值而闻名，它主要利用优化自动化流程来提升生产率、下降浪费。因此精益生产的精髓是即时制（JIT）和自动化（Jidoka）。精益管理贯穿于整个 DevOps 阶段，它鼓励主动发现问题，不断的优化流程，从而达到持续交付、快速反馈、下降风险和保障质量的目的。

实施 DevOps 的具体方法

创建快速敏捷的团队

按照业务功能划分团队，创建沟通群组，设置产品负责人（一个策划人员）、Scrum Master
（咱们通常选择测试人员担任，测试驱动开发模式）和开发者团队（前端工程师、后端工程
师、测试各一名），造成以下的组织结构和系统架构：

实现自动化流程

提交：工程师将代码在本地测试后，提交到版本控制系统，如 Git 代码仓库中。
构建：持续整合系统（如 Jenkins CI），在检测到版本控制系统更新时，便自动从 Git代码仓库里拉取最新的代码，进行编译、构建。
单元测试：Jenkins 完成编译构建后，会自动执行指定的单元测试代码。
部署到测试环境：在完成单元测试后，Jenkins 能够将应用程序部署到与生产环境相近的测试环境中进行测试。
预生产环境测试：在预生产测试环境里，能够进行一些最后的自动化测试，例如使用Appium 自动化测试工具进行测试，以及与实际状况相似的一些测试可由开发人员或客户人员手动进行测试。
部署到生产环境：经过全部测试后，即可以使用灰度更新将最新的版本部署到实际生产环境里。

DevOps在落地实施过程当中常常会遇到的问题

人手紧缺
跨部门协做，前期沟通培训成本高
前期投入工做量大见效少

DevOps 技术栈

敏捷管理工具

Trello
Teambition
Worktile
Tower

产品&质量管理

confluence
禅道
Jira
Bugzila
其中 confluence 和禅道主要是产品的需求、定义、依赖和推广等的全面管理工具；而
Jira 和 Bugzilla 是产品的质量管理和监控能力，包括测试用例、缺陷跟踪和质量监控等。
目前咱们使用 Jira 和禅道较多。

代码仓库管理

Git
Gitlab
Github
Git 是一个开源的分布式版本控制系统；Gitlab 和 Github 是用于仓库管理系统的开源
项目，它们使用 Git 做为代码管理工具，并在此基础上搭建起来的 web 服务。咱们主要使用
的是 Git 和 Gitlab

自动化构建脚本

Gradle
Maven
SBT
ANT

虚拟机与容器化

VMware
VirtualBox
Vagrant
Docker

持续集成（CI）&持续部署（CD）

Jenkins
Hudson
Travis CI
CircleCI
Jenkins 是一个开源软件项目，是基于 Java 开发的一种持续集成工具，用于监控持续重复的工做，旨在提供一个开放易用的软件平台，使软件的持续集成变成可能，它的前身为Hudson。
Travis CI 是目前新兴的开源持续集成构建项目，它与 jenkins 很明显的区别在于采用yaml 格式，简洁清新独树一帜。
CircleCI 是一个为 web 应用开发者提供服务的持续集成平台，主要为开发团队提供测试，持续集成，以及代码部署等服务

自动化测试

Appium
Appium 是一个移动端的自动化框架，可用于测试原生应用，移动网页应用和混合型应用，且是跨平台的。可用于 IOS 和 Android 以及 firefox 的操做系统。
Selenium
Selenium 测试直接在浏览器中运行，就像真实用户所作的同样。Selenium 测试能够在Windows、Linux 和 Macintosh 上的 Internet Explorer、Mozilla 和 Firefox 中运行。
Mock 测试
Mock 测试就是在测试过程当中，对于某些不容易构造或者不容易获取的对象，用一个虚拟的对象来建立以便测试的测试方法。这个虚拟的对象就是 Mock 对象，Mock 对象就是真实对象在调试期间的代替品。
Java 中的 Mock 框架经常使用的有 EasyMock 和 Mockito 等。
消费者驱动契约测试
契约测试是一种针对外部服务的接口进行的测试，它可以验证服务是否知足消费方期待的契约。当一些消费方经过接口使用某个组件的提供的行为时，它们之间就产生了契约。
这个契约包含了对输入和输出的数据结构的指望，性能以及并发性。而 PACT 是目前比较流的消费者驱动契约测试框架。

自动化运维工具

Ansible
Puppet
Chef
SaltStack

监控管理工具

Zabbix
Zabbix 是一个基于 WEB 界面的提供分布式系统监视以及网络监视功能的企业级开源解决方案。
ELK Stack 日志分析系统
ELK Stack 是开源日志处理平台解决方案，背后的商业公司是 Elastic。它由日志采集解析工具 Logstash、基于 Lucene 的全文搜索引擎 Elasticsearch、分析可视化平台Kibana 三部分组成。
云监控（如 Amazon CloudWatch）
Amazon CloudWatch 是一项针对 AWS 云资源和在 AWS 上运行的应用程序进行监控的服务。您能够使用 Amazon CloudWatch 收集和跟踪各项指标、收集和监控日志文件、设置警报以及自动应对 AWS 资源的更改。

版本控制概要

学习开源软件，建议直接学习官方文档，由于跟新的太快了。你能在网上找到的，不必定正确。

#1 什么是版本控制
版本控制（Revision control）是一种在开发的过程当中用于管理咱们对文件、目录或工
程等内容的修改历史，方便查看更改历史记录，备份以便恢复之前的版本的软件工程技术。
#1.1 版本控制的目的
实现跨区域多人协同开发
追踪和记载一个或者多个文件的历史记录
组织和保护你的源代码和文档
统计工做量
并行开发、提升开发效率
跟踪记录整个软件的开发过程
减轻开发人员的负担，节省时间，同时下降人为错误
简单说就是用于管理多人协同开发项目的技术。
没有进行版本控制或者版本控制自己缺少正确的流程管理，在软件开发过程当中将会引入
不少问题，如软件代码的一致性、软件内容的冗余、软件过程的事物性、软件开发过程当中的
并发性、软件源代码的安全性，以及软件的整合等问题。
#1.2 版本控制能够作什么？
自动生成备份
知道改动的地方
随时回滚 
#2 常见的版本控制器
主流的版本控制器有以下这些：
Git
SVN（Subversion） - 集中式的额版本控制系统
CVS（Concurrent Versions System）
VSS（Micorosoft Visual SourceSafe）
TFS（Team Foundation Server）
Visual Studio Online
版本控制产品很是的多（Perforce、Rational ClearCase、RCS（GNU Revision Control
System）、Serena Dimention、SVK、BitKeeper、Monotone、Bazaar、Mercurial、SourceGear
Vault），如今影响力大且使用普遍的是 Git 与 SVN
#3 版本控制分类
#3.1 本地版本控制
记录文件每次的更新，能够对每一个版本作一个快照，或是记录补丁文件，适合我的用，
如 RCS。
#3.2 集中版本控制
全部的版本数据都保存在服务器上，协同开发者从服务器上同步更新或上传本身的修改
全部的版本数据都存在服务器上，用户的本地只有本身之前所同步的版本，若是不连网
的话，用户就看不到历史版本，也没法切换版本验证问题，或在不一样分支工做。并且，全部
数据都保存在单一的服务器上，有很大的风险这个服务器会损坏，这样就会丢失全部的数据，
固然能够按期备份。表明产品：SVN、CVS、VSS
#3.3分布式版本控制
全部版本信息仓库所有同步到本地的每一个用户，这样就能够在本地查看全部版本历史，
能够离线在本地提交，只需在连网时 push 到相应的服务器或其余用户那里。因为每一个用户
那里保存的都是全部的版本数据，只要有一个用户的设备没有问题就能够恢复全部的数据，
但这增长了本地存储空间的占用。

Git的简介和历史

#1 Git 简介
Git 是一个开源的分布式版本控制系统，用于敏捷
高效地处理任何或小或大的项目。
Git 是 Linus Torvalds 为了帮助管理 Linux 内核开发而开发的一个开放源码的版本
控制软件。
Git 与经常使用的版本控制工具 CVS, Subversion 等不一样，它采用了分布式版本库的方式，
没必要服务器端软件支持
#2 Git 的诞生
不少人都知道，Linus 在 1991 年建立了开源的 Linux，今后，Linux 系统不断发展，已
经成为最大的服务器系统软件了。
Linus 虽然建立了 Linux，但 Linux 的壮大是靠全世界热心的志愿者参与的，这么多人
在世界各地为 Linux 编写代码，那 Linux 的代码是如何管理的呢？
事实是，在 2002 年之前，世界各地的志愿者把源代码文件经过 diff 的方式发给 Linus，
而后由 Linus 本人经过手工方式合并代码！
你也许会想，为何 Linus 不把 Linux 代码放到版本控制系统里呢？不是有 CVS、SVN
这些免费的版本控制系统吗？由于 Linus 坚决地反对 CVS 和 SVN，这些集中式的版本控制系
统不但速度慢，并且必须联网才能使用。有一些商用的版本控制系统，虽然比 CVS、SVN 好
用，但那是付费的，和 Linux 的开源精神不符。
不过，到了 2002 年，Linux 系统已经发展了十年了，代码库之大让 Linus 很难继续通
过手工方式管理了，社区的弟兄们也对这种方式表达了强烈不满，因而 Linus 选择了一个商
业的版本控制系统 BitKeeper，BitKeeper 的东家 BitMover 公司出于人道主义精神，受权
Linux 社区无偿使用这个版本控制系统。
安定团结的大好局面在 2005 年就被打破了，缘由是 Linux 社区牛人汇集，难免沾染了
老男孩IT教育
一些梁山好汉的江湖习气。开发 Samba 的 Andrew 试图破解 BitKeeper 的协议（这么干的其
实也不仅他一个），被 BitMover 公司发现了（监控工做作得不错！），因而 BitMover 公司怒
了，要收回 Linux 社区的无偿使用权。
Linus 能够向 BitMover 公司道个歉，保证之后严格管教弟兄们，嗯，这是不可能的。
实际状况是这样的：
Linus 花了两周时间本身用 C 写了一个分布式版本控制系统，这就是 Git！一个月以内，
Linux 系统的源码已经由 Git 管理了！牛是怎么定义的呢？你们能够体会一下。
Git 迅速成为最流行的分布式版本控制系统，尤为是 2008 年，GitHub 网站上线了，它
为开源项目免费提供 Git 存储，无数开源项目开始迁移至 GitHub，包括 jQuery，PHP，Ruby
等等。
历史就是这么偶然，若是不是当年 BitMover 公司威胁 Linux 社区，可能如今咱们就没
有免费而超级好用的 Git 了。
#3 Git 与 SVN 的区别
1、GIT 是分布式的，SVN 不是：这是 GIT 和其它非分布式的版本控制系统，例如 SVN，
CVS 等，最核心的区别。
2、GIT 把内容按元数据方式存储，而 SVN 是按文件：全部的资源控制系统都是把文件
的元信息隐藏在一个相似.svn,.cvs 等的文件夹里。
3、GIT 分支和 SVN 的分支不一样：分支在 SVN 中一点不特别，就是版本库中的另外的一
个目录。
4、GIT 没有一个全局的版本号，而 SVN 有：目前为止这是跟 SVN 相比 GIT 缺乏的最大
的一个特征。
五、GIT 的内容完整性要优于 SVN：GIT 的内容存储使用的是 SHA-1 哈希算法。这能确保
代码内容的完整性，确保在遇到磁盘故障和网络问题时下降对版本库的破坏。

实验前准备

1、实验环境要求
    操做系统：CentOS-7-x86_64
    配置：2VCPU+2048(最好 4096)+50G
    软件包：MInimal Install
    关闭 iptables 和 SELINUX
    注：1、建议初学者保持实验环境和本课程一致，包括但不局限于 IP 地址，主机名，网
卡名称等，能够为你节约不少由于环境问题的排错时间。2、作好虚拟机的快照，好比能够
根据本课程的不一样章节，建立不一样的快照，便于保留实验环境和在实验过程当中进行环境的回
滚。
    10.0.0.11  ci-node1
    10.0.0.12  ci-node2
    10.0.0.13  ci-node3
2、安装系统
3、系统初始化
    一、设置主机名解析：
　　[root@node1 ~]# cat /etc/hosts
　　127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4
　　::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
　　10.0.0.11 ci‐node1
　　10.0.0.12 ci‐node2
　　10.0.0.13 ci‐node2
　　2、安装 EPEL 仓库和经常使用命令
　　[root@node1 ~]# rpm ‐ivh http://mirrors.aliyun.com/epel/epel‐release‐latest‐7.noarch.rpm
　　[root@node1 ~]# yum install ‐y net‐tools vim lrzsz tree screen lsof wget ntpdate
　　3、关闭 NetworkManager 和防火墙
　　[root@node1 ~]# systemctl disable firewalld
　　[root@node1 ~]# systemctl stop NetworkManager
　　4、关闭 SELinux
　　[root@node1 ~]# vim /etc/sysconfig/selinux
　　SELINUX=disabled #修改成 disabled
　　5、设置时间：
　　[root@node1 ~]# crontab ‐l
　　*/5 * * * * /usr/sbin/ntpdate time1.aliyun.com
　　6、更改时区
　　老男孩IT教育
　　ln ‐sf /usr/share/zoneinfo/Asia/Shanghai /etc/localtime
四、其余要求
　　一、系统安装完成后作初始化快照
　　二、下载百度网盘文件。
　　连接：https://pan.baidu.com/s/16m5BVuhBSgtw1-_XTaJdmw 密码：pct9
　　三、使用提供的安装手册自行测试安装 Git、Gitlab、Jenkins。
　　四、注册 GitHub 账户

安装GIT

编译安装

默认在CentOS下，咱们能够经过yum的方式来安装Git
[root@node1 ~]# yum install git –y
[root@node1 ~]# git version
git version 1.8.3.1
使用yum安装的Git的版本是1.8，版本较低，咱们还能够经过源码编译的方式来安装Git的最新版本。
首先须要安装依赖的库：
[root@node1 ~]# yum install curl-devel expat-devel gettext-devel openssl-devel zlib-devel gcc perl-ExtUtils-MakeMaker -y
下载最新的源码包
[root@node1 src]# cd /usr/local/src/
[root@node1 src]# wget https://www.kernel.org/pub/software/scm/git/git-2.9.5.tar.gz
[root@node1 src]# ll
total 5792
-rw-r--r-- 1 root root 5928730 Aug 11 01:57 git-2.9.5.tar.gz
解压安装：
[root@node1 src]# tar xf git-2.9.5.tar.gz
[root@node1 src]# cd git-2.9.5
[root@node1 git-2.9.5]# make prefix=/usr/local/git all
[root@node1 git-2.9.5]# make prefix=/usr/local/git install
[root@node1 git-2.9.5]# rm -rf /usr/bin/git
[root@node1 git-2.9.5]# ln -s /usr/local/git/bin/git /usr/bin/git
[root@node1 git-2.9.5]# git --version
git version 2.9.5
至此，咱们已经完成了Git的编译安装，如今Git能够安装在windows、MAC操做系统上，具体请参考：
https://git-scm.com/book/zh/v2/%E8%B5%B7%E6%AD%A5-%E5%AE%89%E8%A3%85-Git

yum安装

Git分布式版本控制系统最佳实践 - 老男孩教育博客  http://blog.oldboyedu.com/git/
系统环境
CentOS7.4 防火墙和selinux关闭
安装Git
yum -y install git
Git全局配置
git config --global user.name "zy"  #配置git使用用户
git config --global user.email "zhangyao@oldboyedu.com"  #配置git使用邮箱
git config --global color.ui true  #语法高亮
git config --list # 查看全局配置

Git的配置文件

Git 的配置从上到下分三层 system/global/local,使用三个不一样参数进行设置，每一个层次的配置存储在不一样的位置，
1）./etc/gitconfig 文件：包含了适用于系统全部用户和全部库的值。
若是你传递参数选项’--system’ 给 git config，它将明确的读和写这个文件。
2）.~/.gitconfig 文件 ：具体到你的用户。你能够经过传递--global 选项使 Git 读或写这个特定的文件。
3）.位于 git 目录的 config 文件 (也就是 .git/config) ：不管你当前在用的库是什么，特定指向该单一的库。
每一个级别重写前一个级别的值。所以，在.git/config 中的值覆盖了在/etc/gitconfig 中的同一个值

[root@ci-node1 ~]# git config
usage: git config [options]

Config file location
    --global              use global config file       全局配置
    --system              use system config file       系统配置
    --local               use repository config file   仓库配置

初始化工做目录

mkdir git_data
cd git_data/
# 初始化
git init
# 查看工做区状态
git status

常规使用（建立数据-提交数据）

touch README
git status
git add README
git status
git commit -m 'first commit'   #→git commit提交暂存文件至版本库

GIT COMMIT -A 参数

添加新文件
git add  * 添加到暂存区域
git commit  提交git仓库   -m 后面接上注释信息，内容关于本次提交的说明，方便本身或他人查看修改或删除原有文件
常规方法
git add  *
git commit
简便方法
git commit -a  -m "注释信息"
-a 表示直接提交
Tell the command to automatically stage files that have been modified and deleted, but new files you have not told Git about are not affected.

删除暂存区数据

没有添加到暂存区的数据直接rm删除便可。
已经添加到暂存区数据：
git rm --cached database  
#→将文件从git暂存区域的追踪列表移除(并不会删除当前工做目录内的数据文件)
git rm -f database 
#→将文件数据从git暂存区和工做目录一块儿删除

重命名暂存区数据

没有添加到暂存区的数据直接mv/rename更名便可。
已经添加到暂存区数据：
git mv README NOTICE

查看历史记录

git log   #→查看提交历史记录
git log -2   #→查看最近几条记录
git log -p -1  #→-p显示每次提交的内容差别,例如仅查看最近一次差别
git log --stat -2 #→--stat简要显示数据增改行数，这样可以看到提交中修改过的内容，对文件添加或移动的行数，并在最后列出全部增减行的概要信息
git log --pretty=oneline  #→--pretty根据不一样的格式展现提交的历史信息
git log --pretty=fuller -2 #→以更详细的模式输出提交的历史记录
git log --pretty=fomat:"%h %cn"  #→查看当前全部提交记录的简短SHA-1哈希字串与提交者的姓名，其余格式见备注。

　　%s 提交说明。

　　%cd 提交日期。

　　%an 做者的名字。

　　%cn 提交者的姓名。

　　%ce 提交者的电子邮件。

　　%H 提交对象的完整SHA-1哈希字串。

　　%h 提交对象的简短SHA-1哈希字串。

　　%T 树对象的完整SHA-1哈希字串。

　　%t 树对象的简短SHA-1哈希字串。

　　%P 父对象的完整SHA-1哈希字串。

　　%p 父对象的简短SHA-1哈希字串。

　　%ad 做者的修订时间。

还原历史数据

Git服务程序中有一个叫作HEAD的版本指针，当用户申请还原数据时，
其实就是将HEAD指针指向到某个特定的提交版本，可是由于Git是分布式版本控制系统，
为了不历史记录冲突，故使用了SHA-1计算出十六进制的哈希字串来区分每一个提交版本，
另外默认的HEAD版本指针会指向到最近的一次提交版本记录，而上一个提交版本会叫HEAD^，
上上一个版本则会叫作HEAD^^，固然通常会用HEAD~5来表示往上数第五个提交版本。
git reset --hard HEAD^  #→还原历史提交版本上一次
git reset --hard 3de15d4 #→找到历史还原点的SHA-1值后，就能够还原(值不写全,系统会自动匹配)

还原将来数据

什么是将来数据？就是你还原到历史数据了，可是你后悔了，想撤销更改，可是git log已经找不到这个版本了。
git reflog  #→查看将来历史更新点

标签使用

前面回滚使用的是一串字符串，又长又难记。
git tag v1.0   #→当前提交内容打一个标签(方便快速回滚)，每次提交均可以打个tag。
git tag          #→查看当前全部的标签
git show v1.0   #→查看当前1.0版本的详细信息
git tag v1.2 -m "version 1.2 release is test"  #→建立带有说明的标签,-a指定标签名字，-m指定说明文字
git tag -d v1.0   #→咱们为同一个提交版本设置了两次标签,删除以前的v1.0
[root@centos7 git_data]# git reset --hard 0bdf2e7
HEAD is now at 0bdf2e7 modified README file
[root@centos7 git_data]# git reset --hard V1.0

对比数据

git diff能够对比当前文件与仓库已保存文件的区别，知道了对README做了什么修改后，
再把它提交到仓库就放⼼多了。
git diff README

分支结构

在实际的项目开发中，尽可能保证master分支稳定，仅用于发布新版本，平时不要随便直接修改里面的数据文件。
    那在哪干活呢？干活都在dev分支上。每一个人从dev分支建立本身我的分支，开发完合并到dev分支，
最后dev分支合并到master分支。
因此团队的合做分支看起来会像下图那样。

建立分支

git branch linux    #→建立分支
git checkout linux  #→切换分支
git branch   #→查看当前分支状况,当前分支前有*号
测试在linux分支修改文件并提交到git仓库，最后切换回master分支，你会发现什么呢？

合并分支

想把linux的工做成果合并到master分支上
先切换到master分支
git merge linux  #→合并Linux分支至master
查看合并的文件
git branch -d linux #→确认合并完成后，能够放心地删除Linux分支。

分支冲突

同时修改master和linux分支同一个文件并提交，最后merge。
查看合并结果
如何解决？
这种状况下Git就无法再为咱们自动的快速合并了，它只能告诉咱们readme文件的内容有冲突，
须要手工处理冲突的内容后才能继续合并。 
#Git用< <<<<<<，=======，>>>>>>>分割开了各个分支冲突的内容，
咱们须要手工的删除这些符号，并将内容修改

windows客户端使用

前面讲的都是linux客户端，在讲讲windows客户端使用，安装Git-2.10.0-64-bit。
windows的git，本质是windows上的linux系统
TortoiseGit-2.2.0.0-64bit  给git加外壳，svn客户端的git版本

Git服务器

前面咱们已经知道Git人人都是中心，那他们怎么交互数据呢？
一、使用GitHub或者码云等公共代码仓库
二、使用GitLab私有仓库

私有仓库

GitLab 是一个用于仓库管理系统的开源项目。使用Git做为代码管理工具，并在此基础上搭建起来的web服务。可经过Web界面进行访问公开的或者私人项目。它拥有与Github相似的功能，可以浏览源代码，管理缺陷和注释。能够管理团队对仓库的访问，它很是易于浏览提交过的版本并提供一个文件历史库。团队成员能够利用内置的简单聊天程序(Wall)进行交流。它还提供一个代码片断收集功能能够轻松实现代码复用。

代码仓库做为公司珍贵的财产，必定要单独部署在单独的服务器上，防止端口服务冲突。

经常使用的网站：

官网：https://about.gitlab.com/

国内源镜像清华源：https://mirrors.tuna.tsinghua.edu.cn/gitlab-ce/yum/

安装环境：

CentOS 6或者7
2G内存（实验）生产（至少4G）
安装包：gitlab-ce-10.0.6-ce
禁用防火墙，关闭selinux

# 实验中使用过的，由于这样快~~~好操做，下面还列举了其余方法，没有使用，由于安装这个软件真慢
安装文档https://about.gitlab.com/downloads/#centos7
下载了rpm的包，这个版本很稳定
[root@ci-node1 ~]# wget https://mirrors.tuna.tsinghua.edu.cn/gitlab-ce/yum/el7/gitlab-ce-10.2.2-ce.0.el7.x86_64.rpm
安装依赖包
[root@ci-node1 tools]# yum install -y curl policycoreutils-python openssh-server
rpm安装
[root@ci-node1 tools]# rpm -ivh gitlab-ce-10.2.2-ce.0.el7.x86_64.rpm 

配置文件
vim /etc/gitlab/gitlab.rb
修改extemal_url=“http://10.0.0.11”,透过访问这个地址来访问

#############这是什么鬼，忘记这个吧yum localinstall gitlab-ce-9.1.4-ce.0.el7.x86_64.rpm
只要修改了/etc/gitlab/gitlab.rb，就要执行gitlab-ctl reconfigure
gitlab-ctl reconfigure  #→初始化，就执行一次，
看状态/中止/启动/重启
gitlab-ctl status/stop/start/restart
经过浏览器访问页面10.0.0.11，设置初始密码，其余操做相似GitHUB。
若是出现502的错误，多是服务器的内存过小，请至少设置2G内存，生产环境中至少4G
帐户：root  密码本身设置为123456789

GitLab的详细使用和安装word参见文档，点击下载

或者查看官方文档https://about.gitlab.com/install/#centos-7

GitLab安装部署

1. 安装和配置必要的依赖关系Install and configure the necessary dependencies
若是你安装postfix发送邮件，请选择”网站设置”中。而不是使用后缀也能够用邮件或 配置自定义SMTP服务器。若是你想使用的进出口，请 配置为SMTP服务器。
在CentOS7，下面的命令将在系统防火墙打开HTTP和SSH访问。
yum install curl openssh-server postfix
systemctl enable sshd postfix
systemctl start sshd postfix
firewall-cmd –permanent –add-service=http
systemctl reload firewalld
2. 添加gitlab包服务器安装包Add the GitLab package server and install the package
curl -sS https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.rpm.sh | sudo bash
yum install gitlab-ce
3. 配置并启动gitlab Configure and start GitLab
gitlab-ctl reconfigure
gitlab-ctl status
gitlab-ctl stop
gitlab-ctl start
4. 浏览到主机名和登陆Browse to the hostname and login
Username: root 
Password: 5iveL!fe

gitlab服务构成

GitLab 由主要由如下13 个服务构成，他们共同承担了 Gitlab 的运做须要
Nginx：静态 web 服务器。
gitlab-shell：用于处理 Git 命令和修改 authorized keys 列表。
gitlab-workhorse: 轻量级的反向代理服务器。
logrotate：日志文件管理工具。
postgresql：数据库。
redis：缓存数据库。
sidekiq：用于在后台执行队列任务（异步执行）。
unicorn：An HTTP server for Rack applications，GitLab Rails 应用是托管在这个
服务器上面的。
咱们能够使用 gitlab-ctl status 命令来查看各服务的状态
[root@ci-node1 src]# gitlab-ctl status
run: gitaly: (pid 17752) 652s; run: log: (pid 8831) 5484s
run: gitlab-monitor: (pid 17768) 651s; run: log: (pid 9000) 5458s
run: gitlab-workhorse: (pid 17771) 651s; run: log: (pid 8898) 5478s
run: logrotate: (pid 17815) 650s; run: log: (pid 8930) 5471s
run: nginx: (pid 17821) 650s; run: log: (pid 8906) 5477s
run: node-exporter: (pid 17828) 649s; run: log: (pid 8978) 5465s
run: postgres-exporter: (pid 17833) 649s; run: log: (pid 9107) 5440s
run: postgresql: (pid 17841) 649s; run: log: (pid 8649) 5533s
run: prometheus: (pid 17850) 648s; run: log: (pid 9071) 5446s
run: redis: (pid 17858) 648s; run: log: (pid 8589) 5545s
老男孩IT教育run: redis-exporter: (pid 17865) 647s; run: log: (pid 9050) 5452s
run: sidekiq: (pid 17871) 646s; run: log: (pid 8811) 5490s
run: unicorn: (pid 17895) 645s; run: log: (pid 8772) 5496s

gitlab工做流程

Nginx

静态的访问

GitLab Shell

GitLab Shell 有两个做用：为 GitLab 处理 Git 命令、修改 authorized keys 列表。

经过 SSH 访问 GitLab Server 时，GitLab Shell 会：
限制执行预约义好的 Git 命令（git push, git pull, git annex）
调用 GitLab Rails API 检查权限
执行 pre-receive 钩子（在 GitLab 企业版中叫作 Git 钩子）
执行你请求的动做 处理 GitLab 的 post-receive 动做
处理自定义的 post-receive 动做
当经过 http(s)访问 GitLab Server 时，
工做流程取决于你是从 Git 仓库拉取(pull)代码仍是向 git 仓库推送(push)代码。
若是你是从 Git 仓库拉取(pull)代码，GitLab Rails 应用会全权负责处理用户鉴权和执行 Git 命令的工做；
若是你是向 Git 仓库推送(push)代码，GitLab Rails 应用既不会进行用户鉴权也不会执行 Git 命令，
它会把如下工做交由 GitLab Shell 进行处理：
调用 GitLab Rails API 检查权限
执行 pre-receive 钩子（在 GitLab 企业版中叫作 Git 钩子）
执行你请求的动做
处理 GitLab 的 post-receive 动做
处理自定义的 post-receive 动做

GitLab Workhorse

GitLab Workhorse 是一个敏捷的反向代理。它会处理一些大的 HTTP 请求，好比文件上
传、文件下载、Git push/pull 和 Git 包下载。其它请求会反向代理到 GitLab Rails 应用，
即反向代理给后端的 unicorn。

Git经常使用经常使用命令和目录及仓库管理

命令

gitlab-ctl status:查看gitlab组件状态
gitlab-ctl start:启动所有服务      
gitlab-ctl restart:重启所有服务   后面能够跟指定服务，只对，对应的服务有效
gitlab-ctl stop：中止所有服务     后面能够跟指定服务，只对，对应的服务有效
gitlab-ctl reconfigure:使配置文件生效（通常修改完主配置文件/etc/gitlab/gitlab.rb，须要执行此命令）
gitlab-ctl show-config ：验证配置文件
gitlab-ctl uninstall:删除gitlab（保留数据）
gitlab-ctl cleanse:删除全部数据，重新开始
gitlab-ctl tail <service name>查看服务的日志

/var/opt/gitlab/git-data/repositories：库默认存储目录
/opt/gitlab：            应用代码和相应的依赖程序
/var/opt/gitlab：gitlab-ctl reconfigure命令编译后的应用数据和配置文件，不须要人为修改配置
/etc/gitlab：    配置文件目录  gitlab.rb
/var/log/gitlab：此目录下存放了gitlab各个组件产生的日志
/var/opt/gitlab/backups/：备份文件生成的目录

配置GitLab

关闭注册功能

扳手---Settings---Sign-up Restrictions

applications自定义界面和导航栏

Create group

GitLab是经过组（group）的概念来管理仓库（project）和用户（user），经过建立组，在组下再建立仓库，再将用户加入到组，从而实现用户与仓库的权限管理。

建立组的时候，path和name保持一致，

Create user

建立dev用户

grant user

在页面上设置用户类型

保护分支

在实际使用过程当中，咱们一般会保持 master 分支稳定，用于生产环境的版本发布，只
有受权的用户才能够向 master 合并代码。要实现此功能，咱们须要将 master 设置为保护分
支，并受权什么用户能够向 master 用户推送代码。

一、使用 root 用户点击 git_test 仓库页面左下角的 Settings

二、进入设置页面，选择设置菜单栏下面的 Repository 选项，
三、进入 repository 设置页面，
四、展开 Protected Branches
置完成后，在仓库分支页面，可看到 master 分支后面出现一个绿色的 protected 标记。
此时咱们再尝试在 ci-node2 上推送 master 分支到 GitLab，

咱们发现此时咱们已经不能在 ci-node2 上向 GitLab 上推送 master 分支，由于咱们
ci-node2 绑定的是 dev 用户，dev 用户属于 developer 角色，master 分支不容许 developer
角色向其推送内容。
须要合并的时候，在仓库页面提出申请

GitLab配置SSH

生成key------ ssh-keygen #生成密钥命令----- cat /root/.ssh/id_rsa.pub 查看公钥

Linux上复制公钥------绑定到GitLab的root上------点击root用户-----找到左边栏SSH------复制------保存

将本地仓库推送到GitLab ------git remote add gitlab url

初始化GitLab仓库

使用Gitlab远程仓库

GitLab备份管理

对 gitlab 进行备份将会建立一个包含全部库和附件的归档文件。

对备份的恢复只能恢复到与备份时的 gitlab 相同的版本。

将 gitlab 迁移到另外一台服务器上的最佳方法就是经过备份和还原。

gitlab 提供了一个简单的命令行来备份整个 gitlab，而且能灵活的知足需求。

备份配置

备份文件将保存在配置文件中定义的 backup_path 中 ，文件名为TIMESTAMP_gitlab_backup.tar
TIMESTAMP 为备份时的时间戳
TIMESTAMP 的 格 式为 ：
EPOCH_YYYY_MM_DD_Gitlab-version
默认的备份文件目录为：/var/opt/gitlab/backups，若是自定义备份目录须要赋予目录 git 权限
具体操做以下：
配置文件中加入
gitlab_rails['backup_path'] = '/data/backup/gitlab'
gitlab_rails['backup_keep_time'] = 604800 #备份保留的时间（以秒为单位，这个是七天默认值），
在命令行执行以下命令，若是软件自动生成了目录，在看一下权限是否正确，有的话，就不用执行下面的两行
[root@ci-node1 git_test] # mkdir /data/backup/gitlab -p
[root@ci-node1 git_test] # chown -R git.git /data/backup/gitlab
[root@ci-node1 git_test] # gitlab-ctl reconfigure

手动备份

在命令执行：gitlab-rake gitlab:backup:create 生成一次备份。
[root@ci-node1 git_test]# gitlab-rake gitlab:backup:create
Dumping database ...
Dumping PostgreSQL database gitlabhq_production ... [DONE]
done
Dumping repositories ...
* oldboy/git_test ... [DONE]
* oldboy/git_test.wiki ... [SKIPPED]
done
Dumping uploads ...
done...
...

定时备份

经过在定时任务里添加：
0 2 * * * /opt/gitlab/bin/gitlab-rake gitlab:backup:create CRON=1
咱们来实现定时备份，因为代码是一个企业很是重要的资产，因此咱们要重视 GitLab
的备份工做。至少作到天天备份一次，平时要注意检查备份的完整性。
环境变量 CRON=1 的做用是若是没有任何错误发生时， 抑制备份脚本的全部进度输出

恢复实践

GitLab 的恢复只能还原到与备份文件相同的 gitlab 版本的系统中，

恢复时，中止链接到数据库的进程（也就是中止数据写入服务），可是保持 GitLab 是运行的。

[root@ci-node1 git_test]# gitlab-ctl stop unicorn
ok: down: unicorn: 0s, normally up
[root@ci-node1 git_test]# gitlab-ctl stop sideki
[root@ci-node1 git_test]# gitlab-ctl status
run: gitaly: (pid 46031) 25295s; run: log: (pid 8831) 68406s
run: gitlab-monitor: (pid 46042) 25294s; run: log: (pid 9000) 68380s
run: gitlab-workhorse: (pid 46051) 25294s; run: log: (pid 8898) 68400s
run: logrotate: (pid 26776) 93s; run: log: (pid 8930) 68393s
run: nginx: (pid 46068) 25293s; run: log: (pid 8906) 68399s
run: node-exporter: (pid 46074) 25292s; run: log: (pid 8978) 68387s
run: postgres-exporter: (pid 46079) 25292s; run: log: (pid 9107) 68362s
run: postgresql: (pid 46126) 25291s; run: log: (pid 8649) 68455s
run: prometheus: (pid 46134) 25291s; run: log: (pid 9071) 68368s
run: redis: (pid 46142) 25291s; run: log: (pid 8589) 68467s
run: redis-exporter: (pid 46146) 25290s; run: log: (pid 9050) 68374s
run: sidekiq: (pid 25878) 524s; run: log: (pid 8811) 68412s
down: unicorn: 33s, normally up; run: log: (pid 8772) 68418s
接下来执行 gitlab 恢复操做：将备份的数字部分粘贴到BACKUP=后面
[root@ci-node1 git_test]# gitlab-rake gitlab:backup:restore 
BACKUP=1533288168_2018_08_03_10.2.2
整个恢复执行过程当中，咱们能够看到基本是在删除表，建立表。
完成后，重启服务。

执行升级操做

首先，下载新版本的 RPM 包，能够经过官网或者清华镜像站获取。
其次关闭部分 gitlab 服务
gitlab-ctl stop unicorn
gitlab-ctl stop sidekiq
gitlab-ctl stop nginx
执行升级操做
rpm -Uvh gitlab-ce-10.0.4-ce.0.el7.x86_64.rpm

从新配置 gitlab
重启 gitlab 服务
注：升级操做不建议进行。若是确实须要，也能够采起在一台新的服务器上安装新版本的 Gitlab
而后采用导入库的方式将旧系统的代码仓库导入到新 Gitlab 上。

Gitlab高级使用

查看文档

GitHub的使用

Github顾名思义是一个Git版本库的托管服务，是目前全球最大的软件仓库，拥有上百万的开发者用户，
也是软件开发和寻找资源的最佳途径，Github不只能够托管各类Git版本仓库，还拥有了更美观的Web界面，
您的代码文件能够被任何人克隆，使得开发者为开源项贡献代码变得更加容易，固然也能够付费购买私有库，
这样高性价比的私有库真的是帮助到了不少团队和企业。
具体使用方法见博客http://blog.oldboyedu.com/git/
https://blog.csdn.net/zy00000000001/article/details/70505150

Jenkins的使用

经过Jenkins把咱们的代码从远程仓库部署到测试环境，部署到生产环境，实现一个集成

将咱们的代码在它提交的那一刻到最后部署到生产环境的流程串起来。

jenkins简介：

JENKINS 是一个用 JAVA 编写的开源的持续集成工具。

在与 ORACLE 发生争执后，项目从 HUDSON 项目独立出来。

JENKINS 提供了软件开发的持续集成服务。

它运行在 SERVLET 容器中（例如 APACHE TOMCAT）。

它支持软件配置管理（SCM）工具（包括 ACCUREV SCM、CVS、SUBVERSION、 GIT、 PERFORCE、CLEARCASE 和 RTC），能够执行基于 APACHE ANT 和 APACHE MAVEN的项目，以及任意的 SHELL 脚本和 WINDOWS 批处理命令。JENKINS 的主要开发者是川口耕介。JENKINS 是在 MIT 许可证下发布的自由软件。
　　官方网站：https://jenkins.io/
　　清华镜像地址：https://mirrors.tuna.tsinghua.edu.cn/jenkins/

企业代码上线历史：

代码发布上线是每个 IT 企业必需要面临的，并且无论是对开发或者是运维来讲，代
码上线自己就是一个件很是痛苦的事情，不少时候每一次发布都是一次考验。为了提升上线
的效率，代码上线的方式，方法，工具也不断的发展，基本上能够分为如下几个阶段：
阶段 1-没有构建服务器
软件在开发者的机器上经过 Ant 或其它脚本手动构建，代码保存在中央源码仓库中，但
是开发者不是常常提交本地的修改。每次须要发布的时候，开发者手动合并修改，这个过程
是至关痛苦的。
阶段 2-晚上进行构建
在这个阶段，团队有构建服务器，自动化的构建在晚上进行。构建过程只是简单的编译
代码，没有可靠的和可重复的单元测试。然而，开发人员天天提交代码。若是某个开发人员
提的代码和其余人的代码冲突的话，构建服务器会在次日经过邮件通知团队。因此又一段
时间构建是处于失败状态的。
阶段 3-晚上进行构建并进行自动化测试
团队对 CI 和自动化测试愈来愈重视。不管何时版本管理系统中的代码改变了都会
触发编译构建过程，团队成员能够看到是代码中的什么改变触发了这个构建。而且，构建脚
本会编译应用而且会执行一系列的单元测试或集成测试。除了邮件，构建服务器还能够经过
其余方式通知团队成员，如：IM。失败的构建被快速的修复。
阶段 4-代码质量度量
自动化的代码质量和测试覆盖率的度量手段有助于评价代码的质量和测试的有效性。代
码质量的构建会产生 API 文档。
阶段 5-更加认真地对待测试
CI 和测试紧密相关。现在，像测试驱动开发被普遍地使用，使得对自动化的构建更加
有信心。应用不只仅是简单地编译和测试，而是若是测试成功会被自动的部署到一个应用服
务器上来进行更多的综合的 end-to-end 测试和性能测试。
阶段 6-验收测试和更加自动化的部署
验收测试驱动的开发被使用，使得咱们可以了解项目的状态。这些自动化的测试使用行
为驱动的开发和测试驱动的开发工具来做为交流和文档工具，发布非开发人员也能读懂的测
试结果报告。因为测试在开发的早起就已经被自动化的执行了，因此咱们能更加清楚地了解
到什么已经作了，什么尚未作。每当代码改变或晚上，应用被自动化地部署到测试环境中，
以供 QA 团队测试。当测试经过以后，软件的一个版本将被手工部署到生产环境中，团队也
老男孩IT教育能够在出现问题的时候回滚以前的发布。
阶段 7-持续部署
对自动化的单元测试，集成测试和验收测试的信心使得咱们能够使用自动化的部署技术
将软件直接部署到生产环境中。可是测试仍是有可能不能真正的反映现实的环境

Jenkins安装

环境准备

最小硬件需求：256M 内存、1G 磁盘空间，
一般根据须要 Jenkins 服务器至少 1G 内存，50G+磁盘空间。如果有编译型的任务，要设置高一点
软件需求：因为 jenkins 是使用 java 语言编写的，因此须要安装 java 运行时环境（jdk）
一、两台安装好Centos7.4系统的虚拟机，内存1G+
二、全部虚拟机的防火墙和SELinux关闭
三、主机名及IP地址关系以下：
Jenkins  10.0.0.64 不须要安装软件
Gitlab   10.0.0.63 在装好gitlab
四、Linux中能发邮件的帐号

获取安装包

能够从 Jenkins 官方网站及清华镜像站下载 jenkins 安装包，
也能够经过本教程配套的百度网盘下载对应的安装包
本次课程采用 jenkins-2.99 版本，jdk-8u121-linux-x64版本，
http://pkg.jenkins.io/redhat-stable/
https://mirrors.tuna.tsinghua.edu.cn/jenkins/redhat/
本次采用rpm，下载rpm包
或者从网盘下载

安装jdk

能够使用 YUM 方式安装安装 open JDK1.8 版本，也能够使用我提供的 rpm 安装，咱们课
程使用 RPM 方式安装
[root@jenkins src]# rpm -ivh jdk-8u121-linux-x64.rpm
Preparing...
################################# [100%]
Updating / installing...
1:jdk1.8.0_121-2000:1.8.0_121-fcs
################################# [100%]
Unpacking JAR files...
tools.jar...
plugin.jar...
javaws.jar...
deploy.jar...
rt.jar...
jsse.jar...
charsets.jar...
localedata.jar...
[root@jenkins src]# java -version
java version "1.8.0_121"
Java(TM) SE Runtime Environment (build 1.8.0_121-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.121-b13, mixed mode)

安装jenkins

[root@jenkins src]# rpm -ivh jenkins-2.99-1.1.noarch.rpm warning: jenkins-2.72-1.1.noarch.rpm: Header V4 DSA/SHA1 Signature, key ID d50582e6: NOKEY Preparing... ################################# [100%] Updating / installing... 1:jenkins-2.99-1.1 ################################# [100%]

启动、配置jenkins

[root@jenkins tools]# systemctl start jenkins
[root@jenkins tools]# systemctl status jenkins

Jenkins 默认监听 8080，服务启动后咱们能够在浏览器中输入 http://您服务器的 ip地址:8080 访问 jenkins 服务。

[root@jenkins tools]# cat /var/lib/jenkins/secrets/initialAdminPassword
db46467d9186489ba2298f3b99c62824

登录进去后，系统开始联网去加载插件，这是一个很漫长的过程。

若是等不住了，网络很差，就断掉网络。再开，进入插件安装界面

定制jenkins，须要安装插件，左边是安装经常使用插件，右边是本身选择安装。

本次两种方式都不用。由于安装起来很费时间，并且有的不必定会用。

因此，点右上角的X，进入下一步

点击按钮进入jenkins

为了方便修改一下密码

右上角admin------>设置------>修改密码123456

Jenkins插件管理

Jenkins 自己是一个引擎、一个框架，只是提供了很简单功能，

其强大的功能都是经过插件来实现的，

jenkins 有一个庞大的插件生态系统，为 Jenkins 提供丰富的功能扩展。

安装插件的方式

一、常规安装插件流程

（第一种方式）

主页------系统管理------管理插件------可选插件------勾选插件------安装

二、插件页面-----高级选项卡------设置代理（官网下载慢的时候）

三、插件页面-----高级选项卡------上传插件（下载好的）

（第二种方式）

去官网下载，或者去清华镜像

四、在安装好插件的Jenkins下，将插件目录打包，复制到新装的系统下的插件目录下------重启

（第三种方式）

Jenkins下，一切皆文件，没有数据库

覆盖插件目录

本次用作好的插件目录，覆盖咱们刚安装的目录

网盘中找到文件plugins.tar.gz上传到Linux系统中（/server/toos我仍是习惯放在这里）

包很大，221.67M，上传完毕，开始操做

tar xf plugins.tar.gz 
cd plugins/
mv * /var/lib/jenkins/plugins/

重启jenkins后，就安装好了

[root@jenkins plugins]# systemctl restart jenkins

在浏览器刷新，须要从新登陆，帐号admin，密码用刚刚从新设置的123456

登入以后，在已安装插件中，能够看到不少已经装好的插件，暂时都不要更新。

用这种安装方法的好处就是，不用一个一个的挑选和等待下载，节省不少时间，尤为是网络很差好的时候。

Jenkins经常使用目录及文件

学习 Jenkins，首先要明白一点，那就是 jenkins 下一切兼文件，

也就是说 jenkins 没有数据库，全部的数据都是以文件的形式存在，

因此要了解 Jenkins 的主要目录及文件，经过命令咱们能够查看到全部的 jenkins 目录及文件的位置

[root@jenkins plugins]# rpm -ql jenkins
/etc/init.d/jenkins            # 启动文件
/etc/logrotate.d/jenkins       # 日志相关
/etc/sysconfig/jenkins         # 主配置文件
/usr/lib/jenkins               
/usr/lib/jenkins/jenkins.war   # Jenkins 的主程序
/usr/sbin/rcjenkins
/var/cache/jenkins
/var/lib/jenkins               # 主目录
/var/log/jenkins               # 日志文件目录

Jenkins主配置文件

/etc/sysconfig/jenkins 是 Jenkins 的主配置文件：

咱们在这里主要配置 Jenkins 的工做目录、启动用户、启动端口。

若是要复制文件到新的系统中，复制前看一下文件和目录的权限，复制过去要修改权限

Jenkins 默认的用户为 jenkins，生产环境建议使用 jenkins 用户，而后使用 sudo 进行
受权，咱们实验学习过程为了不各类权限问题，改成 root 用户

Jenkins主目录

最重要的目录，若是要备份，就备份这个目录就好了，

/var/lib/jenkins 是 Jenkins 默认配置的主工做目录，咱们能够在主配置文件进行设置，其中主要的目录为

jobs 目录：存放 jobs 的配置及每次构建的结果；

plugins 目录：Jenkins 插件目录，存放咱们已经安装的插件；

worksspace：工做区目录，每次 job 执行构建时的工做目录，

users 目录：存放与用户相关的配置文件。

Jenkins主程序目录

/usr/lib/jenkins/jenkins.war 是 Jenkins 的主程序

若是之后要升级jenkins，简便的办法就是，把一个新的war包复制过来

而后重启，就行了

其余目录及文件

/var/log/Jenkins Jenkins 日志文件目录
/etc/init.d/Jenkins Jenkins 启动文件

Jenkins 建立freestyl项目

自由风格项目

构建做业是一个持续集成服务器的基本职能，构建做业的形式多种多样，

能够是编译和单元测试，也多是打包及部署，或者是其余相似的做业。

在 Jenkins 中，构建做业很容易创建，并且根据你的须要你能够安装各类插件，来建立多种形式构建做业，下面咱们先来学习建立自由式构建做业。
自由式的构建做业是灵活和可配置的选项，而且能够用于任何类型的项目，

0、新建Job

它的配置相对简单，其中不少配置在的选项也会用在其余构建做业中。
在 Jenkins 主页面，点击左侧菜单栏的“新建item”或者“New job”

须要注意：
1、job 名称须要有规划，以便于后面的权限管理；
2、建立 job 后不要轻易更更名称，由于 jenkins 一切皆文件，
不少关于 job 的文件，都是以该名称命名，当你更名后，通常不会删除旧文件，
而是会再从新建立一份新的文件。

输入 job 名称，选择类型后，点击 OK 后建立 job，进入 job 配置页面，此时在 Jenkins
的主目录下的 jobs 目录已经生成了以你 Job 名称命名的文件夹

一、执行Linux命令、脚本

完成建立，进入配置页面，在命令行看下job下生成了什么

[root@jenkins jenkins]# cd jobs/
[root@jenkins jobs]# ll
total 0
drwxr-xr-x 3 jenkins jenkins 38 Mar 20 20:30 My-free-Style-job
[root@jenkins jobs]# cd My-free-Style-job/
[root@jenkins My-free-Style-job]# ll
total 4
drwxr-xr-x 2 jenkins jenkins  23 Mar 20 20:30 builds
-rw------- 1 jenkins jenkins 468 Mar 20 20:30 config.xml

勾选“丢弃旧的构建”，这是咱们必须提早考虑的重要方面，
就是咱们如何处理构建历史，构建做业会消耗大理的磁盘空间，
尤为是你存储的构建产物（好比执行 java 构建时会生成的 JAR、WAR 等）

该选项容许你限制在构建历史记录的做业数。你能够告诉 Jenkins 只保留近的几回构建，
或者只保留指定数量的构建，此外，Jenkins 永远不会删除后一个稳定和成功的构建。
具体数据的指定要根据你项目的实际状况而定，我通常设置为 五、5，

源代码，暂时不讲

构建触发器，就是怎么来触发构建，能够设置自动，后面再继续

构建环境，后面说

构建，他能作什么操做，取决于你安装了什么样的插件，执行相应功能的构建操做

本次选择构建执行脚本，选择execute shell

输入一个简单的命令，先看一下效果和目录作了哪些改变

构建后操做，先不作配置

点击保存！回到主页面

点击“当即构建”，执行 job 的构建任务，咱们的 job 就是执行一条 linux 命令

点击下拉菜单的“console output”在上面的控制台输出内容中，

咱们能够看到 job 执行时的当前工做目录为 Jenkins 主目录+workspaces+以 job 名称命名的文件夹，知道这一点对于咱们后面写脚本执行部署任务时很是重要。

咱们也能够经过命令行进行确认，在目录下多了一个workspace

[root@jenkins jenkins]# cd workspace/
[root@jenkins workspace]# ll
total 0
drwxr-xr-x 2 jenkins jenkins 6 Mar 20 20:58 My-free-Style-job
[root@jenkins workspace]# cd My-free-Style-job/
[root@jenkins My-free-Style-job]# ll
total 0   目录下是空的，由于没有作其余操做，

在jobs下也多了不少东西，构建的内容、历史等都在里面生成了

并且咱们进一步也能够看到 job 主页面，工做空间所对应的位置也是此目录。

咱们再构建中添加一条建立文件的命令，并观察变化

在建立以后，咱们点击工做空间，会看到多了一个文件，就是咱们刚刚建立的

经过这个例子，咱们能够联想到，咱们能够使用 Jenkins 执行任何 linux 命令，

这也就是咱们前面讲的要注意 Jenkins 启动用户的配置，

若是是 root 用户启动的 Jenknis，那 Jenkins 的安全及权限配置必定要作好控制。

咱们在学习初期，为了节省时间，能够使用 root 用户启动jenkins。

连接gitlab获取仓库代码

一、在10.0.0.63（GitLab）服务器上，倒入了一个完整的项目，如今是有组、用户、项目代码

　　经过的URL导入在码云上找的Html代码项目（用的https）

二、在10.0.0.64（Jenkins）服务器上，作好了一个Job

接下来，将gitlab上的代码拉取到jenkins上

开始复制到jenkins的job中的源码管理中

由于咱们使用的 SSH 方式链接仓库，因此须要配置SSH 认证，这台机子的 root用户的公钥在 Gitlab 上的 dev 用户，为何咱们这里还须要认证？下面咱们来查看一下Jenkins 服务的启动用户，咱们已经改为root了（/etc/sysconfig/jenkins）

jenkins是以root用户启动的，咱们须要在jenkins上使用root用户建立秘钥，配置在gitlab上就能打通，或者当jenkins是以jenkins的user启动的，咱们就须要在jenkins上使用jenkins建立秘钥，配置在gitlab上。

在咱们使用了root用户配置完以后，再实验jenkins用户的时候，会报错！

经过排除和查看目录，发现，在咱们设置为root用户后，config.xml的权限变成了root.root

因此在切换回jenkins以后，会报错，在日志中显示，没有访问config.xml的权限

将文件权限修改为jenkins.jenkins就能够了

而后还有一点问题，root用户的公钥已经不能用了，这个时候，在管理页面添加私钥证书，去和gitlab上的公钥配对

OK！基本上在配置的时候后，就这两种错误！

设置完拉取分支，而后保存！！

也能够用commit ID拉取

可是，咱们在一个job下频繁的修改用户，会致使错误，由于jenkins没法操做root用户的文件

最好不要这么操做！

最后，执行如下当即构建，代码就会被拉到工做目录下！

利用linux脚本实现部署

配置文件的变动

通常咱们在获取源代码之后，要对源代码作一些配置。把源代码发到咱们对应的环境里面去。

有一些最基本的操做，研发、测试、生产环境的配置文件都是不同的。

最适合方法：把测试、生产环境正确的测试文件，保存一份在Linux某个文件中，或者保存在仓库上，建议最好也放在git上，这样每次更改都会有记录。

而后，在jenkins中再建立一个job拉取配置文件。

写一个脚本，把正确的文件覆盖源代码中的配置文件。

怎么发送到服务器上

是打一个包，仍是，scp * ，一个文件一个文件。

为了节省性能，节省IO，网络IO/磁盘IO。因此要打包发送，并且，压缩后的文件更小，可是节省IO才是最重要的。

发布时使用软链接，不要复制，黏贴

由于，省时间

安装httpd服务

在一台服务器上安装apache

[root@xiaodao ~]# yum install -y http

配置ssh免密登录

由于咱们要使用脚本将 jenkins 上的程序代码推送到 web-01服务器上，因此须要配置jenkins 到 web-011的 ssh 免密码登陆。（）

httpd也安装在了gitlab上，将配置文件（/etc/httpd/conf/httpd.conf ）中的listen 改成 8808，避免冲突

[root@jenkins ~]# ssh-copy-id -i /root/.ssh/id_rsa.pub root@10.0.0.63

编写部署脚本

流程是这样的：

一、拿到源码，处理配置文件，图片等....

二、打包

三、发到目标服务器（apache的默认网站目录在/var/www/html下）

四、解包

五、使用软链接的方式发布

注意：在咱们屡次提交后，会覆盖以前发送过来的包，须要采用迭代的方式，

[root@jenkins /server/tools]# vim deploy.sh
#!/bin/bash
# 定义文件名，造成迭代文件名
web_name=web-$(date -%F)-(($RANDOM)+10000)
# 定义web服务器名，作一个通用的脚本
host=$1
# 工做目录的名字，以区分推送不一样的项目，作一个通用的脚本
job_name=$2
# 切换到源码目录下，打包
cd  /var/lib/jenkins/workspace/$(job_name) && tar czf /opt/$(web_name).tar.gz ./*
# ssh到远程主机，切换到www目录，建立源码目录
ssh $(host) "cd /var/www && mkdir $(name)"
# 将源码发送到远程主机
scp /opt/$(web_name).tar.gz $(host):/var/www/$(web_name)
# ssh远程主机，切换到项目源码目录下，
ssh $(name) "cd /var/www/$(web_name) && tar xf $(web_name).tar.gz && rm -f $(name).t
ar.gz"
# 作软链接，删除原来的html软链接
ssh $(name) "cd /var/www && rm -rf html && ln -s /var/www/$(name) /var/www/html"

~                                                                                   
"deploy.sh" 18L, 839C written

Jenkins 配置构建

在配置中，写入命令

或者能够直接调用jenkins的全局变量

保存，而后执行当即构建

编写脚本的时候必定要细心，注意语法和关键字

访问10.0.0.63:8808 ，成功构建

Git push触发自动构建

在上面的 job 中，咱们已经成功实现了将 Gitlab 中 monitor 仓库的代码部署到 httpd服务中，可是每次部署须要咱们手动去点击“当即构建”，下面咱们将实现当 Gitlab 收到push 请求后，就触发 Jenkins 构建，将仓库的变化部署到 httpd 服务中。

Jenkins job 配置构建触发器

回到 My-freestyle-job 的配置页面，下拉到构建触发器部分

选择Build when a change is pushed to GitLab. GitLab CI Service URL: http://10.0.0.64:8080/project/My-free-Style-job

点右下角的高级

完成，保存

Gitlab仓库配置webhooks

进入 Gitlab 中咱们的源码仓库的设置页面，

点击Settings---Intergrations

点击最下面的 Add webhooks，完成配置。

能够测试一下最下面的test选项，咱们在 jenkins job 主页面看到构建任务被触发。

接着咱们将仓库克隆到客户端，在客户端测试触发 push 操做

Gitlab 收到本次推送的内容，

Jenkins 对应的 job 已经触发构建。

网站 index.html 内容被更新

同时咱们在 jenkins 中 job 主页面的“最新修改记录”部分能够看到咱们的修改日志。

小公司的测试和审批可能没有那么完善和高效，因此自动上线，最好不要在生产环境中使用，必定要人工介入。保证没有问题

配置构建后操做

构建完成后，jenkins 能够把构建的结果反馈给 Gitlab，这样在 Gitlab 上就能够查看每一次 push 后构建的执行结果。

首先在 Jenkins 上配置，能够访问 Gitlab，打开 jenkins 系统管理系统设置页面，下拉找到 Gitlab 部分，

配置构建后通知Gitlab

Jenkins首页------系统设置------系统设置（右边栏第一个）------往下拉，找到Gitlab

添加认证，这个认证呢，是为了访问10.0.0.63上面的gitlab的

在Gitlab的Usersttings------Access Token------建立token

将得到的token，复制，帖到jenkins的指定位置

ID：gitlab

Discription：gitlab

添加，完成

而后下面有一个测试按钮，点击，Success！

保存！

jenkins的Job配置下增长构建后操做

保存，执行试验一下，构建后查看gitlab是否是收到状态通知

这样，咱们就能够在gitlib中看到构建状态，点击绿钩就能够更多状态信息

会直接链接到jenkins中，

不用在登录jenkins去查看了

配置构建发送邮件

每次执行完构建任务后，咱们均可以经过邮件来通知相关人员构建的执行状况，具体配置以下：
全局配置
在 jenkins 系统管理—>系统设置，
在系统设置中找到 Jenkins Locaction 填好 JenkinsURL 跟系统管理员的邮件地址，注意必填。

下拉到最下面“邮件通知”部分，

注一、邮箱跟最开始设置的管理员邮箱是一致的，二、密码根据您使用的邮箱进行设置，16三、QQ 邮箱，都使用受权码，而不是您的邮件密码。

成功！咱们能够收到测试的邮件

Job 邮件配置
进入 job 配置页面，下拉至构建后操做部分，选择两项中的一项

　　一、选择E-mail Notifacation

　　二、Editable E-mail Notifacation

E-mail Notification 选项配置比较简单

当构建失败后，会发邮件通知

Editable Email Notification 配置

Jenkins建立Maven项目

什么是Mavenue

Maven 是一个项目管理和综合工具。

Maven 提供了开发人员构建一个完整的生命周期框架。

开发团队能够自动完成项目的基础工具建设，Maven 使用标准的目录结构和默认构建生命周期。

Maven 简化和标准化项目建设过程。处理编译，分配，文档，团队协做和其余任务的无缝链接。

Maven 增长可重用性并负责创建相关的任务。

Maven 项目的结构和内容在一个 XML 文件中声明，pom.xml 项目对象模型（POM），这是整个 Maven 系统的基本单元。

用来管理项目的构建，相关性和文档。最强大的功能就是可以自动下载项目依赖库。

推荐书名《Maven时代》-徐小斌做品

真的要使用Maven，应该是，首先要在Linux命令行下就行执行和使用。

Jenkins只是插件式的用工具调用本地的Maven

Centos7下安装Maven

安装JDK

此时已安装好，就在安装jenkins的服务器上安装

获取Maven安装文件

官网：http://maven.apache.org/download.cgi
清华镜像：https://mirrors.tuna.tsinghua.edu.cn/apache/maven/
[root@jenkins ~]# cd /server/tools/
[root@jenkins /server/tools]# wget https://mirrors.tuna.tsinghua.edu.cn/apache/maven/maven-3/3.3.9/binaries/apache-maven-3.3.9-bin.tar.gz

安装MVen

下载的是一个二进制文件包，解压后直接使用的

[root@jenkins /server/tools]# tar xf apache-maven-3.3.9-bin.tar.gz     
[root@jenkins /server/tools]# mv apache-maven-3.3.9 /application/
[root@jenkins /application]# ln -s /application/apache-maven-3.3.9/ /application/maven
[root@jenkins /application]# /application/maven/bin/mvn -v    执行命令，查看maven版本
Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-11T00:41:47+08:00)
Maven home: /application/maven
Java version: 1.8.0_121, vendor: Oracle Corporation
Java home: /usr/java/jdk1.8.0_121/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "3.10.0-693.el7.x86_64", arch: "amd64", family: "unix"

配置Maven

编辑 /etc/profile 文件，在末尾添加 export PATH=/usr/local/apache-maven-3.3.9/bin/:$PATH ，将 maven 命令加入系统环境变量。而后就能够直接使用mvn了

[root@jenkins /application]# source /etc/profile
[root@jenkins /application]# mvn -v
Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-11T00:41:47+08:00)
Maven home: /application/apache-maven-3.3.9
Java version: 1.8.0_121, vendor: Oracle Corporation
Java home: /usr/java/jdk1.8.0_121/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "3.10.0-693.el7.x86_64", arch: "amd64", family: "unix"

认识Maven安装目录

安装完成后，maven 的安装目录结构以下：

[root@jenkins /application/maven]# ll
total 32
drwxr-xr-x 2 root root    97 Mar 24 06:17 bin
drwxr-xr-x 2 root root    42 Mar 24 06:17 boot
drwxr-xr-x 3 root root    63 Nov 11  2015 conf
drwxr-xr-x 3 root root  4096 Mar 24 06:17 lib
-rw-r--r-- 1 root root 19335 Nov 11  2015 LICENSE
-rw-r--r-- 1 root root   182 Nov 11  2015 NOTICE
-rw-r--r-- 1 root root  2541 Nov 11  2015 README.txt

bin:该目录包含了 mvn 运行的脚本，这些脚本用来配置 java 命令，准备好 classpath
和相关的 Java 系统属性，而后执行 Java 命令。其中 mvn 是基于 Linux 平台的脚本，mvn.bat或者mvn.cmd是基于 Windows 平台的脚本。m2.conf 是配置m2目录
boot：该目录只包含一个文件，该文件是一个类加载器框架，Maven 使用该框架加载自己的类库。
conf：该目录包含了一个很是重要的文件 settings.xml。用于全局定义 Maven 的行为。也能够将该文件复制到~/.m2/目录下，在用户范围内定制 Maven 行为。
Lib：该目录包含了全部 Maven 运行时须要的 Java 类库。

经常使用maven命令

网盘中准备了一个Hello world项目，上传

首先咱们建立一个名为 hello-world 的 Maven 项目，项目的目录结构以下

[root@jenkins /server/tools/hello-world]# tree .
.
├── pom.xml  是一个对象模型，全部项目的配置都在里面，若无此，将没法构建
└── src
    ├── main
    │   └── java
    │       └── com
    │           └── juvenxu
    │               └── mvnbook
    │                   └── helloworld
    │                       └── HelloWorld.java
    └── test
        └── java
            └── com
                └── juvenxu
                    └── mvnbook
                        └── helloworld
                            └── HelloWorldTest.java

13 directories, 3 files

咱们在此项目的基本上测试经常使用的 maven 命令
mvn clean 命令用于清理项目生产的临时文件，通常是模块下的 target 目录

mvn package 在项目根目录下执行命令用于项目打包，会在模块下的 target 目录生成 jar 或者 war 等文件。他会自动去找依赖包，先去m2仓库找，再去中心仓库找，后面讲创建私库。找到以来文件开始下载，保存在了根目录下的target下，

[root@jenkins /server/tools/hello-world/target]# ll
total 8
drwxr-xr-x 3 root root   17 Mar 24 07:05 classes    
-rw-r--r-- 1 root root 3129 Mar 24 07:07 hello-world-1.0-SNAPSHOT.jar  jar包是能执行的
drwxr-xr-x 2 root root   28 Mar 24 07:07 maven-archiver
drwxr-xr-x 3 root root   35 Mar 24 07:04 maven-status
-rw-r--r-- 1 root root 2871 Mar 24 07:07 original-hello-world-1.0-SNAPSHOT.jar
drwxr-xr-x 2 root root  125 Mar 24 07:06 surefire-reports
drwxr-xr-x 3 root root   17 Mar 24 07:05 test-classes  测试的结果

mvn test 命令用于测试，用于执行src/test/java/ 下的测试用例，

使用-Dmaven.test.skip=true参数能够跳过测试。

mvn install 命令用于模块安装，将打包好的 jar/war 文件复制到你的本地仓库中，供其余模块使用

mvn deploy 用于部署到m2本地文件

Maven仓库

在 Maven 中，任何一个依赖、插件或者项目构建的输出，均可以称之为构件。

Maven 在某个统一的位置存储全部项目的共享的构件，这个统一的位置，咱们就称之为仓库。（仓库就是存放依赖和插件的地方）任何的构件都有惟一的坐标，Maven 根据这个坐标定义了构件
在仓库中的惟一存储路径。
Maven 仓库分为两类：本地仓库和远程仓库。

远程仓库又能够大体分为如下三类：

中央仓库，这是 Maven 核心自带的远程仓库，它包含了绝大部分开源的构件；

私服是一种特殊的远程仓库，通常是为了节省带宽和时间，在企业局域网内架设的一个私有仓库服务器（如nexus）用其代理全部外部的远程仓库，内部的项目还能够部署到私服上供其余项目使用；
还有就是其余的公开的远程仓库，常见的有 Java.net Maven 库、JBoss Maven 库等。

默认配置下，Maven 根据坐标寻找构件的时候，首先他会查看本地仓库，

若是本地仓库存在，则直接使用；

若是本地仓库不存在，则 Maven 就会去远程仓库查找，

存在则先下载到本地仓库使用，不存在 Maven 就会报错。

本地仓库

顾名思义，就是 Maven 在本地存储构件的地方。

maven 的本地仓库，在安装 maven 后并不会建立，它是在第一次执行 maven 命令的时候才被建立。

maven 本地仓库的默认位置：不管是 Windows 仍是 Linux，在用户的目录下都有一个.m2/repository/的仓库目录，这就是Maven 仓库的默认位置。

这个能够经过修改.m2/settings.xml 文件（不存在能够建立）或者maven 安装目录/conf/settings.xml 进行配置。
在 settings.xml 文件中，设置 localRepository 元素的值为想的仓库地址便可

<settings>
    <localRepository>/opt/maven_repository</localRepository>
</settings>

经过咱们建议修改.m2 目录下的 setting.xml 文件，修改只针对用户。

远程仓库

说到远程仓库先从最核心的中央仓库开始，中央仓库是默认的远程仓库，

maven 在安装的时候，自带的就是中央仓库的配置，全部的 maven 项目都会继承超级 pom，具体的说，包
含了下面配置的 pom 咱们就称之为超级 pom

<repositories> <repository> <id>central</id> <name>Central Repository</name> <url>http://repo.maven.apache.org/maven2</url> <layout>default</layout> <snapshots> <enabled>false</enabled> </snapshots> </repository>

中央仓库包含了绝大多数流行的开源 Java 构件，以及源码、做者信息、SCM、信息、许可证信息等。

通常来讲，简单的 Java 项目依赖的构件均可以在这里下载获得。
私服是一种特殊的远程仓库，它是架设在局域网内的仓库服务，私服代理广域网上的远程仓库，供局域网内的 Maven 用户使用。当 Maven 须要下载构件的时候，它从私服请求，若是私服上不存在该构件，则从外部的远程仓库下载，缓存在私服上以后，再为 Maven 的下载请求提供服务。咱们还能够把一些没法从外部仓库下载到的构件上传到私服上。
Maven 私服的个特性：
1.节省本身的外网带宽：减小重复请求形成的外网带宽消耗
2.加速 Maven 构件：若是项目配置了不少外部远程仓库的时候，构建速度就会大大下降
3.部署第三方构件：有些构件没法从外部仓库得到的时候，咱们能够把这些构件部署到内部仓库(私服)中，供内部 maven 项目使用
4.提升稳定性，加强控制：Internet 不稳定的时候，maven 构建也会变的不稳定，一些私服软件还提供了其余的功能
5.下降中央仓库的负荷：maven 中央仓库被请求的数量是巨大的，配置私服也能够大大下降中央仓库的压力
当前主流的 maven 私服：1.Apache 的 Archiva、2.JFrog 的 Artifactory、3.Sonatype的 Nexus

配置使用远程仓库

在平时的开发中，咱们每每不会使用默认的中央仓库，默认的中央仓库访问的速度比较慢，访问的人或许不少，有时候也没法知足咱们项目的需求，可能项目须要的某些构件中央仓库中是没有的，而在其余远程仓库中有，如 JBoss Maven 仓库。

这时，能够在 pom.xml中配置该仓库，代码以下：

<!-- 配置远程仓库 -->
<repositories>
　　<repository>
　　　　<id>jboss</id>
　　　　<name>JBoss Repository</name>
　　　　<url>http://repository.jboss.com/maven2/</url>　　
　　<releases>
　　　　<enabled>true</enabled>
　　　　<updatePolicy>daily</updatePolicy>
　　</releases>
　　<snapshots>
　　　　<enabled>false</enabled>
　　　　<checksumPolicy>warn</checksumPolicy>
　　</snapshots>
　　<layout>default</layout>
　　</repository>
</repositories>

repository：在 repositories 元素下，能够使用 repository 子元素声明一个或者多个远程仓库。
id：仓库声明的惟一 id，尤为须要注意的是，Maven 自带的中央仓库使用的 id 为 central，若是其余仓库声明也使用该 id，就会覆盖中央仓库的配置。
name：仓库的名称，让咱们直观方便的知道仓库是哪一个，暂时没发现其余太大的含义。
url：指向了仓库的地址，通常来讲，该地址都基于 http 协议，Maven 用户均可以在浏览器中打开仓库地址浏览构件。
releases 和 snapshots：用来控制 Maven 对于发布版构件和快照版构件的下载权限。须要注意的是 enabled 子元素，该例中 releases 的 enabled 值为 true，表示开启 JBoss 仓库的发布版本下载支持而　　snapshots 的 enabled 值为 false，表示关闭 JBoss 仓库的快照版本的下载支持。根据该配置，Maven 只会从 JBoss 仓库下载发布版的构件，而不会下载快照版的构件。
layout：元素值 default表示仓库的布局是 Maven2及 Maven3的默认布局，而不是 Maven1的布局。基本不会用到 Maven1 的布局。
其余：对于 releases 和 snapshots 来讲，除了 enabled，它们还包含另外两个子元素updatePolicy 和 checksumPolicy。

　　元素 updatePolicy 用来配置 Maven 从远处仓库检查更新的频率，默认值是 daily，表示 Maven 天天检查一次。

　　其余可用的值包括：never-从不检查更新；always-每次构建都检查更新；interval：X-每隔 X 分钟检查一次更新（X 为任意整数）。
　　元素 checksumPolicy 用来配置 Maven 检查校验和文件的策略。当构建被部署到 Maven仓库中时，会同时部署对应的检验和文件。在下载构件的时候，Maven 会验证校验和文件，若是校验和验证失　　败，当 checksumPolicy 的值为默认的 warn 时，Maven 会在执行构建时输出警告信息，其余可用的值包括：fail-Maven 遇到校验和错误就让构建失败；ignore-使Maven 彻底忽略校验和错误

利用Nexus搭建私有Maven库

Nexus介绍

Nexus 是一个强大的 Maven 仓库管理器，它极大地简化了本地内部仓库的维护和外部仓库的访问。
Nexus 在代理远程仓库的同时维护本地仓库，以下降中央仓库的负荷,节省外网带宽和时间。
Nexus 是一套“开箱即用”的系统不须要数据库，它使用文件系统加 Lucene 来组织数据。
Nexus 使用 ExtJS 来开发界面，利用 Restlet 来提供完整的 REST APIs，经过 m2eclipse与 Eclipse 集成使用。
Nexus 支持 WebDAV 与 LDAP 安全身份认证。
Nexus 还提供了强大的仓库管理功能，构件搜索功能，它基于 REST，友好的 UI 是一个extjs 的REST 客户端，它占用较少的内存，基于简单文件系统而非数据库

安装JDK

最好安装在单独的服务器上，效率高，传输快，不受其余服务的影响。

建立新的虚拟机10.0.0.65 nexus

获取Nexus安装包

下载地址：https://www.sonatype.com/download-oss-sonatype

访问连接找到Unix/Linux的版本，右键复制连接，使用 wget命令下载便可

安装Nexus

软件包解压后便可使用

解压后会有两个项目

drwxr-xr-x 9 root root       163 Mar 25 03:29 nexus-3.13.0-01

drwxr-xr-x 3 root root        20 Mar 25 03:30 sonatype-work

将文件移动到自定义安装软件的目录，我习惯的是 /application下

作软链接

ln -s /application/nexus-3.13.0-01/ /application/nexus

启动nexus

[root@jenkins /application/nexus]# bin/nexus start
WARNING: ************************************************************
WARNING: Detected execution as "root" user.  This is NOT recommended!
WARNING: ************************************************************
Starting nexus

也能够使用run，能在屏幕输出过程

上面启动成功后会警告不要使用 root 用户启动，这里能够新建一个用户，也能够指定root 用户启动，使他不出现警告，下面配置指定 root 用户启动,编辑 bin 目录下的 nexus.rc文件，

修改内容为：run_as_user="root"

默认的端口是8081

默认的帐号密码时admin；admin123

配置Maven项目使用Nexus仓库

在 maven 的 setting.xml 文件中配置私服配置，这种方式配置后，全部本地使用该配置的maven 项目的 pom 文件都无需配置私服下载相关配置
在<profiles></profiles>之间加入下面的配置

<profile>
　　<id>my-nexus</id>
　　<repositories>
　　<!-- 私有库地址-->
　　　　<repository>
　　　　　　<id>nexus</id>
　　　　　　<name>nexus</name>
　　　　　　<url>http://10.0.0.65:8081/repository/maven-public/</url>
　　　　　　<snapshots> 快照库
　　　　　　　　<enabled>true</enabled>
　　　　　　</snapshots>
　　　　　　<releases> 版本库
　　　　　　　　<enabled>true</enabled>
　　　　　　</releases>
　　　　</repository>
　　</repositories>
　　<pluginRepositories>
　　<!--插件库地址-->
　　　　<pluginRepository>
　　　　<id>nexus</id>
　　　　<url>http://10.0.0.65:8081/repository/maven-public/</url>
　　　　<releases>
　　　　　　<enabled>true</enabled>
　　　　</releases>
　　　　<snapshots>
　　　　　　<enabled>true</enabled>
　　　　</snapshots>
　　　　</pluginRepository>
　　</pluginRepositories>
</profile>

在<settings></settings>之间加入下面的配置，激活启用使用上面的配置

<activeProfiles>
    <activeProfile>my-neuxs</activeProfile>
</activeProfiles>

注：profile 名字要对应

在<mirros></mirros>镜像之间加入以下配置

<mirror>
　　<id>nexus-myself</id>
　　<!--*指的是访问任何仓库都使用咱们的私服-->
　　<mirrorOf>*</mirrorOf>
　　<name>Nexus myself</name>
　　<url>http://10.0.0.65:8081/repository/maven-public/</url>
</mirror>

配置完成后，删除原来的m2后，当咱们再次执行 mvn 命令时，下载构件的地址变为咱们的私服地址

咱们的私服也缓存了相应的构件在本地

建立Maven Job

一、在 Gitlab 建立一个 java 的代码仓库，咱们把前面在命令使用的 helloword 项目初始化为一个 git 仓库，而后 push 到咱们的 Gitlab 上（具体方法请参考前面相关内容）。

二、在 jenkins 配置 maven：打开系统管理—>全局工具配置页面，下拉新增一个 maven 配置。

二、回到 Jenkins 主页面，点击“新建 Item”进入建立 Job 页面，

三、输入 Job 名称，选择 maven 类型，点击确认按钮，建立 job，进入 job 配置页面，

通用部分配置“丢弃旧的构建”

源码管理配置从 git 仓库获取咱们 helloword 仓库的代码

配置输入要执行的 maven 命令，保存配置，返回 job 主页面，执行构建。

在“工做空间”咱们能够看到构建后的产物。

Jenkins 建立Popeline项目

Jenkins Pipeline简介

Jenkins pipeline 是 Jenkins 2.0 的精髓，

是帮助 Jenkins 实现 CI 到 CD 转变的重要角色。

简单来讲，就是一套运行于 Jenkins 上的工做流框架，

将本来独立运行于单个或者多个节点的任务链接起来，实现单个任务难以完成的复杂发布流程。

Pipeline 的实现方式是一套 Groovy DSL，任何发布流程均可以表述为一段 Groovy 脚本，

而且 Jenkins 支持从代码库直接读取脚本，从而实现了 Pipeline as Code 的理念。

Pipeline的基本概念和Jenkinsfile

Pipeline的几个基本概念

Node：一个 Node 就是一个 Jenkins 节点，能够是 Master，也能够是 Slave，是 Pipeline中具体 Step 的运行环境。
Stage：一个 Pipeline 有多个 Stage（阶段）组成，每一个 Stage 包含一组 Step。注意一个 Stage能够跨多个 Node 执行，即 Stage 其实是 Step 的逻辑分组。
Step：是最基本的运行单元，能够是建立一个目录、从代码库中 checkout 代码、执行一个 shell 命令、构建 Docker 镜像、将服务发布到 Kubernetes 集群中。Step 由 Jenkins和 Jenkins 各类插件提供。

Jenkinsfile 语法

Jenkins Pipeline 支持两种语法，

一种 Declarative Pipeline(声明式)，

一种 ScriptedPipeline(脚本式)。

声明式的 Pipeline 限制用户使用严格的预选定义的结构，是一种声明式的编程模型，对比脚本式的 Pipeline 学习起来更加简单；

脚本式的 Pipeline 限制比较少，结构和语法的限制由 Groovy 自己决定，是一种命令式的编程模型。

因此咱们学习使用声明式的方式编写 jenkinsfile。通常来讲 jenkinsfile 会被放在代码库的根目录下。固然也能够在 Web 页面定义。下面是两种不一样方式的 jenkinsfile 示例
Jenkinsfile (声明式)

pipeline {
　　agent any 紧跟着，必须是它，any指定节点
　　
　　stages {
　　　　stage('Build') {
　　　　　　steps {
　　　　　　　　echo 'Building..'
　　　　　　}
　　　　}
　　stage('Test') {
　　　　steps {
　　　　　　echo 'Testing..'
　　　　}
　　}　　　　
　　stage('Deploy') {
　　　　steps {
　　　　　　echo 'Deploying....'
　　　　}
　　}
　　}
}

前面咱们说过，声明式的 Pipeline 有严格的预约义格式结构，

最外层必须是 pipeline{},紧接着是 agent 指示 Jenkins 分配一个执行器和工做空间来执行下面的 Pipeline,

stages和 steps 是声明式 Jenkinsfile 必须的，全部的 stage 必需要定义在 stages 里，

每个 stage下的 step 要定义在一个 steps 里
Jenkinsfile (脚本式)

node {
　　stage('Build') {
　　//
　　}
　　stage('Test') {
　　//
　　}
　　stage('Deploy') {
　　//
　　}
}

在脚本式 jenkinsfile 里，你能够定义一个 node 或者多个 node 块，而后在 node 块里定义你的stage，在 stage 里定义你的 step 便可。

Pipeline Job示例

经过web页面建立爱你jenkinsfile

一、登陆到 jenkins 主页面，点击左侧菜单栏的 New Item 新建项目

二、进入到新建 Job 页面，输入 job 名称，在下面选择 Pipeline 类型，而后点击 OK。

三、打开 Pipeline 配置页面，点 Pipeline 选项卡，下拉到 pipeline （流水线）部分，选择 pipeline script，在页面定义 jenkinsfile 的方式，在脚本框输入下面的内容。

pipeline {
　　agent any
　　stages {
　　　　stage('Stage 1') {
　　　　　　steps {
　　　　　　　　echo 'Hello world!'
　　　　　　}
　　　　}
　　}
}

保存后回到 Job 主页面，点击“当即构建”，
四、构建执行完成后，在页面的右侧以图形的形式显示 pipeline 的结构，点击对应的位置能够查看构建执行的状况。
五、在构建历史处，点击#1 查看此次构建的运行状况，点击“console output”能够看到 Pipeline 的详细运行状况。

经过scm获取jenkinsfile

一、首先咱们在 gitlab 上的 monitor 仓库的根目录下建立一个 Jenkins 文件，文件的内容为：

pipeline {
　　agent any
　　stages {
　　　　stage('Stage 1') {
　　　　steps {
　　　　　　echo 'Hello world!'
　　　　　　　}
　　　　　}
　　}
}

二、接着咱们在 Jenkins 新建一个 pipeline job，命名为 My-pipeline-job01,前 2 步，同上一个示例同样，在 My-pipeline-job01 的配置页面，点击 Pipeline 选项卡，下拉到pipeline 部分，选择从 scm 获取 pipeline script，
三、进入到 scm 配置页面，选择从 git 仓库获取
四、进入到 git 仓库配置页面，输入仓库地址，配置认证，选择分支等，而后点击保存。
五、保存配置后，回到 Job 主页面，执行“当即构件”，在”console output”中，咱们能够看到，首先从 gitlab 仓库获取了全部的代码文件，而后识别到jenkins文件，执行文件中定义的构建任务。

Pipeline 语法生成器

不用本身写语法。

随着 Pipeline 一块儿发布的内建的文档，使得建立复杂的 Pipelines 更加容易。内建的文档能够根据安装在 Jenkins 实例中的插件，被自动生成和更新。

内建的文档能够经过连接被找到: localhost:8080/pipeline-syntax/。

假设你已经有了一个正运行在本地 8080 端口上的实例。一样的文档能够链接到这里，经过任何项目的左边菜单”Pipeline Syntax” 。

语法生成器是动态填充的，其中列出了可供 jenkins 使用的步骤，可用的步骤取决于安装的插件。
使用语法生成器生成步骤：
一、打开 Pipeline Syntax 。

二、在“示例步骤”下拉菜单中，选择须要的步骤。

包含了构建过程全部的

三、输入所选择步骤须要的参数信息

四、点击“生成流水线脚本”生成脚本

使用Pipe实现monitor代码仓库的发布

一、在 Gitlab 在 monitor 仓库的根目录上添加 Jenkinsfile 文件，文件内容以下：

pipeline {
　　agent any
　　stages {
　　　　stage('replace file') {
　　　　　　steps {
　　　　　　　　echo "replace config file use cp "
　　　　　　}
　　　　}
　　　　stage('test') {
　　　　　　steps {
　　　　　　　　echo "unit test "
　　　　　　}
　　　　}
　　　　stage('package') {
　　　　　　steps {
　　　　　　　　sh 'tar czf /opt/web-${BUILD_ID}.tar.gz ./* --exclude=./git --exclude=Jenkinsfile'
　　　　　　}
　　　　}
　　　　stage('deploy') {
　　　　　　steps {
　　　　　　　　sh 'ssh 10.0.0.11 "cd /var/www && mkdir web-${BUILD_ID}"'
　　　　　　　　sh 'scp /opt/web-${BUILD_ID}.tar.gz 10.0.0.11:/var/www/web-${BUILD_ID}'
　　　　　　　　sh 'ssh 10.0.0.11 "cd /var/www/web-${BUILD_ID} && tar xf web-${BUILD_ID}.tar.gz &&rm -f web-${BUILD_ID}.tar.gz"'
　　　　　　　　sh 'ssh 10.0.0.11 "cd /var/www && rm -rf html && ln -s /var/www/web-${BUILD_ID}" /var/www/html'
　　　　　　}
　　　　}　　
　　　　stage('test') {
　　　　　　steps {
　　　　　　　　echo "deploy after test "
　　　　　　}
　　　　}
　　}
}

此 jenkinsfile 包括五个 stage，分为 replace file、test、package、deploy，对于非编译项目，咱们通常包括这五个阶段。
二、在 jenkins 上建立一新的 Job，job 名称为 monitor-web，类型为 pipeline，
三、配置 gitlab 自动触发构建（具体请参与前面部分相关内容）。
四、配置从 scm 获取 jenkins，
五、保存配置，返回 job 主页面，执行构建。

咱们看到咱们部署已经成功。

Jenlins权限管理

Jenkins 自己自带安全管理的功能，可是通常状况下不多去使用，更可能是使用插件的方式进行更加灵活的处理。
Jenkins 的权限管理须要依赖 Jenkins 的权限管理插件。经过配置插件 role-base，能够很方便给不一样用户不一样 job 的管理和执行权限。

插件的安装与配置

在系统管理、插件管理中搜索 role-base 插件，能够进行安装，

具体安装过程就再也不叙述，你们能够查看咱们插件管理部分的内容。

插件安装完成以后，咱们须要在“配置全局安全”中启用插件，打开“系统管理->全局安全配置”页面。

选择受权策略为“Role Based Strategy”，保存退出后，在系统管理页面出现一个角色管理工具：

点击进入以后，就能够对咱们的用户进行权限配置。

建立用户

咱们来建立一个 dev 用户，在“系统管理”中，选择“管理用户”，

选择右侧的新建用户

输入用户名、密码等信息

点击“新建用户”完成用户建立。

角色管理

在“系统管理”，选择“Manage and Assign Roles”进入角色管理页面，

点击“Manage Role”，建立一个全局的 dev 角色，受权只读的权限

在“角色管理页面”，选择“Assign Roles”，将 dev 用户赋予 dev 角色

须要注意的是，以前 admin 或 root 的权限选项不要移除，不然这些用户可能没法登陆。
使用 dev 用户登陆，发现没有任何 job,由于尚未为 dev 用户配置查看的 job 的权限

回到角色管理页面，添加一个 dev 的 job 角色，使用正则表达式匹配 dev 角色能够管理的 job 的名称

在“Assign Roles”页面，将刚才建立的 job 角色配置给 dev 用户。

此时，咱们再次使用 dev 用户登陆 jenkins,便可以看到匹配到的 job，并且能够执行你配置的操做。

Jenkins备份、升级、迁移

升级

下载新版 Jenkins.war 文件，替换旧版本 war 文件，重启便可。
Jenkins.war 文件的位置通常为/usr/lib/jenkins/Jenkins.war。

迁移、备份

Jenkins 的全部的数据都是以文件的形式存放在 JENKINS_HOME 目录中。

因此无论是迁移仍是备份，只须要操做 JENKINS_HOME 就行。

建议将 JENKINS_HOME 打包后在拷贝， windows上能够用 zip， rar 等，Linux 上有 zip，tar 等。

而后将打包的文件解压到新的 JENKINS_HOME目录就好了。

使用thinbackup插件备份

安装插件

安装 ThinBackup 插件，可能参考前面插件管理部分。

配置插件

手动备份

测试从备份恢复

咱们删除/var/lib/jenkins/job 目录下的 my‐freestyle‐job 目录，

而后咱们使用刚才的备份恢复

恢复完成后，我发现刚才删除的目录又回来了

持续集成

持续集成基础概念

1、持续集成

2、持续交付

3、持续部署

4、持续继承的通常流程

提交

测试（第一轮）

构建

测试（第二轮）

部署

回滚

认识DevOps

DevOps是什么？

为何须要DevOps？

DevOps如何落地

实施 DevOps 的具体方法

创建快速敏捷的团队

实现自动化流程

DevOps在落地实施过程当中常常会遇到的问题

DevOps 技术栈

敏捷管理工具

产品&质量管理

代码仓库管理

自动化构建脚本

虚拟机与容器化

持续集成（CI）&持续部署（CD）

自动化测试

自动化运维工具

监控管理工具

版本控制概要

实验前准备

安装GIT

编译安装

yum安装

初始化工做目录

常规使用（建立数据-提交数据）

GIT COMMIT -A 参数

删除暂存区数据

重命名暂存区数据

查看历史记录

还原历史数据

还原将来数据

标签使用

对比数据

分支结构

建立分支

合并分支

分支冲突

windows客户端使用

Git服务器

私有仓库

GitLab安装部署

gitlab服务构成

gitlab工做 流程

Nginx

GitLab Shell

GitLab Workhorse

Git经常使用经常使用命令和目录及仓库管理

命令

目录

配置GitLab

关闭注册功能

Create group

Create user

grant user

保护分支

GitLab配置SSH

初始化GitLab仓库

使用Gitlab远程仓库

GitLab备份管理

备份配置

手动备份

定时备份

恢复实践

执行升级操做

Gitlab高级使用

GitHub的使用

Jenkins的使用

Jenkins安装

gitlab工做流程