持續集成

時間 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工做流程