正確進(jìn)行持續(xù)集成的組織都遵循一些基本規(guī)則。在本文中提出了持續(xù)集成的7個(gè)核心原則。

許多組織致力于DevOps，他們認(rèn)識(shí)到持續(xù)集成（CI）和持續(xù)交付（CD）的好處。然而，令人驚訝的是，很少有人真正理解持續(xù)集成的核心原理。

很大一部分人認(rèn)為他們正在進(jìn)行持續(xù)集成，但實(shí)際上并非如此。難道你真的做持續(xù)集成？這是一個(gè)重要的問題。知道您的組織是否正在進(jìn)行持續(xù)集成的關(guān)鍵問題包括：

1. 您是否定期將內(nèi)部版本的內(nèi)容輸入組織的主要渠道？

2. 您可以在10分鐘內(nèi)解決軟件問題嗎？

畢竟，持續(xù)交付（CD）和DevOps正在擾亂市場(chǎng)并為企業(yè)提供巨大的競(jìng)爭(zhēng)優(yōu)勢(shì)。持續(xù)交付基于持續(xù)集成的可靠實(shí)踐。試圖認(rèn)識(shí)到持續(xù)交付的好處的組織通常無法完全理解持續(xù)集成的概念。

正確進(jìn)行持續(xù)集成的組織都遵循一些基本規(guī)則。開發(fā)人員的工作副本至少每天一次（最好每天幾次）與共享主線同步。每個(gè)集成都通過自動(dòng)構(gòu)建進(jìn)行驗(yàn)證，以盡快檢測(cè)到錯(cuò)誤。持續(xù)集成本身就是一個(gè)旨在包含失敗的過程，在該過程中，開發(fā)人員可能經(jīng)常失敗并迅速失敗，因此他們可以及早發(fā)現(xiàn)并修復(fù)錯(cuò)誤。不遵循這些步驟的組織實(shí)際上并沒有正確地進(jìn)行持續(xù)集成。

持續(xù)集成和您的DevOps團(tuán)隊(duì)

持續(xù)集成是一種開發(fā)團(tuán)隊(duì)實(shí)踐，可為整個(gè)組織帶來真正的利益。負(fù)責(zé)實(shí)施持續(xù)集成實(shí)踐的工程師希望獲得這些好處，并遵循同行所遵循的現(xiàn)代實(shí)踐。通常，組織會(huì)聽到其他團(tuán)隊(duì)如何實(shí)施持續(xù)集成，然后根據(jù)此做出決策。但是，一個(gè)基本問題是每個(gè)組織都是不同的。一些DevOps團(tuán)隊(duì)可能對(duì)他們的組織中的持續(xù)集成有一個(gè)愿景，但它可能不完全符合通常公認(rèn)的定義。

不遵循持續(xù)集成核心原則的組織可能會(huì)遇到問題，無法定期提供清晰，有效的版本。隨著時(shí)間的流逝，該計(jì)劃將失去動(dòng)力，團(tuán)隊(duì)成員將變得虛脫。抵制變革的人們（這是我們大多數(shù)人），如果他們看不到變革帶來的好處的證據(jù)，他們將恢復(fù)到過去的做法。在這種情況下，您會(huì)遇到多個(gè)問題：您的構(gòu)建仍然充滿錯(cuò)誤，您的團(tuán)隊(duì)對(duì)實(shí)現(xiàn)失去信心，失去了關(guān)鍵時(shí)間，現(xiàn)在您需要重新啟動(dòng)項(xiàng)目。

實(shí)現(xiàn)持續(xù)融合所需的文化轉(zhuǎn)變

錯(cuò)誤實(shí)施持續(xù)集成的組織通常會(huì)面臨文化障礙。工程師擅長(zhǎng)解決技術(shù)問題，但是CI要求文化上的轉(zhuǎn)變，而且文化很難改變。您可以引入一個(gè)持續(xù)集成工具，并選中適用于CI應(yīng)該代表的大多數(shù)框，但是要成功實(shí)現(xiàn)CI，則需要更改工作方式和協(xié)作方式。 如果團(tuán)隊(duì)的文化沒有改變，他們將很難實(shí)施持續(xù)集成。

持續(xù)整合的原則

馬丁·福勒（Martin Fowler）制定了持續(xù)集成的核心原則和實(shí)踐至少15年，并且一直沒有改變。這是組織正確執(zhí)行CI所必須遵循的實(shí)踐。

1. 提交主線：這是用于持續(xù)集成的賭注。開發(fā)人員可以設(shè)置一個(gè)自動(dòng)構(gòu)建，并在每次提交時(shí)都運(yùn)行該構(gòu)建。但是，如果文化不經(jīng)常投入，那就沒關(guān)系了。如果開發(fā)人員等待三周提交或分支三周，則他將延遲集成并破壞原則。如果構(gòu)建失敗，團(tuán)隊(duì)必須整理三周的工作來弄清楚它在哪里破裂。

2. 維護(hù)單一源存儲(chǔ)庫：在復(fù)雜的應(yīng)用程序中，開發(fā)人員通常分支并維護(hù)主干（分支）或主干的更改。分支會(huì)增加復(fù)雜性，并阻止每個(gè)人使用單一的事實(shí)來源。團(tuán)隊(duì)每天至少需要一次提交/合并到主干或主干，或者對(duì)于每次更改甚至更好。

3. 自動(dòng)化構(gòu)建：大多數(shù)組織傾向于這樣做。但是，有些聲稱練習(xí)CI的人只是在按計(jì)劃進(jìn)行構(gòu)建（即每晚構(gòu)建），或者是連續(xù)構(gòu)建，但實(shí)際上并沒有測(cè)試或驗(yàn)證每個(gè)構(gòu)建。未經(jīng)構(gòu)建驗(yàn)證，您將無法進(jìn)行持續(xù)集成。

4. 使構(gòu)建進(jìn)行自我測(cè)試：驗(yàn)證過程的第一步是知道有問題的構(gòu)建實(shí)際上失敗了。下一步是確定構(gòu)建產(chǎn)品是否可運(yùn)行以及構(gòu)建是否按我們預(yù)期的那樣執(zhí)行。此測(cè)試應(yīng)作為構(gòu)建過程的一部分包括在內(nèi)。這包括快速功能測(cè)試和非功能測(cè)試。

5. 快速構(gòu)建：如果構(gòu)建應(yīng)用程序花費(fèi)的時(shí)間太長(zhǎng)，則開發(fā)人員將不愿意定期提交更改，否則會(huì)有更大的更改集。在任何一種情況下，沒人會(huì)迅速發(fā)現(xiàn)故障。通過快速構(gòu)建和快速集成，您可以快速隔離變更。如果需要幾個(gè)小時(shí)才能運(yùn)行，那么在此期間您可能還要進(jìn)行20到30個(gè)更改，因此很難快速發(fā)現(xiàn)問題。

6. 在克隆中進(jìn)行測(cè)試：驗(yàn)證過程可驗(yàn)證軟件在其預(yù)期的環(huán)境中是否按預(yù)期運(yùn)行。如果您在其他類型的環(huán)境中進(jìn)行測(cè)試，則可能會(huì)得出錯(cuò)誤的結(jié)果。

7. 立即修復(fù)已損壞的構(gòu)建：對(duì)于開發(fā)團(tuán)隊(duì)來說，快速發(fā)現(xiàn)問題并立即修復(fù)它們至關(guān)重要，因此它們不會(huì)向下游移動(dòng)。幾年前，豐田公司制定了“停產(chǎn)線”方法，如果工人發(fā)現(xiàn)問題，他們可以拉繩子并停止制造過程。CI建立了一個(gè)持續(xù)驗(yàn)證和提交構(gòu)建的過程，因此，如果出現(xiàn)問題，將很容易修復(fù)。

盡管組織在實(shí)現(xiàn)真正的持續(xù)集成方面面臨著所有挑戰(zhàn)，但重要的是要注意軟件開發(fā)社區(qū)在遵循為自己的運(yùn)營(yíng)創(chuàng)造真正價(jià)值的現(xiàn)代流程方面走了多遠(yuǎn)。許多人都在努力進(jìn)行更改并改善其DevOps實(shí)踐。組織面臨的最大障礙是員工對(duì)傳統(tǒng)技術(shù)的文化，情感和技術(shù)依戀。只有克服了“不能做到的文化”，我們才能提供原始的持續(xù)集成。