持續整合(一)思想篇

2021-09-06 18:51:47 字數 1711 閱讀 2611

持續整合(continuousintegration,簡稱ci),又被稱為持續構建(continuousbuild),最初是以一種研發管理的思想被提出來。2023年,持續整合的思想首先在kent beck的極限程式設計中被提了出來。kentbeck在他的書中是這樣描寫敘述的:「團隊程式設計就是先分而治之地解決這個問題,然後整合。但整合的過程是不可預知的,你等待整合的時間越長,付出的代價就可能越高。因此,每完畢一段時間程式設計,系統就應當進行一次整合,並進行對應的測試。」kentbeck將這裡的「一段時間」設定在幾個小時,並提出了整合的同一時候應當進行測試的思想,這也就是敏捷開發中的測試驅動設計。

我們再來聽聽敏捷大師martinfowler對持續整合的定義:持續整合是一種軟體開發實踐,即團隊開發成員常常整合它們的工作,通常每乙個成員每天至少整合一次,也就意味著每天可能會發生多次整合。每次整合都通過自己主動化的構建(包含編譯,公布,自己主動化測試)來驗證,從而盡快地發現整合錯誤。很多團隊發現這個過程可以大大降低整合的問題,讓團隊可以更快的開發內聚的軟體。

簡言之,持續整合就是開發者把**多次提交,自己主動化整合構建,公布的過程。多次,多到什麼程度呢?多到,一天,甚至幾小時提交,整合,構建一次。這樣能夠早早的發現整合中出現的錯誤,不會把錯誤積壓到最後,導致,找錯,排錯非常困難,並且這些過程都是機器自己主動化進行的,大大提高了開發效率,和開發質量。當然了,關於持續整合的長處多多,暫且在這裡不論。

隨著軟體業的發展,軟體專案的規模越來越大,軟體結構越來越複雜,技術要求越來越高,參與人員越來越多,管理也變得越來越難。在這樣乙個大背景下,怎樣提高軟體開發效率和質量,減少軟體開發成本,成為軟體行業的主題。然而在開發中能有一套行之有效的方法加以管理,這是最迫切的需求。可是有效的管理帶來的負面影響往往是成本的提高,這包含時間的成本、人力的成本、資金的成本。在大多數軟體開發專案中,時間總是非常緊,人力和資金也是有限的。這樣,管理者往往步入一種兩難的境界:一方面為了提高軟體質量而須要加大對時間、人力、資金的投入,還有一方面現實情況卻不同意我們這樣做,這也是非常多管理制度不能真正實施下去的原因。就在這種背景下,持續整合就應運而生了。它在軟體開發過程中為開發者攻克了非常多難題。

後來,持續整合的思想又被敏捷開發所吸收,並進一步提出了增量開發的思想。過去,我們解決複雜軟體系統問題的程式設計思想是分而治之。所謂分而治之,就是將大系統劃分成若干小模組,再劃分為乙個個小問題,分別予以解決,最後再整合。運用這種思想,整合的週期必定非常長,可能是數週甚至數月,其風險不言而喻。

增量開發改變了這種思想。儘管它依舊是將大系統劃分為無數的小模組、小問題,但它不是一股腦地馬上去解決全部問題,而是有選擇性地解決最核心、最基本的問題,然後再以進化的方式增量開發、逐漸完好,進而解決其他問題。在這樣乙個過程中,每進化一次就整合一次,產生乙個可執行的成果,以此迴圈往復,直到終於完畢。

然而,採用持續整合的方式固然好,但每幾個小時就要整合一次、測試一次,假設人為地去完畢,成本依舊是巨大的。因而,在敏捷開發大師martinfowler的推動下,持續整合工具誕生了。

持續整合工具將不可靠的人為操作,轉變成了機器自己主動化操作,在不提高專案成本的前提下大大的提高了軟體開發效率和質量成為了可能。

持續整合,事實上是一種思想,是軟體開發管理自己主動化,智慧型化的一種思想,更是軟體業發展的趨勢。而我們須要做的就是在開發過程中來實現這樣的思想,利用各種軟體工具來構建乙個更自己主動化,智慧型化的軟體生產工廠來實現它。當然了,在這個智慧型化的軟體生產工廠中,持續整合僅僅是非常小的一部分實現而已,我們要做的還有很多其它。

持續整合(一)

一 提出 整合軟體 的過程不是新問題,如果專案開發的規模比較小,比如乙個人的專案,如果它對 外部系統 的依賴很小,那麼軟體整合不是問題,但是隨著軟體專案複雜度的增加 即使增加乙個人 就會對整合和確保 軟體元件 能夠在一起工作提出了更多的要求 要早整合,常整合 早整合,頻繁的整合幫助專案在早期發現專案...

中級篇 CI CD持續整合 持續部署(69)

從這次課就開始學習ci cd,結合docker或者是使用k8s來完成。cicd的理解 ps 本人的目標cicd的整個流程,可以自己搭建一套小公司內部的流程,方便開發人員和測試使用。往期精彩 docker導學 一 容器的技術概述 二 docker的魅力初體驗 5分鐘安裝wordpress不走彎路 三 ...

持續整合簡介

想起我剛畢業後,進入一家以軟體外包為主的外企做開發。它使用傳統的瀑布式的軟體開發流程,沒有使用任何的敏捷實踐。我每天上班開啟電腦,拿到自己的任務,然後從版本控制更新 開啟工程按下build,準備進行今天的開發任務。突然發現build失敗 通常是編譯不過 大喊一聲 誰break build啦 也沒有人...