<<互聯網敏捷DevOps和自動化之5.持續集成>>
持續集成的價值是什么？對于開發和測試人員又意味著什么呢？
1.1 持續集成介紹
使用持續集成和測試驅動開發的敏捷實踐
說到持續集成，我們就不得不提到源代碼管理，尤其是互聯網得今天源代碼得管理至關重要，分之策略和代碼合并，代碼review都是整個軟件生命周期得關鍵點，那么下面我就對常用得代碼管理svn和git進行詳細介紹和闡述
About Git and Git flow
Subversion有一個很標準的目錄結構，是這樣的。比如項目是proj，svn地址為svn://proj/，那么標準的svn布局是
svn://proj/|+-trunk+-branches+-tags
這是一個標準的布局，trunk為主開發目錄，branches為分支開發目錄，tags為tag存檔目錄（不允許修改）。但是具體這幾個目錄應該如何使用，svn并沒有明確的規范，更多的還是用戶自己的習慣。對于這幾個開發目錄，一般的使用方法有兩種。我更多的是從軟件產品的角度出發（比如freebsd），因為互聯網的開發模式是完全不一樣的。第一種方法，使用trunk作為主要的開發目錄。一般的，我們的所有的開發都是基于trunk進行開發，當一個版本/release開發告一段落（開發、測試、文檔、制作安裝程序、打包等）結束后，代碼處于凍結狀態（人為規定，可以通過hook來進行管理）。此時應該基于當前凍結的代碼庫，打tag。當下一個版本/階段的開發任務開始，繼續在trunk進行開發。此時，如果發現了上一個已發行版本（Released Version）有一些bug，或者一些很急迫的功能要求，而正在開發的版本（Developing Version）無法滿足時間要求，這時候就需要在上一個版本上進行修改了。應該基于發行版對應的tag，做相應的分支（branch）進行開發。例如，剛剛發布1.0，正在開發2.0，此時要在1.0的基礎上進行bug修正。按照時間的順序
1.0開發完畢，代碼凍結
基于已經凍結的trunk，為release1.0打tag此時的目錄結構為svn://proj/ +trunk/ (freeze) +branches/ +tags/ +tag_release_1.0 (copy from trunk)
2.0開始開發，trunk此時為2.0的開發版
發現1.0有bug，需要修改，基于1.0的tag做branch此時的目錄結構為svn://proj/ +trunk/ ( dev 2.0 ) +branches/ +dev_1.0_bugfix (copy from tag/release_1.0) +tags/ +release_1.0 (copy from trunk)
在1.0 bugfix branch進行1.0 bugfix開發，在trunk進行2.0開發
在1.0 bugfix 完成之后，基于dev_1.0_bugfix的branch做release等
根據需要選擇性的把dev_1.0_bugfix這個分支merge回trunk（什么時候進行這步操作，要根據具體情況）
這是一種很標準的開發模式，很多的公司都是采用這種模式進行開發的。trunk永遠是開發的主要目錄。
第二種方法，在每一個release的branch中進行各自的開發，trunk只做發布使用。這種開發模式當中，trunk是不承擔具體開發任務的，一個版本/階段的開發任務在開始的時候，根據已經release的版本做新的開發分支，并且基于這個分支進行開發。還是舉上面的例子，這里面的時序關系是。
1.0開發，做dev1.0的branch此時的目錄結構svn://proj/ +trunk/ (不擔負開發任務 ) +branches/ +dev_1.0 (copy from trunk) +tags/
1.0開發完成，merge dev1.0到trunk此時的目錄結構svn://proj/ +trunk/ (merge from branch dev_1.0) +branches/ +dev_1.0 (開發任務結束，freeze) +tags/
根據trunk做1.0的tag此時的目錄結構svn://proj/ +trunk/ (merge from branch dev_1.0) +branches/ +dev_1.0 (開發任務結束，freeze) +tags/ +tag_release_1.0 (copy from trunk)
1.0開發，做dev2.0分支此時的目錄結構svn://proj/ +trunk/ +branches/ +dev_1.0 (開發任務結束，freeze) +dev_2.0 （進行2.0開發） +tags/ +tag_release_1.0 (copy from trunk)
1.0有bug，直接在dev1.0的分支上修復此時的目錄結構svn://proj/ +trunk/ +branches/ +dev_1.0 (1.0bugfix) +dev_2.0 （進行2.0開發） +tags/ +tag_release_1.0 (copy from trunk)
選擇性的進行代碼merge
這其實是一種分散式的開發，當各個部分相對獨立一些（功能性的），可以開多個dev的分支進行開發，這樣各人/組都不會相互影響。比如dev_2.0_search和dev_2.0_cache等。但是這樣merge起來就是一個很痛苦的事情。這里要注意一下的，第六步進行選擇性的merge，是可以當2.0開發結束后一起把dev_1.0（bugfix用）和dev_2.0（新版本開發用）merge回trunk。或者先把dev_1.0 merge到dev_2.0，進行測試等之后再merge回trunk。這兩種方法各有利弊，第一種方法是可以得到一個比較純的dev_2.0的開發分支，而第二種方法則更加的保險，因為要測試嘛。以上呢，就是我說的兩種開發模式了，具體哪種好，并沒有定論。這里大致的說一下各自的優缺點第一種開發模式（trunk進行主要開發，集中式）：優點：管理簡單缺點：當開發的模塊比較多，開發人數/小團隊比較多的時候，很容易產生沖突而影響對方的開發。因為所有的改動都有可能觸碰對方的改動第二種開發模式（分支進行主要開發，分散式）：優點：各自開發獨立，不容易相互影響。缺點：管理復雜，merge的時候很麻煩，容易死人
1.2 持續集成概念
“持續集成”一詞來源與極限編程（Extreme Programming）,作為它的12個實踐原則之一出現。ThoughtWorks首席科學家、軟件開發領域大事Martin Fowler對持續集成是這樣定義的：持續集成是一種軟件開發實踐，即團隊開發成員經常集成他們的工作，通常每個成員每天至少集成一次，也就意味置頂每天可能發生多次集成。每次集成都是通過自動化的構建（包括編譯、發布、自動化測試）來驗證，從而盡快地發現集成錯誤。許多團隊發現這個過程可以大大的減少集成的問題，讓團隊能夠更快的開發內聚的軟件。從上面的定義可以看出，一個典型的持續集成周期包括以下幾個步驟：
1版本控制服務器上有最新的代碼
2持續集成服務器從版本控制服務器下載最新的代碼
3等代碼完全更新以后，調用自動化編譯腳本，進行代碼編譯
4運行所有的自動化測試（單元測試、接口測試、系統級別的UI自動化測試等）
5將結果寫入報告文件中，反饋給團隊成員
6如果構建失敗，必須盡快修改確保下次構建成功
7產生可執行的軟件版本，提供給測試人員進行測試持續集成框架是由代碼提交活定時來觸發的（項目級別的持續集成可以由開發每次代碼提交觸發，而產品級別的持續集成可以由定時來觸發），每次提交到版本控制服務器上的代碼都要經過自動化構建，確保每次的代碼變更都不會導致持續集成失敗。
1.3 持續集成目的和價值
持續集成的目的不是減少build失敗的次數，而是盡早發現問題，在最短的時間內解決問題，減少風險和浪費。從而讓產品開發流程更加敏捷，縮短產品開發周期，在產品上線后，讓用戶用得更加順暢。在沒有應用持續集成之前，傳統的開發模式是項目一開始就劃分模塊，每個開發人員分別負責一個模塊，等所有的代碼都開發完成之后再集成到一起提交給測試人員，隨著軟件技術隊的發展，軟件已經不能簡單地通過劃分模塊的方式來開發，需要項目內部相互協作，劃分模塊這種傳統的模式的弊端也越來越明顯。由于很多bug在項目早期的設計、編碼階段就引入，到最后集成測試時才發現問題，開發人員需要花費大量的時間來定位bug，加上軟件的復雜性，bug的定位就更難了，甚至出現不得不調整底層架構的情況。這種情況的發生不僅僅對測試進度造成影響，而且會拖長整個項目周期。而持續集成可以有效解決軟件開發過程中的許多問題，在集成測試階段之前就幫助開發人員發現問題，從而可以有效的確保軟件質量，減小項目的風險，使軟件開發團隊從容的面對各種變化。持續集成報告中可以體現目前項目進度，哪部分需要已經實現，哪些代碼已經通過自動化測試，代碼質量如何，讓開發團隊和項目組了解項目的真實狀況。持續集成的價值有：1易于定位錯誤。某一次集成失敗了，說明新加的代碼或修改的代碼引起了錯誤，很容易就可以知道誰負責的代碼出了問題，可以直接找相關人員來進行討論，分析。2及早在項目里取得系統級成果。每次集成產生的版本都是一個可用的版本。3改善對進度的控制。每次持續集成報告中可以體現目前項目進度，哪部分需求已實現，哪些還沒實現。4改善客戶關系。可以非常明確的給演示項目進度（理由如上）5更加充分地測試系統中的各個單元。每日構建和測試相結合帶來的好處6能在更短的時間里構建整個系統7有助于項目的開發數據的收集8與其他工具結合的持續代碼質量改進。如與checkstyle，PMD、Findbugs等9與測試工具或框架結合的持續測試。如LoadRunner等10便于code review。每個build與前一個build之間有什么改動，針對這些改動可以有效的實現code review
1.4 持續集成流程圖
持續集成（Continuous Integration，CI）是一個長期而又敏捷的過程，在核心的CI可以分為兩大類，一類是產品級別的持續集成，產品級別的持續集成在發布日做到日構建。另一類也就是本文需重要描述的項目級別的持續集成。項目級別CI貫穿整個項目周期，從項目的FRD到發布后的跟進。下圖是項目級別的持續集成的流程圖，主要介紹項目使用CI的流程。
圖片.png
CI的介入是從立項的時候開始，前期是溝通和方案的定制，然后就是具體策略的執行，這里需要說明一下，CI不是獨立存在的個體，他會與測試范圍界定、缺陷分析等緊緊結合。當拿到一個項目時，應該怎么做，在流程圖中已經說明了一切，首先是要做項目評估，如果項目適合做CI，然后就可以和項目組溝通，達成一直需指定方案計劃和資源評估方案，最后進行具體方案的實施。
圖中節點說明：
項目評估：
當我們參與一個項目的時候，需要評估下該項目是否適合做項目級別的持續集成，不是什么項目都可以做持續集成的。根據業界的經驗，如何項目周期短，迭代次數少，這類的項目就不適合做持續集成，但還是要根據項目的特點進行評估。
溝通：
這是非常重要的一點，只有團隊達成一致，才能將CI持續下去，我們在達成一直的基礎上做約定和計劃，如果在溝通的過程中無法達成一致，那么個人建議不要進行CI，當然也要去分析為什么沒有達成一致。
計劃約定與資源評估：
在溝通達成一致的基礎上做出計劃約定和資源評估。
持續集成實施：
在溝通、計劃、約定的基礎上我們就可以運用工具和策略對起進行實施，具體的工具和實施在后面的章節會做說明。
2 持續集成方案與策略
在前面介紹了項目級別持續集成的流程，四個節點（項目評估、溝通、計劃與方案定制、持續集成實施）都非常的重要，項目評估、溝通、計劃與方案定制屬于前期的過程，也是基礎。本章重點介紹持續集成實施中持續集成的方案與策略、量化標準以及數據的采集。
2.1 持續集成策略
持續集成的實施肯定缺少不了策略，但我們應該使用什么樣的集成策略呢？如下圖所示：
Jenkins + Pipeline 構建流水線發布
利用Jenkins的Pipeline配置發布流水線
參考： https://jenkins.io/doc/pipeline/tour/deployment/
pipeline
新建一個名為pipeline-loop的 pipeline項目，然后配置，關鍵配置如下：
生成pipeline可以用的git連接（通過此鏈接，從私有gitlab拉取代碼）
Pipeline生成： https://jenkins.aniu.so/view/Pipeline/job/pipeline-loop/pipeline-syntax/
pipeline-syntax
生成的pipeline代碼如下，后面配置會用到：
checkout([$class: 'GitSCM', branches: [[name: '*/master']], doGenerateSubmoduleConfigurations: false, extensions: [], submoduleCfg: [], userRemoteConfigs: [[credentialsId: '500378f5-a6e4-4255-984e-61537fe0e455', url: 'git@gitlab.aniu.so:aniu-yunwei/game-of-life.git']]])
配置pipeline-loop項目
pipeline { agent any stages { stage('Checkout') { steps { echo 'Checkout' checkout([$class: 'GitSCM', branches: [[name: '*/master']], doGenerateSubmoduleConfigurations: false, extensions: [], submoduleCfg: [], userRemoteConfigs: [[credentialsId: '500378f5-a6e4-4255-984e-61537fe0e455', url: 'git@gitlab.aniu.so:aniu-yunwei/game-of-life.git']]]) } } stage('Build') { steps { echo 'Building' sh 'mvn clean install' # 可以用自己的 mvn clean deploy + 參數替代 } } stage('Test') { steps { echo 'Testing' sh 'mvn clean verify sonar:sonar' # 此處可以使用mvn test替代，筆者這步是檢測代碼的質量同步到自己的代碼質量檢測平臺。 } } stage('Deploy') { steps { echo 'Deploying' sh 'mvn clean deploy' # 此處調用腳本或者ansible、saltstak，部署到遠程 } } }}
配置完成保存，然后build此項目，查看結果如下：
pipeline-test
持續集成的策略是采用技術手段為CI提供技術依據，做一個好的持續的項目最核心的是良好的單元測試編碼，集成測試編碼、系統測試編碼、web ui層自動化等不同level的自動化能力，安裝核心系統目前的情況來講，有些條件并不成熟。但我們可以反其道而行之，以項目持續集成為基礎，來推動某些條件（如單元測試、代碼規范）的良性循環，形成量的積累，使得持續集成條件逐步走上正軌。
2.2 單元測試集成
單元測試是持續集成中非常重要的組成部分。目前我們軟件質量部產品線的單元測試可以說是幾乎處于無的狀態。目的與價值單元測試（模塊測試）是開發者編寫的一小段代碼，用于檢驗被測代碼是否正確。通常而言，一個單元測試是用于判斷某個特定條件或場景下某個函數的行為是否按照預期結果進行。單元測試與其他測試不同，單元測試可看作是編碼工作的一部分，應該由程序員完成（TDD），也就是說，經過了單元測試的代碼才是已完成的代碼，提交產品代碼時也要同時提交測試代碼。持續集成中集成單元測試，每次迭代提交都保證單元測試的質量，那么產品的質量在一定程度上都得以保證。所以單元測試在持續集成過程中是測試件中非常重要的組成部分。不可缺少，這也是CI過程要單元測試集成的目的和意義。
2.3 單元測試策略
集成測試項目中對單元測試策略采用如下：1參與單元測試case設計開發人員或測試人員進行單元測試編碼，測試設計人員參與case設計，因為我們設計case的角度和開發人員是不一樣的，測試人員的設計會更加全面。2單元測試case的review要進行單元測試case的review，如果發現不合適的case則要進行修訂。以保證單元測試的質量。3單元測試的用例評審（單元測試完成階段）與項目組成員或資深人員一起參與單元測試用例的評審，對不合適的用例需進行修改。在持續集成過程中，如果發現單元測試的failed趨勢上升或failed達到某一標準時，需和開發人員溝通并修訂bug，從而保證每次迭代產品的質量。
2.4 適用范圍和階段
單元測試適合在開發人員進行單元測試編碼階段，一旦單元測試編碼完成，上述單元測試的測試都可以適用，貫穿于整個項目周期。
2.5 工具
既然有持續集成，那我們就需要用到一些持續集成的工具和平臺去分析每次的構建結果，在持續集成平臺（hudson）中集成了單元測試覆蓋率統計工具。參考后續內容。
2.6 量化指標
使用單元測試策略中我們會采集到一些數據指標，
3 接口測試集成
接口測試類似于單元測試，是分層自動化的重要組成部分，介于黑盒測試與白盒測試之間，在了解系統設計與接口定義對前提下，就可以在適當的時候運用mock來進行接口測試。
3.1 目的與價值
接口測試是質量的保證和效能的提升，所謂質量保證，就是深入到代碼的底層，可以對接口進行直接的參數注入，查看其返回結果，讓我們知道底層到底發生了什么。所謂效能的提升，就是程序的速度遠比手工的速度快，幾分鐘就可以跑完上百個用例。接口測試不但可以提高測試效率，也不需要投入過多的精力去熟悉代碼邏輯，而且可以借助單元測試技術實現持續集成和每日構建。
3.2 接口測試策略
本文采用的接口測試主要是對系統提供的服務接口進行所有接口的覆蓋和集成，在覆蓋的過程中進行以業務為導向的codeReview。在持續集成運行的過程中發現bug，需與開發人員溝通后修訂bug，從而保證產品的質量。起測試方案如下：1新增的接口進行case覆蓋和集成2修改的接口進行case覆蓋和集成3保證已有接口的正確
3.3 適用范圍和階段
接口測試和單元測試一樣，貫穿整個項目的周期。1需求了解階段：了解項目中接口的功能，接口的輸入輸出參數及返回值，根據項目的情況決定是否做接口測試2設計階段：了解接口的實現，并與開發溝通確定接口以怎么樣的形式進行暴露，從少先隊哪一層暴露。3編碼階段：腳本編寫、數據準備、調試4測試階段：-接口參數完成和提交測試前，主要個工作就是：運行接口測試腳本進行測試，根據測試的結果與開發逐一過用例，以確定是代碼問題還是數據問題，直至所有的case均跑通。-測試階段和分支回歸階段，利用集成測試平臺完成該接口的測試和部分的分支回歸工作，檢查測試結果-發布回歸，利用持續集成平臺檢查測試結果
5 發布會
接口參數若有變化應及時維護腳本和數據
持續集成保證底層的質量3.4 工具
接口測試涉及的工具主要是接口測試的開發和持續集成平臺。
開發工具例如eclipse
持續集成測試平臺hudson的配置和運行4 UI 測試集成
4.1 目的和價值
UI自動化測試是通過直接操作指定的瀏覽器，對瀏覽器中的頁面對象、元素進行操作，完全模擬手工測試過程。項目中運行UI自動化測試的一個目的就是期望能利用自動化替代手工測試提升測試效率，通常在分支回歸階段使用，減少回歸投入時間；另一個目的是為了產品級UI自動化測試做基礎建設。產品級UI自動化測試在每日發布的回歸測試中使用，不僅能擴大回歸范圍，而且能幫我杜絕重要故障，保證產品重要業務流程的正確性。2 UI測試集成策略集成測試項目中對UI測試的策略采用如下：1可行性分析及需求提?。簻y試負責人評估項目是否適合UI自動化覆蓋，并確認UI自動化覆蓋范圍。2計劃安排：測試負責人平臺自動化腳本開發工作量，并且在測試計劃中加入
軟件開發周期中需要一些可以幫助開發者提升速度的自動化工具。其中工具最重要的目的是促進軟件項目的持續集成與交付。通過CI/CD工具，開發團隊可以保持軟件更新并將其迅速的投入實踐中。
Jenkins是最著名的CI/CD系統工具，且能迅速的成為開發引擎，管理開發方面。Jenkins為插件開發提供便利，為擴展版本控制系統提供功能且為IBM提供支持。 由Sun Microsystems分離出來的Hudson項目首次推出Jenkins，其最新版本為2，提高可用性與安全性。
但是當涉及持續集成與持續交付時，Jenkins并不是唯一的選擇。 CircleCI,、GitLab和 JetBrains 等公司也為開發者提供可用的CI/CD工具。
Atlassian Bamboo
Atlassian Bamboo提供豐富的功能，從構建與部署Docker Container在Amazon Web Services運行應用程序。專門的代理可被用于熱修復和關鍵構建。可擴展性一直被視為Jenkins的眼中釘，在這里，Appfire的CEO Randall Ward，Atlassian商業合作伙伴提供附件組件和服務，提高Bamboo優勢。
Atlassian確實提出了可擴展性，同時Jenkins用戶曾發現Jenkins工具有“主要性能障礙”。Bamboo通過輪詢代理和擴展代理功能。Appfire使用Bamboo作為瑞士軍刀，與第三方附加組件集成測試，以及部署代碼。
Bamboo功能代碼顯而易見，確保用戶從之前最新的部署中查看完整的代碼更改。它集成其他的Atlassian產品，包括Bitbucket Git代碼管理解決方案、Jira項目管理解決方案和HipChat團隊聊天應用程序。
CircleCI
CircleCI也強調了擴展性，除了它能測試一切，對移動應用程序進行Jasmin單元測試。CircleCI幫助開發者帶來Docker文件到產品中。
CircleCI提供了一個編排層和一個工作流工具，可自動化代碼更改且將代碼推到數據中心。始于2011年，CircleCI開始作為多組織Saas選擇。它是Jenkins的替代，用戶無須管理自己的服務器，Ruby、Python和AJAX應用程序是它的強項。它現在可以在防火墻外部署，與Jenkins相反，它是開源的且是一個企業解決方案。CircleCI可擴展超出Jenkins所能處理的，其配置是在代碼中編寫的而不是在服務器中完成的。
Eclipse Hudson
Jenkins的前身，在Oracle移交項目的五年前Hudson是Eclipse Foundation管理的。Oracle繼承了Hudson當其在2010年收購了Sun Microsystems，但Jenkins開發者并未在Oracle項目方向上取得一致。最新的更新是在2月，Hudson是用Java編寫且運行在servlet容器上如Apache Tomcat。它可以使用版本控制工具如Git和Subversion。
“在Hudson團隊中我們致力于加強Hudson在一個已開始的基礎上，重點創建Hudson一個合適的平臺為持續交付以及持續集成,“Eclipse的一位代表說?！币虼?您將看到工具的新功能，特別涉及大型企業在規模和復雜的構建管道使用需求Hudson?！?br>
根據Eclipse的一個案例研究顯示，Hudson用戶Cleo提供了業務集成軟件和服務，評估Jenkins代替Hudson因為Jenkins維護大多數Hudson插件?！拔覀兎艞壛诉@個想法后，Jenkins的核心功能是比Hudson的更加不可靠,”Cleo發布工程師Stuart Lorber表示。
GitLab CI
在可用的SaaS或防火墻外，開源GitLab CI可以在任何平臺上執行且支持語言，包括Unix、Windows,OS x。用戶可以自動向上和向下擴展虛擬機進行即時處理和最小化。其他功能包括多語言支持、實時記錄、每階段管道定義多個作業和Docker支持，用于測試和構建Docker圖像。另外可擴展性也是一個優勢。
GitLab CI是GitLab code-hosting平臺的一部分，旨在為持續集成提供簡單的設置。設置CI曾經是乏味的,我們想讓它非常簡單。GitLab CI并不需要大量的管理，測試被執行在GitLab Runner中，用Go編寫且提供多平臺、多語言功能。
因為GitLab CI與GitLab集成，用戶不需要建立新的項目。用戶添加一個文件來描述你想要如何測試庫。
JetBrains TeamCity
JetBrains TeamCity CI/CD服務器集成工具如Apache Maven創建管理和JetBrain自己的YouTrack問題追蹤工具。我們提供完整的體驗與內置的功能插件。
TeamCity 不是開源的，有一個Web界面和管理功能。
該平臺有IDE插件適用于Eclipse、Microsoft Visual Studio、和 JetBrains IntelliJ。還提供動態測試報告。TeamCity是一個產品且已存在10年。由JetBrains衍生出并進化為很成熟的產品。
ThoughtWorks GoCD
ThoughtWorks GoCD是一個開源的持續交付系統，它提供了一個“材料清單”部署。代理網格同時通過管道和版本提供并行處理，模板允許重用配置管道。它支持CD，開箱即用，無須安裝其他的插件。
GoCD與Jenkins不同之處在于它是部署管道以及簡化持續交付，GoCD可被安裝或建立在云上。
ThoughtWorks Snap
ThoughtWorks Snap提供基于云的持續集成和交付的功能。Snap在云計算中完全是人來操作的，它是面向用戶“無須任何基礎設施”。托管部署可以被設置在云平臺中，包括GitHub、Amzaon Web Services、DigitalOcean和Heroku。合并請求被測試以確保其完全合并。
Snap在GitHub上是免費使用公共存儲，其中有一個負載使用私有存儲。近期，Docker支持增加到Snap，Docker的圖片通過軟件交付和部署可被使用。
Jenkins是一個流行的持續集成框架，可以在我們提交項目的時候自動測試、運行和部署項目。雖然Jenkins使用Java編寫，但是由于Jenkins支持多種語言的項目，所以現在很多公司都是用Jenkins來進行項目的持續集成。
下載和安裝
Linux安裝
首先第一步就是下載和安裝Jenkins，我們可以到官網的下載頁面來下載。該頁面列出了常見的Linux系統、MacOS和Windows的安裝包。當然其實如果是Linux的話，不一定必須從官網下載，如果Linux軟件倉庫中有Jenkins的軟件包，也可以直接用對應的包管理工具安裝。
例如，對于ArchLinux系統來說，可以用下面的命令安裝Jenkins。
pacman -S jenkins
安裝完成之后，使用systemd啟動Jenkins。啟動之后，可以訪問瀏覽器的localhost:8090
來訪問Jenkins。
啟動Jenkinssudo systemctl start jenkins# 讓Jenkins開機自啟sudo systemctl start jenkins
對于其他Linux系統，參考相關文檔來了解如何安裝。
Windows安裝
Jenkins也支持Windows操作系統，直接在上面的官網下載鏈接中找到Windows系統對應的項目即可。這是一個MSI安裝包，我們可以和普通程序一樣安裝。安裝完成之后會自動打開瀏覽器的localhost:8080
頁面進入Jenkins。
Jenkins會以服務的方式運行在Windows系統中，不需要的時候可以關閉Jenkins服務。
Docker安裝
Docker作為一種非常方便的部署項目的方式，Jenkins自然也支持了。使用下面的命令就可以獲取Jenkins。
docker pull jenkins
下載完成之后，使用下面的命令啟動Jenkins鏡像。
docker run -p 8080:8080 -p 50000:50000 jenkins
然后就可以在瀏覽器的localhost:8080
端口訪問了。
使用Jenkins
初始化
第一次打開Jenkins的時候需要輸入Jenkins的安全密碼。在網頁上會給出改密碼的位置，如果是Windows系統，應該在類似D:\Program Files (x86)\Jenkins\secrets\initialAdminPassword
的路徑下。
Linux
然后需要安裝Jenkins插件，可以直接安裝推薦的插件，也可以自己手動選擇要安裝的插件。
安裝插件
然后就是創建用戶了。這一步我沒有截圖。
新建項目
創建完用戶之后，就可以新建項目了。一般情況下，選擇第一種自由風格的項目即可。
新建項目
之后輸入各種項目信息就行了，其中比較注意的一點就是源代碼管理這里了。Jenkins需要一個項目地址來拉取項目代碼。
配置項目
配置完畢之后就可以構建項目了。詳細的配置和使用可以參考相應文檔。
