柚子快報(bào)激活碼778899分享：運(yùn)維 DevOps

http://yzkb.51969.com/

一、DevOps 簡(jiǎn)介

指導(dǎo)思想，并不是技術(shù)

?背景：實(shí)戰(zhàn)中企業(yè)的IT職能劃分：研發(fā)部門：甲方（產(chǎn)品經(jīng)理）、乙方（項(xiàng)目經(jīng)理）——開(kāi)發(fā)部門（用什么開(kāi)發(fā)框架、什么語(yǔ)言、是否做微服務(wù)或單體架構(gòu)、開(kāi)發(fā)周期、開(kāi)發(fā)模式）——OPS運(yùn)維部門：分交付上線和部署上線，上線到測(cè)試環(huán)境或生產(chǎn)環(huán)境。包括是否做藍(lán)綠部署、灰度部署、滾動(dòng)發(fā)布，上線到哪個(gè)平臺(tái)，怎么負(fù)載均衡、上線后的穩(wěn)定性，監(jiān)控時(shí)長(zhǎng)?！獪y(cè)試部門：開(kāi)發(fā)周期中跟隨開(kāi)發(fā)人員進(jìn)行質(zhì)量監(jiān)測(cè)，工作是編寫測(cè)試用力、提交bug漏洞、對(duì)代碼結(jié)構(gòu)做質(zhì)量檢測(cè)。測(cè)試分為黑盒（只測(cè)功能）和白盒測(cè)試（編寫代碼能力，查看代碼功能）。

運(yùn)維擴(kuò)展崗位：實(shí)施、駐場(chǎng)、技術(shù)支持。

1.傳統(tǒng)開(kāi)發(fā)模型

①：軟件開(kāi)發(fā)生命周期（五個(gè)階段重）

階段1: 計(jì)劃和需求分析 (Planning and Requirement Analysis)

每個(gè)軟件開(kāi)發(fā)生命周期模型都從分析開(kāi)始，過(guò)程的利益相關(guān)者討論對(duì)最終產(chǎn)品的要求。此階段的目標(biāo)是系統(tǒng)要求的詳細(xì)定義。此外，還需要確保所有流程參與者都清楚地了解任務(wù)以及每個(gè)需求將如何實(shí)施。通常，討論涉及質(zhì)量保證專家，如果有必要，他們甚至可以在開(kāi)發(fā)階段干預(yù)過(guò)程中的添加。

階段2: 設(shè)計(jì)項(xiàng)目架構(gòu) (Project Architecture)

在軟件開(kāi)發(fā)生命周期的第二階段，開(kāi)發(fā)人員實(shí)際上正在設(shè)計(jì)架構(gòu)。所有利益相關(guān)者（包括客戶）都會(huì)討論此階段可能出現(xiàn)的所有不同技術(shù)問(wèn)題。此外，還定義了項(xiàng)目中使用的技術(shù)，團(tuán)隊(duì)負(fù)載，限制，時(shí)間范圍和預(yù)算。最合適的項(xiàng)目決策是根據(jù)定義的要求做出的。

階段3: 開(kāi)發(fā)和編程 (Development and Coding)

在批準(zhǔn)要求后，該過(guò)程進(jìn)入下一階段 - 實(shí)際開(kāi)發(fā)。程序員從這里開(kāi)始編寫源代碼，同時(shí)牢記先前定義的需求。系統(tǒng)管理員調(diào)整軟件環(huán)境，前端程序員開(kāi)發(fā)程序的用戶界面以及與服務(wù)器交互的邏輯。編程本身一般會(huì)用四個(gè)階段:算法開(kāi)發(fā),源代碼編寫,編譯,測(cè)試和調(diào)試

階段4: 測(cè)試 (Testing)

測(cè)試階段包括調(diào)試過(guò)程。開(kāi)發(fā)過(guò)程中遺漏的所有代碼缺陷都會(huì)在此處檢測(cè)到，記錄下來(lái)并傳回給開(kāi)發(fā)人員進(jìn)行修復(fù)。重復(fù)測(cè)試過(guò)程，直到刪除所有關(guān)鍵問(wèn)題并且軟件工作流程穩(wěn)定。

階段5: 部署 (Deployment)

當(dāng)程序最終確定并且沒(méi)有關(guān)鍵問(wèn)題時(shí) - 是時(shí)候?yàn)樽罱K用戶啟動(dòng)它了。新程序版本發(fā)布后，技術(shù)支持團(tuán)隊(duì)加入。該部門提供用戶反饋; 在利用期間咨詢和支持用戶。此外，此階段還包括所選組件的更新，以確保軟件是最新的，并且不會(huì)受到安全漏洞的影響。

②：SDLC模型 (Software Development Life cycle Model)

從第一個(gè)也是最古老的“瀑布式”SDLC模型演變而來(lái)，其種類不斷擴(kuò)大。比較常見(jiàn)的SDLC模型如下

瀑布模型 (Waterfall Model)

迭代模型 (Iterative Model)

螺旋模型 (Spiral Model)

V形模型 (V-Shape Model)： 單元測(cè)試，集成測(cè)試，系統(tǒng)測(cè)試，驗(yàn)收測(cè)試;適合高質(zhì)量的軟件環(huán)境，比如微軟。? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?

敏捷模型 (Agile Model)

【注】：

①?? 瀑布模型要求很嚴(yán)格，最終效果要和期望效果一致，缺點(diǎn)是開(kāi)發(fā)周期特別長(zhǎng)，每個(gè)階段必須完成相應(yīng)的功能。

②?? 敏捷開(kāi)發(fā)， 迭代開(kāi)發(fā)和增量開(kāi)發(fā)。好處在于哪里出問(wèn)題就只修改一小部分，不用從頭開(kāi)始。

迭代開(kāi)發(fā)：在之前的基礎(chǔ)上進(jìn)行迭代開(kāi)發(fā)。

增量開(kāi)發(fā)：在某些迭代開(kāi)發(fā)基礎(chǔ)上完善相關(guān)功能。軟件的每個(gè)版本，按照新增功能來(lái)劃分迭代。

?瀑布模型：

瀑布模型是早期實(shí)現(xiàn)的開(kāi)發(fā)模型,是一個(gè)級(jí)聯(lián)SDLC模型，其中開(kāi)發(fā)過(guò)程看起來(lái)像制造業(yè)的流水線，一步一步地進(jìn)行分析，預(yù)測(cè)，實(shí)現(xiàn)，測(cè)試，實(shí)施和支持階段。該SDLC模型包括完全逐步執(zhí)行每個(gè)階段。該過(guò)程嚴(yán)格記錄并預(yù)定義，具有該軟件開(kāi)發(fā)生命周期模型的每個(gè)階段所期望的功能。

敏捷開(kāi)發(fā)：

敏捷開(kāi)發(fā)的核心是迭代開(kāi)發(fā)(lterative Development)與增量開(kāi)發(fā)(IncrementalDevelopment) 。

迭代開(kāi)發(fā)：

對(duì)于大型軟件項(xiàng)目，傳統(tǒng)的開(kāi)發(fā)方式是采用一個(gè)大周期(比如一年或數(shù)年)進(jìn)行開(kāi)發(fā)，整個(gè)過(guò)程就是一次"大開(kāi)發(fā)"。迭代開(kāi)發(fā)的方式則不一樣，它將開(kāi)發(fā)過(guò)程拆分成多個(gè)小周期，即一次"大開(kāi)發(fā)"變成多次"小開(kāi)發(fā)"，每次小開(kāi)發(fā)都是同樣的流程，所以看上去就好像重復(fù)在做同樣的步驟

比如: 某公司生產(chǎn)手機(jī),第一次生產(chǎn)1代(比較簡(jiǎn)陋),逐年再生產(chǎn)2代,再到3代等

增量開(kāi)發(fā):

軟件的每個(gè)版本，都會(huì)新增一個(gè)可以被用戶感知到的完整功能。也就是說(shuō)，按照新增功能來(lái)劃分迭代。

比如: 房地產(chǎn)公司開(kāi)發(fā)一個(gè)小區(qū)。如果采用增量開(kāi)發(fā)的模式，該公司第一個(gè)迭代就是交付一期樓盤，第二個(gè)迭代交付二期樓盤…每個(gè)迭代都是完成一棟完整的樓盤。而不是第一個(gè)迭代挖好所有樓的地基，第二個(gè)迭代建好每棟樓的骨架，第三個(gè)迭代架設(shè)屋頂.....

雖然敏捷開(kāi)發(fā)將軟件開(kāi)發(fā)分成多個(gè)迭代，但是也要求，每次迭代都是一個(gè)完整的軟件開(kāi)發(fā)周期，必須按照軟件工程的方法論，進(jìn)行正規(guī)的流程管理。

敏捷開(kāi)發(fā)和瀑布開(kāi)發(fā)的區(qū)別：

①瀑布開(kāi)發(fā)周期很長(zhǎng)，敏捷開(kāi)發(fā)周期短。

②瀑布開(kāi)發(fā)開(kāi)發(fā)模式是線性的，很難看到結(jié)果，過(guò)程中出錯(cuò)風(fēng)險(xiǎn)大。敏捷開(kāi)發(fā)是小步快跑方式，基于增量和迭代方式進(jìn)行開(kāi)發(fā)，每次開(kāi)發(fā)關(guān)聯(lián)相關(guān)測(cè)試，

優(yōu)勢(shì)如下：

盡早交付,加快資金回籠

降級(jí)風(fēng)險(xiǎn),及時(shí)了解市場(chǎng)需求

提高效率,階段性功能折分及快速質(zhì)量反饋

敏捷開(kāi)發(fā)大幅提高了開(kāi)發(fā)團(tuán)隊(duì)的工作效率，讓版本的更新速度變得更快。

很多人可能會(huì)覺(jué)得，“更新版本的速度快了，風(fēng)險(xiǎn)不是更大了嗎？”其實(shí)，事實(shí)并非如此。

敏捷開(kāi)發(fā)可以幫助更快地發(fā)現(xiàn)問(wèn)題，產(chǎn)品被更快地交付到用戶手中，團(tuán)隊(duì)可以更快地得到用戶的反饋，從而進(jìn)行更快地響應(yīng)。而且，DevOps小步快跑的形式帶來(lái)的版本變化是比較小的，風(fēng)險(xiǎn)會(huì)更小（如下圖所示）。即使出現(xiàn)問(wèn)題，修復(fù)起來(lái)也會(huì)相對(duì)容易一些。

devops在現(xiàn)代化云原生平臺(tái)的應(yīng)用性

?

2.DevOps 介紹（什么是 DevOps）

DevOps 即開(kāi)發(fā) Development 和 Operations運(yùn)維的縮寫。

DevOps是一組過(guò)程、方法與系統(tǒng)的統(tǒng)稱，用于促進(jìn)開(kāi)發(fā)、技術(shù)運(yùn)營(yíng)和質(zhì)量保障（QA）部門之間的溝通、協(xié)作與整合。

DevOps 是針對(duì)開(kāi)發(fā)人員、運(yùn)維人員和測(cè)試人員的一種工作理念，是軟件在應(yīng)用開(kāi)發(fā)、代碼部署和質(zhì)量測(cè)試等整條生命周期中協(xié)作和溝通的最佳實(shí)踐

DevOps 強(qiáng)調(diào)整個(gè)組織的所有相關(guān)部門的緊密合作以及交付和基礎(chǔ)設(shè)施變更的自動(dòng)化、從而實(shí)現(xiàn)持續(xù)集成、持續(xù)部署和持續(xù)交付的目標(biāo)

基于CICD技術(shù)，去實(shí)現(xiàn)devops

補(bǔ)充：

構(gòu)建：將開(kāi)發(fā)好的代碼測(cè)試、編譯、打包、部署、上線、運(yùn)營(yíng)監(jiān)控的整體流程。

基于CICD技術(shù)去實(shí)現(xiàn)devops理念，CICD是一個(gè)技術(shù)棧。

Git是代碼控制、版本控制系統(tǒng)；gitlab私有代碼倉(cāng)庫(kù)；maven實(shí)現(xiàn)編譯流程；Nexus程序包倉(cāng)庫(kù)；docker容器和鏡像制作；harbor私有鏡像倉(cāng)庫(kù)；jmeter做性能測(cè)試，壓力測(cè)試；

其中開(kāi)發(fā)人員做應(yīng)用鏡像，運(yùn)維人員做系統(tǒng)鏡像和環(huán)境鏡像。

3：為什么要 DevOps

傳統(tǒng)的模式是開(kāi)發(fā)人員只關(guān)心開(kāi)發(fā)程序，追求功能的變化和實(shí)現(xiàn)

運(yùn)維只負(fù)責(zé)基礎(chǔ)環(huán)境管理和代碼部署及監(jiān)控等，更看重應(yīng)用的穩(wěn)定運(yùn)行

雙方缺少一個(gè)共同的目標(biāo)

DevOps 強(qiáng)調(diào)團(tuán)隊(duì)協(xié)作、相互協(xié)助、持續(xù)發(fā)展，實(shí)現(xiàn)團(tuán)隊(duì)作戰(zhàn)，即無(wú)論是開(kāi)發(fā)、運(yùn)維還是測(cè)試，都為了最終的代碼發(fā)布、持續(xù)部署和業(yè)務(wù)穩(wěn)定而付出各自的努力，從而實(shí)現(xiàn)產(chǎn)品設(shè)計(jì)、開(kāi)發(fā)、測(cè)試和部署的良性循環(huán)，實(shí)現(xiàn)產(chǎn)品的最終持續(xù)交付。

想要將DevOps真正落地，首先第一點(diǎn)，是思維轉(zhuǎn)變，也就是“洗腦”。不僅是運(yùn)維的要洗，開(kāi)發(fā)的也要洗。員工要洗，領(lǐng)導(dǎo)更要洗。DevOps并不僅僅是組織架構(gòu)變革，更是企業(yè)文化和思想觀念的變革。如果不能改變觀念，即使將員工放在一起，也不會(huì)產(chǎn)生火花。除了洗腦之外，就是根據(jù)DevOps思想重新梳理全流程的規(guī)范和標(biāo)準(zhǔn)。在DevOps的流程下，運(yùn)維人員會(huì)在項(xiàng)目開(kāi)發(fā)期間就介入到開(kāi)發(fā)過(guò)程中，了解開(kāi)發(fā)人員使用的系統(tǒng)架構(gòu)和技術(shù)路線，從而制定適當(dāng)?shù)倪\(yùn)維方案。而開(kāi)發(fā)人員也會(huì)在運(yùn)維的初期參與到系統(tǒng)部署中，并提供系統(tǒng)部署的優(yōu)化建議。DevOps的實(shí)施，促進(jìn)開(kāi)發(fā)和運(yùn)維人員的溝通，增進(jìn)彼此的理（gan）解（qing）。

4.DevOps 相關(guān)的軟件

DevOps 涉及的四大相關(guān)平臺(tái)

項(xiàng)目管理：如：Jira,禪道

代碼托管：如：Gitlab,SVN

持續(xù)交付：如：Jenkins,Gitlab

運(yùn)維平臺(tái)：如：騰訊藍(lán)鯨,Spug等

持續(xù)集成、持續(xù)交付和持續(xù)部署 CICD（重）

最初是瀑布模型，后來(lái)是敏捷開(kāi)發(fā)，現(xiàn)在是DevOps，這是現(xiàn)代開(kāi)發(fā)人員構(gòu)建出色的產(chǎn)品的技術(shù)路線。隨著DevOps的興起，出現(xiàn)了持續(xù)集成（Continuous Integration）、持續(xù)交付（Continuous Delivery） 、持續(xù)部署（Continuous Deployment） 的新方法。傳統(tǒng)的軟件開(kāi)發(fā)和交付方法正在迅速變得過(guò)時(shí)。從以前的敏捷時(shí)代，大多數(shù)公司會(huì)每月，每季度，每?jī)赡晟踔撩磕臧l(fā)布部署/發(fā)布軟件。然而現(xiàn)在在DevOps時(shí)代，每周，每天，甚至每天多次是常態(tài)。當(dāng)SaaS正在占領(lǐng)世界時(shí)，尤其如此，您可以輕松地動(dòng)態(tài)更新應(yīng)用程序，而無(wú)需強(qiáng)迫客戶下載新組件。很多時(shí)候，他們甚至都不會(huì)意識(shí)到正在發(fā)生變化。開(kāi)發(fā)團(tuán)隊(duì)通過(guò)軟件交付流水線（Pipeline）實(shí)現(xiàn)自動(dòng)化，以縮短交付周期，大多數(shù)團(tuán)隊(duì)都有自動(dòng)化流程來(lái)檢查代碼并部署到新環(huán)境。CI/CD 是一種通過(guò)在應(yīng)用開(kāi)發(fā)階段引入自動(dòng)化來(lái)頻繁向客戶交付應(yīng)用的方法。CI/CD 的核心概念是持續(xù)集成、持續(xù)交付和持續(xù)部署。作為一個(gè)面向開(kāi)發(fā)和運(yùn)營(yíng)團(tuán)隊(duì)的解決方案，CI/CD 主要針對(duì)在集成新代碼時(shí)所引發(fā)的問(wèn)題具體而言，CI/CD 可讓持續(xù)自動(dòng)化和持續(xù)監(jiān)控貫穿于應(yīng)用的整個(gè)生命周期（從集成和測(cè)試階段，到交付和部署）。這些關(guān)聯(lián)的事務(wù)通常被統(tǒng)稱為“CI/CD 管道”，由開(kāi)發(fā)和運(yùn)維團(tuán)隊(duì)以敏捷方式協(xié)同支持。和部署）。這些關(guān)聯(lián)的事務(wù)通常被統(tǒng)稱為“CI/CD 管道”，由開(kāi)發(fā)和運(yùn)維團(tuán)隊(duì)以敏捷方式協(xié)同支持。????????????? 此描述來(lái)源紅帽官網(wǎng) ????一文帶你看懂 CI/CD 是什么？

①持續(xù)集成 (CI-Continuous Integration)

集成指將多位開(kāi)發(fā)者的開(kāi)發(fā)代碼提交后,合并集成在一起,存放在代碼庫(kù)的過(guò)程,并且后續(xù)還會(huì)不斷的迭代更新代碼

持續(xù)集成是指多名開(kāi)發(fā)者在開(kāi)發(fā)不同功能代碼的過(guò)程當(dāng)中，可以頻繁的將代碼行合并到一起并切相互不影響工作。很多情況下每天都要進(jìn)行幾次，主要目的是盡早發(fā)現(xiàn)集成錯(cuò)誤，使團(tuán)隊(duì)更加緊密結(jié)合，更好地協(xié)作。

CI屬于開(kāi)發(fā)人員的自動(dòng)化流程。成功的 CI 意味著應(yīng)用代碼的新更改會(huì)定期構(gòu)建、測(cè)試并合并到共享存儲(chǔ)庫(kù)中。該解決方案可以解決在一次開(kāi)發(fā)中有太多應(yīng)用分支，從而導(dǎo)致相互沖突的問(wèn)題。

持續(xù)集成強(qiáng)調(diào)開(kāi)發(fā)人員提交了新代碼之后，立刻進(jìn)行構(gòu)建、（單元）測(cè)試。根據(jù)測(cè)試結(jié)果，可以確定新代碼和原有代碼能否正確地集成在一起。通過(guò)持續(xù)集成可以自動(dòng)編譯、打包、簽名項(xiàng)目，配合單元測(cè)試可以實(shí)現(xiàn)持續(xù)集成+自動(dòng)化測(cè)試。讓工程師從重復(fù)而又枯燥的手動(dòng)打包完全解放出來(lái)，讓工程師能更加專注于代碼本身，最大限度的減少誤操作風(fēng)險(xiǎn)，降低修復(fù)錯(cuò)誤代碼的成本，大幅提高工作效率。

CICD 流程（重）

?

開(kāi)發(fā)人員不斷的進(jìn)行代碼提交到本地，再提交到運(yùn)程的代碼倉(cāng)庫(kù)服務(wù)器

Jenkins作為持續(xù)集成工具，使用Git工具到Git倉(cāng)庫(kù)拉取代碼到集成服務(wù)器，代碼測(cè)試與審查，再配合JDK，Maven，Go等軟件完成代碼編譯，測(cè)試，打包等工作，在這個(gè)過(guò)程中每一步如果出錯(cuò)，都需要重新再執(zhí)行一次整個(gè)流程。

Jenkins把生成的軟件jar或war包等分發(fā)到測(cè)試服務(wù)器或者生產(chǎn)服務(wù)器，測(cè)試人員或用戶就可以訪問(wèn)應(yīng)用。

②：持續(xù)交付(CD-Continuous Delivery)測(cè)試環(huán)境

完成 CI 中構(gòu)建及單元測(cè)試和集成測(cè)試的自動(dòng)化流程后，持續(xù)交付可以自動(dòng)的將已驗(yàn)證的代碼發(fā)布到存儲(chǔ)庫(kù)。為了實(shí)現(xiàn)高效的持續(xù)交付流程，務(wù)必要確保 CI 已內(nèi)置于開(kāi)發(fā)管道。持續(xù)交付的目標(biāo)是擁有一個(gè)可隨時(shí)部署到生產(chǎn)環(huán)境的代碼庫(kù)。

在持續(xù)交付中，每個(gè)階段（從代碼更改的合并，到生產(chǎn)就緒型構(gòu)建版本的交付）都涉及測(cè)試自動(dòng)化和代碼發(fā)布自動(dòng)化。在流程結(jié)束時(shí)，運(yùn)維團(tuán)隊(duì)可以快速、輕松地將應(yīng)用部署到生產(chǎn)環(huán)境中。

持續(xù)交付完成了構(gòu)建和測(cè)試過(guò)程細(xì)致的自動(dòng)化，但是如何發(fā)布以及發(fā)布什么仍然是需要人工操作，持續(xù)部署可以改變這一點(diǎn)。

持續(xù)集成（CONTINUOUS INTEGRATION，CI）指的是開(kāi)發(fā)人員頻繁的（一天多次的）將所有開(kāi)發(fā)者的工作合并到主干上。這些新提交在最終合并到主線之前，都需要通過(guò)編譯和自動(dòng)化測(cè)試流進(jìn)行驗(yàn)證，以保障所有的提交在合并主干之后的質(zhì)量問(wèn)題，對(duì)可能出現(xiàn)的一些問(wèn)題進(jìn)行預(yù)警。持續(xù)集成的核心在于確保新增的代碼能夠與原先代碼正確的集成。

持續(xù)交付在持續(xù)集成的基礎(chǔ)上，將集成后的代碼部署到更貼近真實(shí)運(yùn)行環(huán)境的「類生產(chǎn)環(huán)境」（production-like environments）中。比如，我們完成單元測(cè)試后，可以把代碼部署到連接數(shù)據(jù)庫(kù)的Staging 環(huán)境中更多的測(cè)試。如果代碼沒(méi)有問(wèn)題，可以繼續(xù)手動(dòng)部署到生產(chǎn)環(huán)境中。此方式是當(dāng)前普遍采用的方式

③：持續(xù)部署(CD-Continuous Deployment)開(kāi)發(fā)環(huán)境

對(duì)于一個(gè)成熟的 CI/CD 管道來(lái)說(shuō)，最后的階段是持續(xù)部署。作為持續(xù)交付(自動(dòng)將生產(chǎn)就緒型構(gòu)建版本發(fā)布到代碼存儲(chǔ)庫(kù))的進(jìn)一步延伸，持續(xù)部署可以自動(dòng)將應(yīng)用發(fā)布到生產(chǎn)環(huán)境。由于在生產(chǎn)之前的管道階段沒(méi)有手動(dòng)風(fēng)控，因此持續(xù)部署在很大程度上都得依賴精心設(shè)計(jì)的測(cè)試自動(dòng)化。實(shí)際上，持續(xù)部署意味著開(kāi)發(fā)人員對(duì)應(yīng)用的更改在編寫后的幾分鐘內(nèi)就能生效（假設(shè)它通過(guò)了自動(dòng)化測(cè)試）。這更加便于持續(xù)接收和整合用戶反饋?？偠灾?，所有這些 CI/CD 的關(guān)聯(lián)步驟都有助于降低應(yīng)用的部署風(fēng)險(xiǎn)，因此更便于以小件的方式（而非一次性）發(fā)布對(duì)應(yīng)用的更改。不過(guò)，由于還需要編寫自動(dòng)化測(cè)試以適應(yīng) CI/CD 管道中的各種測(cè)試和發(fā)布階段，因此前期投資還是會(huì)很大。持續(xù)部署是基于某種工具或平臺(tái)實(shí)現(xiàn)代碼自動(dòng)化的構(gòu)建、測(cè)試和部署到線上環(huán)境以實(shí)現(xiàn)交付高質(zhì)量的產(chǎn)品,持續(xù)部署在某種程度上代表了一個(gè)開(kāi)發(fā)團(tuán)隊(duì)的更新迭代速率。與持續(xù)集成相比，持續(xù)交付（CONTINUOUS DELIVERY，CD）的側(cè)重點(diǎn)在于交付，其核心對(duì)象不在于代碼，而在于可交付的產(chǎn)物。由于持續(xù)集成僅僅針對(duì)于新舊代碼的集成過(guò)程執(zhí)行了一定的測(cè)試，其變動(dòng)到持續(xù)交付后還需要一些額外的流程。與持續(xù)集成相比較，持續(xù)交付添加了測(cè)試Test->模擬Staging->生產(chǎn)Production的流程，也就是為新增的代碼添加了一個(gè)保證：確保新增的代碼在生產(chǎn)環(huán)境中是可用的。在持續(xù)交付的基礎(chǔ)上，把部署到生產(chǎn)環(huán)境的過(guò)程自動(dòng)化。如果你對(duì)比上圖持續(xù)部署就可以發(fā)現(xiàn)持續(xù)部署和持續(xù)交付的區(qū)別就是最終部署到生產(chǎn)環(huán)境是自動(dòng)化的。因?yàn)樽詣?dòng)發(fā)布存在較大的風(fēng)險(xiǎn),當(dāng)前采用此方式較少

持續(xù)交付的目的就是擁有一個(gè)可隨時(shí)部署到生產(chǎn)環(huán)境的代碼庫(kù)，并確保以最少的工作量部署新代碼。可以理解為持續(xù)交付是交付到測(cè)試環(huán)境；持續(xù)部署是部署到生產(chǎn)環(huán)境。

CI屬于開(kāi)發(fā)人員的自動(dòng)化流程；CD屬于運(yùn)維人員的自動(dòng)化。

Devops的核心功能是實(shí)現(xiàn)CICD流水線的自動(dòng)化。

持續(xù)交付已自動(dòng)化，持續(xù)部署不能完全自動(dòng)化，仍需手動(dòng)部署到生產(chǎn)環(huán)境。

④：CICD 流程過(guò)程和架構(gòu)

應(yīng)用部署發(fā)展階段

開(kāi)發(fā)人員自行上傳代碼

早期項(xiàng)目,沒(méi)有專業(yè)的運(yùn)維人員,運(yùn)維的工作由開(kāi)發(fā)兼職完成,項(xiàng)目發(fā)布很不專業(yè),很容易出錯(cuò),也是最原始的方式

開(kāi)發(fā)人員先將代碼發(fā)給運(yùn)維,再由運(yùn)維人員手動(dòng)上傳至生產(chǎn)環(huán)境專業(yè)的運(yùn)維人員完成應(yīng)用的部署,每次項(xiàng)目發(fā)布都由運(yùn)維人員一步一步手動(dòng)實(shí)現(xiàn),效率低下且容易出錯(cuò)，運(yùn)維利用腳本和自動(dòng)化運(yùn)維工具實(shí)現(xiàn)部署，由運(yùn)維人員編寫Shell,Python等腳本或利用自動(dòng)化運(yùn)維工具,如Ansible等實(shí)現(xiàn)半自動(dòng)化應(yīng)用部署,效率很高,但對(duì)技術(shù)的專業(yè)性有較高要求通過(guò) Web 等 GUI 界面實(shí)現(xiàn)一鍵自動(dòng)化部署，可以通過(guò)開(kāi)源或自研的運(yùn)維平臺(tái)實(shí)現(xiàn)方便的應(yīng)用部署,操作容易,效率高,但需要提前構(gòu)建運(yùn)維平臺(tái)

⑤：常見(jiàn)的CICD工具

K8s環(huán)境的CICD是將代碼制作成鏡像后發(fā)布到各個(gè)pod中，如果是openstack，就是將代碼發(fā)布到一個(gè)個(gè)實(shí)例中；普通模式是將代碼發(fā)布到服務(wù)器中。

整個(gè)CICD流程核心是Jenkins，它實(shí)質(zhì)沒(méi)有特定功能，通過(guò)調(diào)用別的軟件去執(zhí)行某些相應(yīng)功能。

⑦：Kubernetes 環(huán)境的 CICD

⑧：CICD流程結(jié)合服務(wù)器架構(gòu)

二、版本控制系統(tǒng)VCS詳解

版本控制系統(tǒng)（Version Control System，VCS）是一種軟件，可以幫助軟件團(tuán)隊(duì)的開(kāi)發(fā)人員協(xié)同工作，并存檔他們工作的完整歷史記錄。

為什么使用 VCS ?

在實(shí)際開(kāi)發(fā)過(guò)程中，經(jīng)常會(huì)有這種需求或問(wèn)題

代碼可能被破壞,比如誤刪除等,希望還能找回

代碼出現(xiàn)了嚴(yán)重的Bug,希望回滾至數(shù)周前的舊代碼

需要在已經(jīng)發(fā)布的程序中添加新的功能，如果測(cè)試驗(yàn)證后沒(méi)有問(wèn)題，才會(huì)使用新的代碼，而在測(cè)試

驗(yàn)證期間，不能影響原來(lái)的代碼

同一個(gè)軟件需要有多個(gè)版本并行開(kāi)發(fā),滿足不同的應(yīng)用需求

實(shí)際項(xiàng)目開(kāi)發(fā)基本都是多個(gè)人合作完成，在多個(gè)人寫代碼時(shí)，就牽扯到代碼合并成一份的問(wèn)題。

1：版本控制系統(tǒng)分類

①：本地版本控制系統(tǒng)

第一代版本控制系統(tǒng)被稱為本地版本控制系統(tǒng)。通過(guò)加鎖將并發(fā)執(zhí)行轉(zhuǎn)換成順序執(zhí)行。 一次只能有一個(gè)人處理文件。

具體流程如下：首先，應(yīng)該把文件放在一個(gè)服務(wù)器上，方便使用者上傳或下載文件；其次，任何人想對(duì)文件修改時(shí)，需要先把這個(gè)文件加鎖，通過(guò)checkout指令，使得其他人無(wú)法修改；最后，當(dāng)修改完成之后，需要釋放鎖，通過(guò)checkin指令，形成一個(gè)新的版本，存放到服務(wù)器端。

第一代版本控制系統(tǒng)主要有 RCS、SCCS（1972年發(fā)布）和 DSEE（被認(rèn)為是 Atria ClearCase 的前身）。目前，有些項(xiàng)目還在使用！

用戶想要完成任何的提交和回滾都依賴于連接集中的代碼服務(wù)器才能實(shí)現(xiàn),比如下班回家后,如果無(wú)法連接至代碼的服務(wù)器,將無(wú)法提交代碼；此外此服務(wù)器還存在單點(diǎn)問(wèn)題

③：分布式版本控制系統(tǒng)

在每個(gè)用戶都有一個(gè)完整的服務(wù)器，然后再部署一個(gè)中央服務(wù)器；用戶可以先將代碼提交到本地，沒(méi)有網(wǎng)絡(luò)也可以先提交到本地，然后在有網(wǎng)絡(luò)的時(shí)候再提交到中央服務(wù)器，這樣就大大方便了開(kāi)發(fā)者

相比集中式的版本控制系統(tǒng)，工作的時(shí)候需要先從中央服務(wù)器獲取最新的代碼，改完之后需要提交，如果是一個(gè)比較大的文件則需要足夠快的網(wǎng)絡(luò)才能快速提交完成,而使用分布式的版本控制系統(tǒng)，每個(gè)用戶都是一個(gè)完整的版本庫(kù)，即使沒(méi)有中央服務(wù)器也可以提交代碼或者回滾，最終再把改好的代碼提交至中央服務(wù)器進(jìn)行合并即可。

svn集中式版本控制系統(tǒng)和git分布式版本控制系統(tǒng)的區(qū)別：

① svn集中式需要連網(wǎng)絡(luò)到中央服務(wù)器；而git分布式代碼的提交和回滾是不依賴網(wǎng)絡(luò)的，不用依賴中央服務(wù)器，只有在將最終成品提交到中央服務(wù)器需要網(wǎng)絡(luò)。

②git是分布式的,svn是集中式的

git是每個(gè)歷史版本都存儲(chǔ)完整的文件,便于恢復(fù),svn是存儲(chǔ)差異文件

git可離線完成大部分操作,svn則不能

git有著更優(yōu)雅的分支和合并實(shí)現(xiàn)

git有著更強(qiáng)的撤銷修改和修改歷史版本的能力

git速度更快,效率更高

2：常見(jiàn)版本控制系統(tǒng)簡(jiǎn)介

①集中式版本控制系統(tǒng)svn

SVN 依賴于網(wǎng)絡(luò)，需要在各個(gè)開(kāi)發(fā)主機(jī)上安裝客戶端軟件,并且在一臺(tái)服務(wù)器集中進(jìn)行版本管理和存儲(chǔ).目前依然有部分公司在使用

優(yōu)點(diǎn)：

管理方便，邏輯明確，符合一般人思維習(xí)慣。

易于管理，集中式服務(wù)器更能保證安全性。

代碼一致性非常高。

適合開(kāi)發(fā)人數(shù)不多的項(xiàng)目開(kāi)發(fā)。

缺點(diǎn)：

服務(wù)器壓力太大，數(shù)據(jù)庫(kù)容量暴增。

如果不能連接到服務(wù)器上，基本上不可以工作，如果服務(wù)器不能連接上，就不能提交，還原，對(duì)比等等。

不適合開(kāi)源開(kāi)發(fā)（開(kāi)發(fā)人數(shù)非常非常多，但是Google app engine就是用svn的）。但是一般集中式管理的有非常明確的權(quán)限管理機(jī)制（例如分支訪問(wèn)限制），可以實(shí)現(xiàn)分層管理，從而很好的解決開(kāi)發(fā)人數(shù)眾多的問(wèn)題。

②分布式版本控制系統(tǒng)git

在 Linux 開(kāi)源的初期，Linux 開(kāi)源項(xiàng)目的代碼是 linus 本人通過(guò) linux 命令 diff 和 patch 兩條命令手動(dòng)完成。隨著 Linux 代碼越來(lái)越壯大，靠 Linus 一個(gè)人來(lái)手動(dòng)合并已經(jīng)不現(xiàn)實(shí)。2002 年，Linus 選擇了一個(gè)商業(yè)版本控制系統(tǒng) BitKeeper 作為 Linux 內(nèi)核的代碼管理工具（BitKeeper 的開(kāi)發(fā)商 BitMover 授權(quán)l(xiāng)inux 社區(qū)免費(fèi)使用）。但是，免費(fèi)使用是有很多的限制的，因此 linux 社區(qū)的大佬開(kāi)始破解BitKeeper。其中，samba 的作者 andrew 破解成功了。但是被 BitMover 公司發(fā)現(xiàn)，收回免費(fèi)使用權(quán)。

迫不得已，Linus 選擇了自己開(kāi)發(fā)一個(gè)分布式版本控制工具以替代 BitKeeper。linus 閉關(guān)一個(gè)月，寫出了 Git。在一個(gè)月后，Git 成功接管了 Linux 社區(qū)的版本控制工作，并且開(kāi)始開(kāi)源。

Git 重要特性:

在本地就可以完成提交,因此不需要網(wǎng)絡(luò),提交完成后,可以有網(wǎng)絡(luò)環(huán)境時(shí),再同步到遠(yuǎn)程倉(cāng)庫(kù)服務(wù)器

優(yōu)點(diǎn)：

適合分布式開(kāi)發(fā)，強(qiáng)調(diào)個(gè)體。

公共服務(wù)器壓力和數(shù)據(jù)量都不會(huì)太大。

速度快、靈活。

任意兩個(gè)開(kāi)發(fā)者之間可以很容易的解決沖突。

支持離線工作。

缺點(diǎn)：

不符合常規(guī)思維。

學(xué)習(xí)周期相對(duì)而言比較長(zhǎng)。

代碼保密性差，一旦開(kāi)發(fā)者把整個(gè)庫(kù)克隆下來(lái)就可以完全公開(kāi)所有代碼和版本信息。

③：Github 網(wǎng)站

2008年1月，Wanstrath和Preston-Werner推出使用Ruby on Rails編寫而成的GitHub的個(gè)人測(cè)試版。2月，他們又增加了第三位聯(lián)合創(chuàng)始人PJ Hyett，到2008年3月，GitHub的beta版已經(jīng)擁有了2000名用戶。GitHub于2008年4月推出公共版本，然后逐漸在開(kāi)發(fā)者社區(qū)中流行起來(lái)，到2009年7月，用戶數(shù)量達(dá)到了10萬(wàn)。

由于GitHub在軟件開(kāi)發(fā)人員中很受歡迎，成立后的四年，GitHub通過(guò)向個(gè)人程序員和企業(yè)收取每月訪問(wèn)平臺(tái)的費(fèi)用，在沒(méi)有外部資金的情況下得以生存下來(lái)。

GitHub網(wǎng)站為開(kāi)源項(xiàng)目免費(fèi)提供Git存儲(chǔ)，無(wú)數(shù)開(kāi)源項(xiàng)目開(kāi)始遷移至GitHub，包括jQuery，PHP，Ruby等等。GitHub同時(shí)提供付費(fèi)賬戶和免費(fèi)賬戶。這兩種賬戶都可以創(chuàng)建公開(kāi)的代碼倉(cāng)庫(kù)，但是只有付費(fèi)賬戶可以創(chuàng)建私有的代碼倉(cāng)庫(kù)。

2018年6月5日 微軟花費(fèi) 75 億美元收購(gòu) GitHub

2019年1月7日 免費(fèi)的 GitHub 用戶現(xiàn)在可以獲得不受限制的私人項(xiàng)目，最多可以有三個(gè)協(xié)同合作者

2005年4月3日，開(kāi)始開(kāi)發(fā) Git。

2005年4月6日，項(xiàng)目發(fā)布。

2005年4月7日，Git就可以作為自身的版本控制工具了。

2005年4月18日，發(fā)生第一個(gè)多分支合并。

2005年4月29日，Git 的性能就已經(jīng)達(dá)到了 Linus 的預(yù)期。

2005年6月16日，Linux 2.6.12 發(fā)布，那時(shí) Git 已經(jīng)在維護(hù) Linux 核心的源代碼了。

2005年7月26日，Linus 功成身退，將 Git 的維護(hù)交給另外一個(gè) Git 的主要貢獻(xiàn)者 Junio C Hamano。

2016年5月，BitKeeper宣布使用 Apache 2.0許可證開(kāi)源。

2020年4月14日 GitHub宣布向所有用戶和團(tuán)隊(duì)提供不限制協(xié)作人數(shù)的私有倉(cāng)庫(kù)，同時(shí)GitHub的核心功能對(duì)所有人免費(fèi)開(kāi)放

官網(wǎng): http://www.github.com

3：常見(jiàn)的軟件部署模式（重）

①：藍(lán)綠部署 Blue-green Deployments

藍(lán)綠部署指的是不停止老版本代碼(不影響上一個(gè)版本訪問(wèn))，而是在另外一套環(huán)境部署新版本然后進(jìn)行測(cè)試，測(cè)試通過(guò)后將用戶流量切到新版本，其特點(diǎn)為業(yè)務(wù)無(wú)中斷，升級(jí)風(fēng)險(xiǎn)相對(duì)較小。但本方式成本較高,一般小公司較少使用

藍(lán)綠色部署是一種部署策略，利用兩種相同的環(huán)境，即"藍(lán)色"（又名預(yù)發(fā)布）環(huán)境和"綠色"（又名生產(chǎn)）環(huán)境，具有不同版本的應(yīng)用程序或服務(wù)。質(zhì)量保證和用戶接受度測(cè)試通常在承載新版本或更改的藍(lán)色環(huán)境中進(jìn)行。一旦藍(lán)色環(huán)境中測(cè)試并接受新的變化，用戶流量就會(huì)從綠色環(huán)境轉(zhuǎn)變?yōu)樗{(lán)色環(huán)境。然后，一旦部署成功，您可以切換到新環(huán)境。

具體過(guò)程：

1、當(dāng)前版本(V1)業(yè)務(wù)正常訪問(wèn)

2、在另外一套環(huán)境部署新代碼版本(V2)，代碼可能是增加了功能或者是修復(fù)了某些bug

3、測(cè)試通過(guò)之后將用戶請(qǐng)求流量切到新版本環(huán)境

4、觀察一段時(shí)間，如有異常直接切換舊版本

5、下次升級(jí)，將舊版本(V2)升級(jí)到新版本(V3)命名卷: 指定數(shù)據(jù)卷的名稱和容器路徑的掛載關(guān)系，此方式會(huì)創(chuàng)建命名數(shù)據(jù)卷

藍(lán)綠部署適用的場(chǎng)景：

1、不停止老版本，額外部署一套新版本，等測(cè)試確認(rèn)新版本正常后，才將用戶請(qǐng)求切換至新版本，如果有問(wèn)題，切換回老版本

2、藍(lán)綠發(fā)布是一種用于升級(jí)與更新的發(fā)布策略，部署的最小維度是容器，而發(fā)布的最小維度是應(yīng)用。

3、藍(lán)綠發(fā)布對(duì)于增量升級(jí)有比較好的支持，但是對(duì)于涉及數(shù)據(jù)表結(jié)構(gòu)變更等等不可逆轉(zhuǎn)的升級(jí)，并不完全合適用藍(lán)綠發(fā)布來(lái)實(shí)現(xiàn)，需要結(jié)合一些業(yè)務(wù)的邏輯以及數(shù)據(jù)遷移與回滾的策略才可以完全滿足需求。

②：金絲雀(灰度)發(fā)布 Canary Deployment

金絲雀發(fā)布也叫灰度發(fā)布，是指在黑與白之間，能夠平滑過(guò)渡的一種發(fā)布方式，灰度發(fā)布是增量發(fā)布（例如：2%、25%、75%、100%）進(jìn)行更新)的一種類型，灰度發(fā)布是在原有版本可用的情況下，同時(shí)部署一個(gè)新版本應(yīng)用作為“金絲雀”(小白鼠)，測(cè)試新版本的性能和表現(xiàn)，以保障整體系統(tǒng)穩(wěn)定的情況下，盡早發(fā)現(xiàn)、調(diào)整問(wèn)題。因此，灰度發(fā)布可以保證整體系統(tǒng)的穩(wěn)定，在初始灰度的時(shí)候就可以發(fā)現(xiàn)、調(diào)整問(wèn)題，以保證其影響度。此方式在實(shí)際生產(chǎn)中使用較為普遍

金絲雀/灰度發(fā)布步驟組成：

1、準(zhǔn)備好部署各個(gè)階段的工件，包括：構(gòu)建組件，測(cè)試腳本，配置文件和部署清單文件。

2、從負(fù)載均衡列表中移除掉“金絲雀”服務(wù)器（選擇全部服務(wù)器中的一部分）。

3、升級(jí)“金絲雀”應(yīng)用（排掉原有流量并進(jìn)行部署）。

4、對(duì)應(yīng)用進(jìn)行自動(dòng)化測(cè)試。

5、將“金絲雀”服務(wù)器重新添加到負(fù)載均衡列表中（連通性和健康檢查）。

6、如果“金絲雀”在線使用測(cè)試成功，升級(jí)剩余的其他服務(wù)器。否則就回滾回舊版本

金絲雀/灰度發(fā)布部署適用的場(chǎng)景：

1、不停止老版本，額外搞一套新版本，不同版本應(yīng)用共存。

2、灰度發(fā)布中，常常按照用戶設(shè)置路由權(quán)重，例如90%的用戶維持使用老版本，10%的用戶嘗鮮新版

本。

3.經(jīng)常與A/B測(cè)試一起使用，用于測(cè)試選擇多種方案。

A/B測(cè)試是效果測(cè)試，同一時(shí)間有多個(gè)版本的服務(wù)對(duì)外服務(wù)，這些服務(wù)都是經(jīng)過(guò)足夠測(cè)試，達(dá)到了上線標(biāo)準(zhǔn)的服務(wù)，有差異但是沒(méi)有新舊之分（它們上線時(shí)可能采用了藍(lán)綠部署的方式）。

A/B測(cè)試關(guān)注的是不同版本的服務(wù)的實(shí)際效果，譬如說(shuō)轉(zhuǎn)化率、訂單情況等。

A/B測(cè)試時(shí)，線上同時(shí)運(yùn)行多個(gè)版本的服務(wù)，這些服務(wù)通常會(huì)有一些體驗(yàn)上的差異，譬如說(shuō)頁(yè)面樣式、顏色、操作流程不同。相關(guān)人員通過(guò)分析各個(gè)版本服務(wù)的實(shí)際效果，選出效果最好的版本。

③：滾動(dòng)發(fā)布(更新)

滾動(dòng)發(fā)布故名思議，就是逐步升級(jí)服務(wù)中的節(jié)點(diǎn)

滾動(dòng)發(fā)布是指每次只升級(jí)一個(gè)或多個(gè)服務(wù)實(shí)例，升級(jí)完成后加入生產(chǎn)環(huán)境，不斷執(zhí)行這個(gè)過(guò)程，直到集群中的全部舊版本升級(jí)新版本。

在金絲雀發(fā)布基礎(chǔ)上的進(jìn)一步優(yōu)化改進(jìn)，是一種自動(dòng)化程度較高的發(fā)布方式，用戶體驗(yàn)比較平滑，是目前成熟型技術(shù)組織所采用的主流發(fā)布方式。

①定義

滾動(dòng)發(fā)布：一般是取出一個(gè)或者多個(gè)服務(wù)器停止服務(wù)，執(zhí)行更新，并重新將其投入使用。周而復(fù)始，直到集群中所有的實(shí)例都更新成新版本。

②特點(diǎn)

這種部署方式相對(duì)于藍(lán)綠部署，更加節(jié)約資源——它不需要運(yùn)行兩個(gè)集群、兩倍的實(shí)例數(shù)。我們可以部分部署，例如每次只取出集群的 20% 進(jìn)行升級(jí)。

③部署過(guò)程

滾動(dòng)式發(fā)布一般先發(fā)1臺(tái)，或者一個(gè)小比例，如2% 服務(wù)器，主要做流量驗(yàn)證用，類似金絲雀 (Canary) 測(cè)試。

滾動(dòng)式發(fā)布需要比較復(fù)雜的發(fā)布工具和智能 LB，支持平滑的版本替換和流量拉入拉出。

每次發(fā)布時(shí)，先將老版本V1流量從LB上摘除，然后清除老版本，發(fā)新版本V2，再將LB流量接入新版本。這樣可以盡量保證用戶體驗(yàn)不受影響。

一次滾動(dòng)式發(fā)布一般由若干個(gè)發(fā)布批次組成，每批的數(shù)量一般是可以配置的（可以通過(guò)發(fā)布模板定義）。例如第一批 1 臺(tái)（金絲雀），第二批 10%，第三批 50%，第四批 100%。每個(gè)批次之間留觀察間隔，通過(guò)手工驗(yàn)證或監(jiān)控反饋確保沒(méi)有問(wèn)題再發(fā)下一批次，所以總體上滾動(dòng)式發(fā)布過(guò)程是比較緩慢的 (其中金絲雀的時(shí)間一般會(huì)比后續(xù)批次更長(zhǎng)，比如金絲雀 10 分鐘，后續(xù)間隔 2 分鐘)。

回退是發(fā)布的逆過(guò)程，將新版本流量從 LB 上摘除，清除新版本，發(fā)老版本，再將 LB 流量接入老版本。和發(fā)布過(guò)程一樣，回退過(guò)程一般也比較慢的。

④優(yōu)勢(shì)和不足

優(yōu)勢(shì)：用戶體驗(yàn)影響小，體驗(yàn)較平滑。

不足：

-- 發(fā)布和回退時(shí)間比較緩慢。

-- 發(fā)布工具比較復(fù)雜，LB 需要平滑的流量摘除和拉入能力。

總結(jié)：

① 藍(lán)綠部署：準(zhǔn)備兩套環(huán)境，一套在線用，一套備用的新版本，在環(huán)境前做負(fù)載均衡，不影響老版本的基礎(chǔ)上上線新版本。

②（金絲雀）灰度發(fā)布：是增量發(fā)布的一種類型。方法是保留部分老版本的同時(shí)，一點(diǎn)點(diǎn)發(fā)布新版本，進(jìn)行測(cè)試和調(diào)整。K8S中使用的就是灰度發(fā)布。

③?? 滾動(dòng)發(fā)布：一般是取出一個(gè)或者多個(gè)服務(wù)器停止服務(wù)，執(zhí)行更新，并重新將其投入使用。周而復(fù)始，直到集群中所有的實(shí)例都更新成新版本。

三、devops之git

①：git和SVN區(qū)別（重）

git是分布式的,svn是集中式的

git是每個(gè)歷史版本都存儲(chǔ)完整的文件,便于恢復(fù),svn是存儲(chǔ)差異文件

git可離線完成大部分操作,svn則不能

git有著更優(yōu)雅的分支和合并實(shí)現(xiàn)

git有著更強(qiáng)的撤銷修改和修改歷史版本的能力

git速度更快,效率更高

②：git版本控制的原理和流程

工作區(qū) workspace：clone的代碼或者開(kāi)發(fā)編寫代碼文件所在的目錄 ，通常是一個(gè)服務(wù)代碼所在的目錄名稱 ,對(duì)應(yīng)于<項(xiàng)目目錄>

暫存區(qū)index ：用于存儲(chǔ)在工作區(qū)中對(duì)代碼進(jìn)行修改后的文件所保存的地方，只有放入此區(qū)的文件才能被git進(jìn)行管理,使用 git add添加,對(duì)應(yīng)為<項(xiàng)目目錄>/.git/index文件

本地倉(cāng)庫(kù)repo： 用于存儲(chǔ)在工作區(qū)和暫存區(qū)中改過(guò)并提交的文件地方，使用 git commit 提交,對(duì)應(yīng)于/<項(xiàng)目目錄>/.git/

遠(yuǎn)程倉(cāng)庫(kù) ：多個(gè)開(kāi)發(fā)人員共同協(xié)作提交代碼的倉(cāng)庫(kù)，即私有 gitlab 服務(wù)器或公有云github,gitee網(wǎng)站等

③：git中文件的狀態(tài)變化周期

untracked: 在工作目錄下創(chuàng)建的新文件，這個(gè)時(shí)候本地git倉(cāng)庫(kù)不知道,不能對(duì)其進(jìn)行版本跟蹤管理

unmodified: 添加到暫存區(qū)的文件未修改,把文件從暫存區(qū)推動(dòng)到本地倉(cāng)庫(kù)

modified: 已經(jīng)添加到暫存區(qū)的文件,在本地工作區(qū)的文件被修改了 ,需要重新添加至?xí)捍鎱^(qū)

staged: 文件添加到了本地倉(cāng)庫(kù)里面的暫存區(qū)

④：Git分支和標(biāo)簽

分支: 對(duì)文件的副本,可以實(shí)現(xiàn)多個(gè)不同用途的軟件版本同時(shí)的演進(jìn),實(shí)現(xiàn)多個(gè)開(kāi)發(fā)版本的隔離

分支在實(shí)際中有什么用呢？

假設(shè)你準(zhǔn)備開(kāi)發(fā)一個(gè)新功能，但是需要兩周才能完成，第一周你寫了50%的代碼，如果立刻提交，由于代碼還沒(méi)寫完，不完整的代碼庫(kù)會(huì)導(dǎo)致別人不能測(cè)試等工作。如果等代碼全部寫完再一次提交，又存在丟失每天進(jìn)度的巨大風(fēng)險(xiǎn)?，F(xiàn)在有了分支，就不用擔(dān)心了。你創(chuàng)建了一個(gè)獨(dú)立的分支，對(duì)其他人是透明的,沒(méi)有影響,他們還繼續(xù)在原來(lái)的分支上正常工作，而你在自己的分支上工作，想提交就提交，直到開(kāi)發(fā)完畢后，再一次性合并到原來(lái)的分支上，這樣既安全，又不影響別人工作。

tag: 給某個(gè)狀態(tài)打個(gè)標(biāo)簽用于記錄當(dāng)前狀態(tài),相當(dāng)于里程碑

tag是git版本庫(kù)的一個(gè)標(biāo)記，指向某個(gè)commit的指針。

tag主要用于發(fā)布版本的管理，一個(gè)版本發(fā)布之后，可以為git打上 v1.0.1,v1.0.2 ...這樣的類似的標(biāo)簽。

tag跟branch有點(diǎn)相似，但是本質(zhì)上和分工上是不同的：

tag 對(duì)應(yīng)某次commit, 是一個(gè)點(diǎn)，是不可移動(dòng)的。

branch 對(duì)應(yīng)一系列commit，是很多點(diǎn)連成的一根線，有一個(gè)HEAD 指針，是可以依靠 HEAD 指針移動(dòng)的。

所以，兩者的區(qū)別決定了使用方式，改動(dòng)代碼用 branch ,不改動(dòng)只查看用 tag。

tag 和 branch 的相互配合使用，有時(shí)候起到非常方便的效果

例如：已經(jīng)發(fā)布了 v1.0 v2.0 v3.0 三個(gè)版本，這個(gè)時(shí)候，我突然想不改現(xiàn)有代碼的前提下，在 v2.0 的基礎(chǔ)上加個(gè)新功能，作為 v4.0 發(fā)布。就可以檢出 v2.0 的代碼作為一個(gè) branch ，然后作為開(kāi)發(fā)分支。

⑤. Git相關(guān)命令

git status??

git log??

git init??

git checkout -b??

git add????

git rm --cache

git commit -m 版本名???

git branch??

git reset? --hard? HEAD^

柚子快報(bào)激活碼778899分享：運(yùn)維 DevOps

http://yzkb.51969.com/

參考文章