今天，人們希望比以往更快地看到他們最喜歡的應用程序與最新的花里胡哨。開發(fā)人員花費數(shù)年時間開發(fā)和發(fā)布新軟件產(chǎn)品的日子已經(jīng)一去不復返了。因此，每個軟件開發(fā)公司都需要一個有效的 DevOps 管道來跟上客戶的需求。本文介紹了 DevOps 管道的基本概念，管道如何在 DevOps 環(huán)境中工作，并解釋了代碼在部署到生產(chǎn)之前必須經(jīng)過的階段。

什么是 DevOps 管道？

DevOps 管道是開發(fā) (Dev) 和運營 (Ops) 團隊實施的一組實踐，用于更快、更輕松地構建、測試和部署軟件。管道的主要目的之一是保持軟件開發(fā)過程的組織和重點。不過，“管道”一詞可能有點誤導。汽車廠的裝配線可能是一個更合適的類比，因為 軟件開發(fā)是一個連續(xù)的循環(huán)。

在制造商向公眾發(fā)布汽車之前，它必須通過無數(shù)的組裝階段、測試和質(zhì)量檢查。工人必須建造底盤、添加電機、車輪、車門、電子設備和完成油漆工作，以使其對客戶具有吸引力。DevOps 管道的工作方式類似。

在向用戶發(fā)布應用程序或新功能之前，您首先必須編寫代碼。然后，確保它不會導致任何可能導致應用程序崩潰的致命錯誤。避免這種情況涉及運行各種測試以找出任何錯誤、錯別字或錯誤。最后，一旦一切按預期工作，您就可以將代碼發(fā)布給用戶。從這個簡化的解釋中，您可以得出結論，DevOps 管道由構建、測試和部署階段組成。

DevOps 管道的組件

為確保代碼從一個階段無縫移動到下一個階段，需要實施多種 DevOps 策略和實踐。其中最重要的是 持續(xù)集成 和 持續(xù)交付（CI/CD）。

持續(xù)集成

持續(xù)集成 (CI) 是一種將來自多個開發(fā)人員的小塊代碼盡可能頻繁地集成到共享代碼存儲庫中的方法。使用 CI 策略，您可以自動測試代碼中的錯誤，而無需等待其他團隊成員貢獻他們的代碼。CI 的主要好處之一是它可以幫助大型團隊防止所謂的 集成地獄。

在軟件開發(fā)的早期，開發(fā)人員必須等待很長時間才能提交代碼。這種延遲顯著增加了代碼集成沖突和錯誤代碼部署的風險。與舊的做事方式相反，CI 鼓勵開發(fā)人員每天提交他們的代碼。因此，他們可以更快地發(fā)現(xiàn)錯誤，并最終花費更少的時間來修復它們。CI 的核心是 中央源代碼控制系統(tǒng)。它的主要目的是幫助團隊組織他們的代碼、跟蹤更改并啟用自動化測試。

在典型的 CI 設置中，每當開發(fā)人員將新代碼推送到共享代碼存儲庫時，自動化就會啟動以將新代碼和現(xiàn)有代碼編譯到構建中。如果構建過程失敗，開發(fā)人員會收到警報，通知他們哪些代碼行需要重做。確保只有高質(zhì)量的代碼通過管道是至關重要的。因此，每次有人向共享存儲庫提交新代碼時，都會重復整個過程。

持續(xù)交付

持續(xù)交付 (CD) 是 CI 的擴展。它涉及通過鼓勵開發(fā)人員以增量塊的形式將代碼發(fā)布到生產(chǎn)環(huán)境來加快發(fā)布過程。通過 CI 階段后，代碼構建將移至暫存區(qū)。在管道中的這一點上，由您決定是將構建推送到生產(chǎn)還是保留它以進行進一步評估。在典型的 DevOps 場景中，開發(fā)人員首先將他們的代碼推送到類似生產(chǎn)的環(huán)境中以評估其行為方式。但是，新版本也可以立即上線，開發(fā)人員只需按一下按鈕即可隨時部署它。

要充分利用持續(xù)交付，請盡可能頻繁地部署代碼更新。發(fā)布頻率取決于工作流程，但通常是每天、每周或每月。與一次發(fā)布所有更改相比，以更小的塊發(fā)布代碼更容易解??決問題。因此，您可以避免瓶頸和合并沖突，從而保持穩(wěn)定、持續(xù)的集成管道流。

持續(xù)部署

持續(xù)交付和持續(xù)部署在許多方面都相似，但兩者之間存在關鍵差異。雖然持續(xù)交付使開發(fā)團隊能夠手動部署軟件、功能和代碼更新，但持續(xù)部署就是自動化整個發(fā)布周期。

在持續(xù)部署階段，代碼更新會自動發(fā)布給最終用戶，無需任何人工干預。但是，實施自動發(fā)布策略可能很危險。如果它未能緩解沿途檢測到的所有錯誤，那么不良代碼將被部署到生產(chǎn)環(huán)境中。在最壞的情況下，這可能會導致應用程序中斷或用戶遇到停機時間。

僅在發(fā)布次要代碼更新時才應使用自動部署。如果出現(xiàn)問題，您可以回滾更改而不會導致應用程序出現(xiàn)故障。要充分利用持續(xù)部署的潛力，需要擁有強大的測試框架，以確保新代碼真正沒有錯誤并準備好立即部署到生產(chǎn)環(huán)境中。

持續(xù)測試

持續(xù)測試是在開發(fā)過程的每個階段盡可能頻繁地運行測試以在到達生產(chǎn)環(huán)境之前檢測問題的做法。實施持續(xù)測試策略可以快速評估交付管道中特定候選版本的業(yè)務風險。

測試范圍應涵蓋功能測試和非功能測試。這包括處理應用程序和服務器基礎架構的安全和性能方面的運行單元、系統(tǒng)、集成和測試。持續(xù)測試包括更廣泛的質(zhì)量控制，包括風險評估和遵守內(nèi)部政策。

持續(xù)運營

擁有全面的持續(xù)運營策略有助于保持應用程序和環(huán)境的最大可用性。目標是讓用戶不知道不斷發(fā)布代碼更新、錯誤修復和補丁。持續(xù)運營策略有助于防止代碼發(fā)布期間出現(xiàn)停機和可用性問題。要獲得持續(xù)運營的好處，您需要有一個強大的 自動化和編排 架構，可以處理服務器、數(shù)據(jù)庫、容器、網(wǎng)絡、服務和應用程序的持續(xù)性能監(jiān)控。

DevOps 管道的階段

關于如何構建管道沒有固定的規(guī)則。DevOps 團隊根據(jù)他們的特定工作流程添加和刪除某些階段。盡管如此，幾乎每個管道都有四個核心階段： 開發(fā)、 構建、 測試和 部署?？梢酝ㄟ^添加另外兩個階段（ 計劃 和 監(jiān)控）來擴展該設置 ，因為它們在專業(yè)的 DevOps 環(huán)境中也很常見。

計劃

規(guī)劃階段涉及在開發(fā)人員開始編碼之前規(guī)劃整個工作流程。在這個階段，產(chǎn)品經(jīng)理和項目經(jīng)理起著至關重要的作用。他們的工作是創(chuàng)建一個開發(fā)路線圖，指導整個團隊完成整個過程。

在從用戶和利益相關者那里收集反饋和相關信息后，工作被分解成一個任務列表。通過將項目分割成更小、更易于管理的塊，團隊可以更快地交付結果、當場解決問題并更輕松地適應突然的變化。在 DevOps 環(huán)境中，團隊在 sprint中工作- 一個較短的時間段（通常為兩周），在此期間，各個團隊成員都在處理分配給他們的任務。

發(fā)展

在開發(fā)階段，開發(fā)人員開始編碼。根據(jù)編程語言，開發(fā)人員在他們的本地機器上安裝適當?shù)?IDE（Python IDE、Java IDE等）、代碼編輯器和其他技術，以實現(xiàn)最大的生產(chǎn)力。

在大多數(shù)情況下，開發(fā)人員必須遵循某些編碼風格和標準，以確保統(tǒng)一的編碼模式。這使任何團隊成員都更容易閱讀和理解代碼。當開發(fā)人員準備好提交他們的代碼時，他們會向共享源代碼存儲庫發(fā)出拉取請求。然后，團隊成員可以手動審查新提交的代碼，并通過批準初始拉取請求將其與主分支合并。

建造

DevOps 管道的構建階段至關重要，因為它允許開發(fā)人員在代碼中的錯誤進入管道并導致重大災難之前檢測到它們。在新編寫的代碼與共享存儲庫合并后，開發(fā)人員會運行一系列自動化測試。在典型的場景中，拉取請求會啟動一個自動化過程，將代碼編譯成構建 - 可部署的包或可執(zhí)行文件。

請記住，某些編程語言不需要編譯。例如，用 Java 和 C編寫的應用程序 需要編譯才能運行，而用 PHP 和 Python編寫的應用程序 則不需要。如果代碼有問題，構建會失敗，并且會通知開發(fā)人員這些問題。如果發(fā)生這種情況，初始拉取請求也會失敗。開發(fā)人員每次提交到共享存儲庫時都會重復此過程，以確保只有無錯誤的代碼繼續(xù)沿管道傳輸。

測試

如果構建成功，則進入測試階段。在那里，開發(fā)人員運行手動和自動測試以進一步驗證代碼的完整性。在大多數(shù)情況下， 會執(zhí)行用戶驗收測試 。人們以最終用戶的身份與應用程序進行交互，以確定代碼在將其發(fā)送到生產(chǎn)環(huán)境之前是否需要進行額外的更改。在這個階段，執(zhí)行安全、性能和負載測試也 很常見。

部署

當構建到達 Deploy 階段時，軟件已準備好推送到生產(chǎn)環(huán)境。如果代碼只需要較小的更改，則使用自動部署方法。但是，如果應用程序經(jīng)歷了大修，則首先將構建部署到類似生產(chǎn)的環(huán)境中，以監(jiān)控新添加的代碼的行為方式。在發(fā)布重大更新時，實施 藍綠部署策略 也很常見。

藍綠色部署意味著擁有兩個相同的生產(chǎn)環(huán)境，其中一個環(huán)境托管當前應用程序，而另一個環(huán)境托管更新版本。要將更改發(fā)布給最終用戶，開發(fā)人員可以簡單地將所有請求轉(zhuǎn)發(fā)到適當?shù)姆掌?。如果出現(xiàn)問題，開發(fā)人員可以簡單地恢復到以前的生產(chǎn)環(huán)境，而不會導致服務中斷。

監(jiān)視器

在 DevOps 管道的最后階段，運營團隊努力工作，持續(xù)監(jiān)控基礎架構、系統(tǒng)和應用程序，以確保一切順利運行。他們從日志、分析和監(jiān)控系統(tǒng)以及用戶反饋中收集有價值的數(shù)據(jù)，以發(fā)現(xiàn)任何性能問題。在 Monitor 階段收集的反饋用于提高 DevOps 管道的整體效率。在每個發(fā)布周期之后調(diào)整管道以消除潛在的瓶頸或其他可能阻礙生產(chǎn)力的問題是一種很好的做法。

如何創(chuàng)建 DevOps 管道

現(xiàn)在您已經(jīng)更好地了解了 DevOps 管道是什么以及它是如何工作的，讓我們探索創(chuàng)建 CI/CD 管道時所需的步驟。

設置源代碼控制環(huán)境

在您和團隊開始構建和部署代碼之前，請確定源代碼的存儲位置。 GitHub 是迄今為止最受歡迎的代碼托管網(wǎng)站。GitLab 和 BitBucket 是強大的替代品。

要開始使用 GitHub，請打開一個免費帳戶并創(chuàng)建一個共享存儲庫。要將代碼推送到 GitHub，首先 在本地機器上安裝 Git 。完成代碼編寫后，將其推送到共享源代碼存儲庫。如果多個開發(fā)人員正在開發(fā)同一個項目，其他團隊成員通常會在將新代碼與主分支合并之前手動查看新代碼。

設置構建服務器

一旦代碼在 GitHub 上，下一步就是對其進行測試。針對代碼運行測試有助于防止向用戶部署錯誤、錯誤或拼寫錯誤。許多測試可以確定代碼是否可以生產(chǎn)。決定運行哪些分析取決于項目的范圍和用于運行應用程序的編程語言。

創(chuàng)建構建的兩個最流行的解決方案是 Jenkins 和 Travis-CI。Jenkins 是完全免費和開源的，而 Travis-CI 是一個托管解決方案，也是免費的，但僅適用于開源項目。要開始運行測試， 請在服務器上安裝 Jenkins 并將其連接到 GitHub 存儲庫。然后，您可以將 Jenkins 配置為在每次更改共享存儲庫中的代碼時運行。它編譯代碼并創(chuàng)建一個構建。在構建過程中，Jenkins 會在遇到任何問題時自動發(fā)出警報。

運行自動化測試

有許多測試，但最常見的是 單元測試、 集成測試和 功能測試。根據(jù)開發(fā)環(huán)境，最好安排 自動測試一個 接一個地運行。通常，您希望在測試過程開始時運行最短的測試。例如，您將在功能測試之前運行單元測試，因為它們通常需要更多時間才能完成。如果構建順利通過測試階段，您可以將代碼部署到生產(chǎn)環(huán)境或類似生產(chǎn)環(huán)境以進行進一步評估。

部署到生產(chǎn)

在將代碼部署到生產(chǎn)環(huán)境之前，首先設置服務器基礎架構。例如，要部署 Web 應用程序，您需要 安裝像 Apache 這樣的 Web 服務器。假設應用程序?qū)⒃谠浦羞\行，您很可能會將其部署到虛擬機。對于需要物理硬件的全部處理潛力的應用程序，您可以部署到專用服務器或 裸機云服務器。

部署應用程序有兩種方法—— 手動 或 自動。首先，最好手動部署代碼以了解部署過程。后來，自動化可以加快這個過程，但只有你有信心，才會有障礙阻止糟糕的代碼最終進入生產(chǎn)環(huán)境。將代碼發(fā)布到生產(chǎn)環(huán)境是一個簡單的過程。最簡單的部署方法是配置構建服務器以執(zhí)行自動將代碼發(fā)布到生產(chǎn)環(huán)境的腳本。

結束時

現(xiàn)在您了解什么是 devops 管道以及它如何幫助加快您的軟件開發(fā)生命周期。然而，這只是冰山一角。DevOps 管道是一個廣泛的主題，每個組織都會有自己的方式將其集成到他們的工作流程中。最終目標是創(chuàng)建一個可重復的系統(tǒng)，利用自動化并實現(xiàn)持續(xù)改進，以幫助更快、更輕松地交付高質(zhì)量的產(chǎn)品。