持續整合與持續交付(1) 基礎知識祥解

2021-10-07 03:45:27 字數 3218 閱讀 9866

git簡介

git (分布式版本控制系統) git是乙個開源的分布式版本控制系統,可以有效、高速地處理從很小到非常大的專案版本管理。 git 是 linus torvalds 為了幫助管理 linux 核心開發而開發的乙個開放原始碼的版本控制軟體。 torvalds 開始著手開發 git 是為了作為一種過渡方案來替代 bitke。 開源的最先進的分布式版本控制系統,沒有之一 用以高效、高速的處理從很小到非常大的專案版本管理

git特點

速度

簡單的設計

對非線性開發模式的強力支援(允許成千上萬個並行開發的分支)

完全分布式

有能力高效管理類似 linux 核心一樣的超大規模專案(速度和資料量)

自誕生於 2005 年以來,git 日臻成熟完善,在高度易用的同時,仍然保留著初期設定的目標。 它的速度飛快,極其適合管理大專案,有著令人難以置信的非線性分支管理系統。

git必看秘籍:

版本控制是一種記錄乙個或若干檔案內容變化,以便將來查閱特定版本修訂情況的系統

本地版本控制系統

集中化的版本控制系統

分布式版本控制系統

分布式版本控制系統(distributed version control system,簡稱 dvcs),

在這類系統中,像 git、mercurial、bazaar 以及 darcs 等,客戶端並不只提取最新版本的檔案快照,而是把**倉庫完整地映象下來。

這麼一來,任何一處協同工作用的伺服器發生故障,事後都可以用任何乙個映象出來的本地倉庫恢復。

因為每一次的轉殖操作,實際上都是一次對**倉庫的完整備份。

分布式相比於集中式的最大區別在於開發者可以提交到本地

每個開發者通過轉殖(git clone),在本地機器上拷貝乙個完整的git倉庫

git的功能特性

從一般開發者的角度來看,git有以下功能:

(1)從伺服器上轉殖完整的git倉庫(包括**和版本資訊)到單機上。

(2)在自己的機器上根據不同的開發目的,建立分支,修改**。

(3)在單機上自己建立的分支上提交**。

(4)在單機上合併分支。

(5)把伺服器上最新版的**fetch下來,然後跟自己的主分支合併。

(6)生成補丁(patch),把補丁傳送給主開發者。

(7)看主開發者的反饋,如果主開發者發現兩個一般開發者之間有衝突(他們之間可以合作解決的衝突),

就會要求他們先解決衝突,然後再由其中乙個人提交。如果主開發者可以自己解決,或者沒有衝突,就通過。

(8)一般開發者之間解決衝突的方法,開發者之間可以使用pull 命令解決衝突,解決完衝突之後再向主開發者提交補丁。

從主開發者的角度(假設主開發者不用開發**)看,git有以下功能

(1)檢視郵件或者通過其它方式檢視一般開發者的提交狀態。

(2)打上補丁,解決衝突(可以自己解決,也可以要求開發者之間解決以後再重新提交,

如果是開源專案,還要決定哪些補丁有用,哪些不用)。

(3)向公共伺服器提交結果,然後通知所有開發人員。

(1)優點

適合分布式開發,強調個體。

公共伺服器壓力和資料量都不會太大。

速度快、靈活。

任意兩個開發者之間可以很容易的解決衝突。

離線工作。

(2)缺點

資料少(起碼中文資料很少)。

學習週期相對而言比較長。

不符合常規思維。

**保密性差,一旦開發者把整個庫轉殖下來就可以完全公開所有**和版本資訊

(1)集中式版本控制系統

先說集中式版本控制系統,版本庫是集中存放在**伺服器的,而幹活的時候,用的都是自己的電腦,

所以要先從**伺服器取得最新的版本,然後開始幹活,幹完活了,再把自己的活推送給**伺服器。

**伺服器就好比是乙個圖書館,你要改一本書,必須先從圖書館借出來,然後回到家自己改,改完了,再放回圖書館。

集中式版本控制系統最大的毛病就是必須聯網才能工作,如果在區域網內還好,頻寬夠大,速度夠快,

可如果在網際網路上,遇到網速慢的話,可能提交乙個10m的檔案就需要5分鐘,效率低

(2)分布式版本控制系統

那分布式版本控制系統與集中式版本控制系統有何不同呢? 首先,分布式版本控制系統根本沒有「**伺服器」,每個人的電腦上都是乙個完整的版本庫,

這樣,你工作的時候,就不需要聯網了,因為版本庫就在你自己的電腦上。 既然每個人電腦上都有乙個完整的版本庫,那多個人如何協作呢?

比方說你在自己電腦上改了檔案a,你的同事也在他的電腦上改了檔案a, 這時,你們倆之間只需把各自的修改推送給對方,就可以互相看到對方的修改了。

和集中式版本控制系統相比,分布式版本控制系統的安全性要高很多,因為每個人電腦裡都有完整的版本庫,

某乙個人的電腦壞掉了不要緊,隨便從其他人那裡複製乙個就可以了。 而集中式版本控制系統的**伺服器要是出了問題,所有人都沒法幹活了。

在實際使用分布式版本控制系統的時候,其實很少在兩人之間的電腦上推送版本庫的修改,

因為可能你們倆不在乙個區域網內,兩台電腦互相訪問不了,也可能今天你的同事病了,他的電腦壓根沒有開機。

因此,分布式版本控制系統通常也有一台充當「**伺服器」的電腦,但這個伺服器的作用僅僅是用來方便「交換」大家的修改,

沒有它大家也一樣幹活,只是交換修改不方便而已。

CICD 持續整合與持續交付

持續整合與持續交付是軟體開發和交付中的實踐。我們專案中一直在踐行持續整合 ci continuous integration 持續交付 cd continuous delivery 未能達到理想狀態,只能實踐一部分。這篇文章用於總結ci cd的實踐。什麼是持續整合?軟體開發中,整合是乙個很可能發生未...

持續整合 持續交付 持續部署

持續整合 持續整合強調開發人員提交了新 之後,立刻進行構建 單元 測試。根據測試結果,我們可以確定新 和原有 能否正確地整合在一起。持續交付 持續交付在持續整合的基礎上,將整合後的 部署到更貼近真實執行環境的 類生產環境 production like environments 中。比如,我們完成單...

持續整合 持續交付 持續部署

參考 1 continuous integration 持續整合 持續整合強調對於開發人員的每個提交,立刻進行構建 單元 測試。根據測試結果,我們可以確定新 和原有 能否正確地整合在一起。2 continuous delivery 持續交付 持續交付在持續整合的基礎上,將整合後的 部署到更貼近真實執...