第1章 引入
l 一個開發單打獨鬥，撸代碼，開發網站，自由自在；
l 多個開發同時開發一個網站，同時改一份代碼。但是同時改一個檔案會導緻沖突。
l 采用分支結構，每天上班第一件事克隆代碼，下班前最後一件事合并代碼。（上一篇文章有寫到）
l 好景不長，開發越來越多，代碼檔案越來越多。每天下班前合并代碼時，發現很多合并失敗的檔案。最後每天加班3小時人工合并代碼。
l 解決方法：将代碼合并的周期縮短，以前一天，現在一小時，半小時。。。。。
l 随時随地将代碼合并，這種方法叫做持續內建。
持續內建（英語：Continuous integration，簡稱CI）
持續內建指的是，頻繁地（一天多次）将代碼內建到主幹。
它的好處主要有兩個：
Ø 快速發現錯誤。每完成一點更新，就內建到主幹，可以快速發現錯誤，定位錯誤也比較容易。
Ø 防止分支大幅偏離主幹。如果不是經常內建，主幹又在不斷更新，會導緻以後內建的難度變大，甚至難以內建。
l 初級運維很苦逼，剛開始開發每天合并一次代碼，然後運維把代碼pull下來測試就可以了。
l 但是，後來開發引進持續內建方法論，開發們都“彈冠相慶”。
l 運維感覺好苦逼，一天到晚不停的測試代碼。
l 運維就想有沒有辦法自動化？
l 借助一個自動化的部署工具，叫做JENKINS。
l 開發上傳自己的代碼到GITLAB，gitlab發消息通知Jenkins，随後Jenkins從倉庫拉取代碼。最後全自動部署到測試伺服器進行相關測試，并将測試結果通知運維和開發。
l 還有偷懶的方法，直接把這個工具交給開發使用，從此就可以高枕無憂了。
l 這種自動測試的方法叫做持續傳遞。
持續傳遞（英語：Continuous delivery，簡稱CD），指的是：頻繁地将軟體的新版本，傳遞給品質團隊或者使用者，以供評審。如果評審通過，代碼就進入生産階段。
持續傳遞可以看作持續內建的下一步。它強調的是，不管怎麼更新，軟體是随時随地可以傳遞的。
l 代碼測試通過了，該到生産環境部署了；
l 部署時要麼成功，要麼失敗復原；
l 可以使用自動化部署工具或批量管理工具（ansible）
l 這裡有個方法叫做持續部署。
持續部署（英語：Continuous Deployment，縮寫為 CD）是持續傳遞的下一步，指的是代碼通過評審以後，自動部署到生産環境。
持續部署的目标是，代碼在如何時刻都是可部署的，可以進入生産階段。
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許可證下釋出的自由軟體。
第2章 安裝Jenkins
推薦的硬體配置
1 GB的RAM
50 GB的驅動器空間
系統環境
[root@jenkins ~]# cat /etc/redhat-release
CentOS Linux release 7.2.1511 (Core)
[root@jenkins ~]# uname -r
3.10.0-327.el7.x86_64
[root@jenkins ~]# getenforce
Disabled
[root@jenkins ~]# systemctl status firewalld.service
● firewalld.service - firewalld - dynamic firewall daemon
Loaded: loaded (/usr/lib/systemd/system/firewalld.service; disabled; vendor preset: enabled)
Active: inactive (dead)
軟體要求
Java 8--無論是Java運作時環境（JRE）還是Java開發工具包（JDK）都可以。
可以使用open jdk
正常安裝方法：使用RPM包安裝
RPM包下載下傳位址：
官方倉庫 https://pkg.jenkins.io/redhat-stable/
清華大學開源軟體鏡像站 https://mirrors.tuna.tsinghua.edu.cn/jenkins/redhat/
下載下傳相應的資料包即可，我這裡使用的是jenkins-2.73.1-1.1.noarch.rpm
yum安裝jdk
yum -y install java-1.8.0-openjdk java-1.8.0-openjdk-devel
安裝rpm包
rpm -ivh jenkins-2.73.1-1.1.noarch.rpm
啟動
/etc/init.d/jenkins start
檢查端口資訊
[root@jenkins ~]# ss -lntup |grep java
tcp LISTEN 0 50 :::8080 :::* users:(("java",pid=1715,fd=159))
RPM包安裝的内容
[root@Jenkins ~]# rpm -ql jenkins
/etc/init.d/jenkins # 啟動檔案
/etc/logrotate.d/jenkins # 日志分割配置檔案
/etc/sysconfig/jenkins # jenkins主配置檔案
/usr/lib/jenkins # 存放war包目錄
/usr/lib/jenkins/jenkins.war # war 包
/usr/sbin/rcjenkins # 指令
/var/cache/jenkins # war包解壓目錄 jenkins網頁代碼目錄
/var/lib/jenkins # jenkins 工作目錄
/var/log/jenkins # 日志
配置檔案說明
[root@Jenkins ~]# grep "^[a-Z]" /etc/sysconfig/jenkins
JENKINS_HOME="/var/lib/jenkins" #jenkins工作目錄
JENKINS_JAVA_CMD=""
JENKINS_USER="jenkins" # jenkinx啟動使用者
JENKINS_JAVA_OPTIONS="-Djava.awt.headless=true"
JENKINS_PORT="8080" # 端口
JENKINS_LISTEN_ADDRESS=""
JENKINS_HTTPS_PORT=""
JENKINS_HTTPS_KEYSTORE=""
JENKINS_HTTPS_KEYSTORE_PASSWORD=""
JENKINS_HTTPS_LISTEN_ADDRESS=""
JENKINS_DEBUG_LEVEL="5"
JENKINS_ENABLE_ACCESS_LOG="no"
JENKINS_HANDLER_MAX="100" # 最大連接配接
JENKINS_HANDLER_IDLE="20"
JENKINS_ARGS=""
浏覽器通路: http://10.0.0.64:8080
解鎖Jenkins，密碼從指令行中擷取
[root@jenkins ~]# cat /var/lib/jenkins/secrets/initialAdminPassword
618377eec2ba4731a37f7ae80903c076
輸入授權密碼，然後點選下一步
稍等一會來到安裝插件選擇的頁面，将此頁面關閉，在安裝完成Jenkins後安裝插件。
關閉安裝插件選擇後，選擇開始使用Jenkins
安裝完成，顯示界面
安裝Jenkins插件
系統管理 >> 管理插件
選擇自己需要的插件進行安裝即可，也可選擇全部安裝。
插件安裝完成後插件安裝目錄的内容
[root@jenkins ~]# ls /var/lib/jenkins/plugins/
ace-editor icon-shim.jpi pipeline-stage-view
ace-editor.jpi jackson2-api pipeline-stage-view.jpi
……省略若幹
handlebars pipeline-stage-step.jpi ws-cleanup
handlebars.jpi pipeline-stage-tags-metadata ws-cleanup.jpi
icon-shim pipeline-stage-tags-metadata.jpi
至此Jenkins安裝完成
系統管理 >> 系統設定 >> Maven項目配置
系統管理 >> 系統設定 >> Jenkins Location
向下拉，找到郵件通知，配置郵件的smtp資訊
配置完成後點選 Test configuration 進行測試，測試成功後，點選儲存
第3章 Jenkins使用
建立一個新的任務
輸入項目的名稱，選擇建構自由風格的軟體
gitlab的詳細安裝方法參照：版本控制系統
建立公鑰和私鑰
[root@gitlab ~]# cat /root/.ssh/id_rsa
-----BEGIN RSA PRIVATE KEY-----
MIIEowIBAAKCAQEAq/uH2b/N40EAwp4I5roiRcNB9Jxh3wAlbsYGS7M6pWuFRWSC
jgsl83sYYR1vrx+1LNNwF7LC+4BcUmYOvG8/rIQV89joRbpcIrHSEKm1hagblgLY
UqykJZ1iBczPZc11/33yOsWJRz+4vHPjc9wtCK5u5Zz9zOSCaWCLgg7inNDUho0K
caajGJMzahgpGApPqwfCP2mb/buPYjgg+iNFpBKWy9oc6Ee4FDIv1ssuoCmoNQst
zpouxUtfXRqHyE5hul5RQ3Ec0R/ac/Hgc285Spl9Ro7J3RBCwiJhyyo5kZr6KXRe
Se29cH1mHB30vmfkksdqwniBeM8cyHzvqLJ5AwIDAQABAoIBAE52C41ZBwo1nq4r
QS5aHsarBQ0exzvgqjM2XqrsksXjHsMAztsU1PSW5RFxR4Giupo/wDTfljr9XaEt
9G0dZ/RBsm40OAuPsPcXHxoBAtJ+Vk+C7sQRBTYv7gdtX/U23i14fSk4858wwAwh
5tP10AnU4r0YeWWfnquKozrrpZEaqUjtbqGRXdo+larXpmagp9iSGUW6e7ln1ACY
imikXSVc6PtU0rVMrMbCT6J3LleUZeKnkd2QZa3SRurVmUB5s62L08htHRoNbENy
Gv++47q0xK9lF6IcAqpBvIOaoN4nqMdYpXTt5Ee4ls+0YLnLh896JTH0orJpxltK
eRLds+kCgYEA1sAM3F26m1GroYuxsE0+viSPMfFCapLv8hcbQg0GjdjuLAoxqNRj
jYKqDl+xEOIe4d5zLKNw5nszUf98th+KHhhLl651W41MYIImnyU2jr3Z2JrA2UoM
XsykALRwb4sFcPUhzs1xmPA3HkSPyqcpWQrcYq4xokL+NB35CE7mAVUCgYEAzQR1
eyeFUtyj4My1SNDmR0FSzB88C+ynJQr13sDfmmKFT+C28uY8DDHdspQhGsPH7Q5O
4Rf2cC28iJUwZNMzfD5054Y7UN45Ft91j6ru8SPDgo7dwyrcDXuvWSPicmKj06b9
6qsYJuJ5nWJP412qd0Ok0OvA638apexpPO9qcPcCgYAh/x9KF5B+HCzGkz3bAi+H
nHQK3P29r2tK8PuAtl0uQYRa9nYsGwtzkJbpVZ7LZHCtIzEqhOlPo3tZZM/SaSXN
Y907swOjLbhEovYIRbTgXg/JqZ4UCBPzQgRIlEgkcGa5HiVu/rkYFBc1tHbrBxGV
phGDkb4LyP1DNOeCuDLTTQKBgQCscVevoupNbDCbYRQKj0tiG9vcvVjwXrmoOrPc
DTcG0F95dHXtkSJoz3i+QEIoFQ0Qo7xNMK6kZJPz/iiaZdskYhRKuWki+Afk6Ugk
843PXlmQc0Ksalx1KteujrRlqfpKiGeC/y5tZokMjCjOAXbkogz7fZDjhCGR9mv+
SRKquQKBgF3zVifL/+jifBBz2O0k/02LOcdmUNSwqnTOF7Lnwczr33BJF9UVVTH1
nfOjZIUPM+D7pT3JuCevhFr5XxWQCCS67NIXrSEv6nDwDPz7EQ4Q04SPf88wL64j
2bdQjVT4UoBJzM4/mSDVBHrWoRWqzDszqeBcyNib2Cu3GllKwuT9
-----END RSA PRIVATE KEY-----
在gitlab中添加公鑰id_rsa.pub
在jenkins中添加私鑰id_rsa
在首頁中，點選項目名稱的下拉監聽
選擇源碼管理，先将gitlab的項目位址複制過來
選擇SSH密鑰和證書，然後選擇直接輸入，将私鑰複制到下框中即可
添加完成後，點選儲存
選擇剛才建立的證書，完成後，選擇建構
選擇建構——拉到最底部，選擇使用shell腳本
腳本内容
建立測試環境
[root@Jenkins ~]# mkdir -p /data/www
[root@jenkins ~]# chown -R jenkins.jenkins /data/www/
選擇建構後的操作，讓每次建構完成後都将結果發送給管理者
回到首頁，點選右側的按鈕進行測試
部署完成
檢視部署日志
檢視部署結果
[root@jenkins www]# ls
README.md
該功能會使用到一個插件 gitlab plugin
配置gitlab認證
添加一個新的憑證
從gitlab的設定中将 token複制過來
将複制的token粘貼到api token中，點ok
在系統配置中找到Gitlab 将資訊進行填寫，Credentials 選擇剛剛建立對的即可
打開項目，編輯項目的建構觸發器
在gitlab上配置連接配接jenkins ，将Jenkins的Secret token 與Build URL 複制到gitlab中
儲存之前先程序測試，測試成功後進行儲存
在gitlab進行上傳檔案，可以測試。
在日志中顯示是 Started by GitLab push by Administrator 即表示自動內建成功
第4章 代碼上線方案
l 純手動scp上傳代碼。
l 純手動登陸，Git pull 或者SVN update。
l 純手動xftp上傳代碼。
l 開發發送壓縮包，rz上傳，解壓部署代碼。
l 全程運維參與，占用大量時間。
l 如果節點多，上線速度慢。
l 人為失誤多，目錄管理混亂。
l 復原不及時，或者難以回退。
上線方案示意圖
1、開發人員需在個人電腦搭建LAMP環境測試開發好的網站代碼，并且在辦公室或 IDC機房的測試環境測試通過，最好有專職測試人員。
2、程式代碼上線要規定時間，例如：三天上線一次，如網站需經常更新可每天下午 17點上線，這個看網站業務性質而定，原則就是影響使用者體驗最小。
3、代碼上線之前需備份，網站程式出了問題友善回退，另外，從上線技巧上講，上傳代碼時盡可能先傳到伺服器網站臨時目錄，傳完整後一步mv過去，或者通過In做軟連結— 線上更新代碼的思路。如果嚴格更新，把應用伺服器從叢集節點平滑下線，然後更新。
4、盡量由運維人員管理上線，對于代碼的功能性，開發人員更在意，而對于代碼的性 能優化和上線後伺服器的穩定，運維更在意伺服器的穩定，是以，如果網站當機問題歸運維管，就要讓運維上線，這樣更規範科學。否則，開發随意更新，出了問題運維負責，這樣就錯了，運維永遠無法擡頭。
JAVA代碼環境，上線時，有數台機器同時需要更新或者分批更新
1. 本地開發人員取svn代碼。當天上線送出到trunk，否則，長期項目單開分支開發，然後在合并主線(trunk)
2. 辦公内網開發測試時，由開發人員或配置管理者通過部署平台jenkins實作統一部署，（即在部署平台上控制開發機器從svn取代碼，編譯，打包，釋出到開發機，包名如idc_dep.war）.
3. 開發人員通知或和測試人員一起測試程式，沒有問題後，由配置管理者打上新的tag标記。這裡要注意，不同環境的配置檔案是随代碼同時釋出的。
4. 配置管理者，根據上一步的tag标記，checkout出上線代碼，并配置好IDC測試環境的所有配置，執行編譯，打包(mvn,ant)(php不需要打包)，然後釋出到IDC内的統一分發伺服器。
5. 配置管理者或SA上線人員，把分發的程式代碼内容推送到相關測試伺服器（包名如idc_test.war），然後通知開發及測試人員進行測試。如果有問題向上回退，繼續修改。
6. 如果IDC測試沒有問題，繼續打好tag标記，此時，配置管理者，根據上步的tag标記，checkout出測試好的代碼，并配置好IDC正式環境的所有配置，執行編譯，打包(mvn,ant)(php不需要打包)，然後釋出到IDC内的統一分發伺服器主機，準備批量釋出。
7. 配置管理者或SA上線人員，把分發的内容推送到相關正式伺服器（包名如idc_product.war）,然後通知開發及測試人員進行測試。如果有問題直接釋出復原指令。
IDC正式上線的過程對于JAVA程式，可以是AB組分組上線的思路，即平滑下線一半的伺服器，然後釋出更新代碼，重新開機測試，無問題後，挂上更新後的伺服器，同時再平滑下線另一半的伺服器，然後釋出更新代碼測試（或者直接釋出後，重新開機，挂上線）
對于PHP上線方法：釋出代碼時（也需要測試流程）可以直接釋出到正式線臨時目錄 ，然後mv或更改link的方式釋出到正式上線目錄 ，不需要重新開機http服務。這是新朗，趕集的上線方案。
對于java上線方法:較大公司需要分組平滑上線（如從負載均衡器上摘掉一半的伺服器），釋出代碼後，重新開機伺服器測試，沒問題後，挂上上好線的一半，再下另外一半。如果前端有DNS智能解析，上線還可以分地區上線若幹伺服器，逐漸普及到全國的伺服器，這個被稱為“灰階釋出”，在後面門戶網站上線的知識裡我們在講解。
1. 上線的流程裡，辦公室測試環境-->IDC測試環境-->正式生産環境，所有環境中的所有軟體均應版本統一，其次盡量單一，否則将後患無窮，開發測試成功，IDC測試就可能有問題（如:作業系統，web伺服器，jdk,php,tomcat,resin等版本）
2. 開發團隊小組辦公内部測試環境測試（該測試環境屬于開發小組維護，或定時自動更新代碼），代碼有問題傳回給某開發人員重新開發。
3. 有專門的測試工程師，程式有問題直接傳回給開發人員（此時傳回的一般為程式的BUG，稱為BUG庫），無問題進行IDC測試
4. IDC測試由測試人員和運維人員參與，叫IDCtest,進行程式的壓力測試，有問題直接傳回給開發人員，無問題進行線上環境上線。
5. 數台伺服器代碼分發上線方案舉例（JAVA程式）
A:假設同業務伺服器有6台，将伺服器分為A,B兩組，A組三台，B組三台，先對A組進行從負載均衡器上平滑下線，B組正常提供服務，避免伺服器因上線影響業務。
B:下線過程是通過腳本将A組伺服器從RS池（LVS,NGINX,HAPROXY,F5等均有平滑方案）中踢出，避免負裁均衡器将請求發送給A組伺服器（此時的時間應該為網站流量少時，一般為晚上）
C:将代碼分發到A組伺服器的站點目錄下，對A組伺服器上線并重新開機服務，并由專業的測試人員進行通路測試，測試成功後，挂上A組的伺服器，同時下線B組伺服器，B組代碼上線操作測試等和A組相同，期間也要觀察上線提供服務的伺服器狀況，有問題及時復原。
6. 特别說明：如果是PHP程式，則上線可以簡單化，直接将上線代碼（最好全量）釋出到所有上線伺服器的特定目錄後，分發完成後，一次性mv或ln到站點目錄，當然測試也是少不了的。測試除了人員測試外，還有各種測試腳本測試各個相關業務接口。