Categories
程式開發

非運維專屬,開發人員的 CI/CD 使用指南


好像DevOps的定義還不夠複雜似的,它經常與它的誤解小伙伴一起被人掛在嘴邊:持續集成、持續交付和持續部署。就像一個古老的皇帝,需要一位演說家記住和講出他的頭銜/名字,滑稽的是,CI/CD/CD總是被人一起提及。你可以參與到這樣的對話中,但是一旦你將話題轉到持續集成、持續交付和持續部署,你就會連續不斷地說出這麼一大長串,讓每個人(包括你自己)都很惱火。或者在AWS這樣的環境中你可以簡稱它為CI/CD/CD,初級和非技術人員都會認為你是某種字母表專家。

不僅這個“東西”的名字令人困惑,而且它的定義也是模棱兩可。如果你問管理者,他們會告訴你如何為客戶創造價值。如果你問開發人員,他們會開始滔滔不絕地說一些工具、流程和代碼。如果你問營銷人員,他們會告訴你,這是解決組織中所有問題的方法。如果你問銷售人員,他們會告訴你節省的時間、指標和公司的潛在收益。如果你問敏捷教練,他們可能會讓你更加困惑,大喊CI不是CD, 這個CD不是……那個CD。

“哪個CD ?”

“別擔心。事實上,就叫它CI/CD吧。”

“那這個CD是持續交付的CD還是持續部署的CD(Continuous Delivery or Deployment)?”

“依賴於具體情況(Depends)吧。”

“持續依賴(Continuous Depends)?”【譯註:此處保留原文,請讀者體會原文的小趣味】

“打擾了,告辭”

那麼,當我們的英雄戰隊肩負起執行這個神秘過程的任務時,我們該從哪裡著手呢?

非運維專屬,開發人員的 CI/CD 使用指南 1

一個實用的定義

當我第一次嘗試解決這個問題時,看了一些系列視頻,在裡面有一個CTO,他試圖解釋持續集成、持續交付和持續部署。其中有一半是圖表/線條,另一半是他完全不停地在叨叨CI/CD這個咒語。到最後,我覺得他就是想輕鬆地賺這份錢。

為了節省開發人員的時間和挫折感,讓我給出了一個持續集成、持續交付和持續部署(CI/CD)的實用定義:

CI/CD有一個半自動到全自動的過程,憑此過程在舊代碼中安全地添加新代碼並將其發布給用戶。

對,沒錯,我們可以在這個鍋裡放入各種定義、切面和敏捷宣言的引用,就像你可以在雞肉麵湯裡倒入橙汁一樣。但是我們不會。為什麼?因為從開發人員的角度來看,這就是你在日常實現要做的事情。

“我有我當前的代碼。我想安全地添加(刪除)一些新代碼。我希望部署這些新變更。我希望這件事盡可能自動地完成。”

這個定義使你更加專注於它本身。事實上,有了它,我敢打賭你能想出各種可能的方法來實現它。

一些實用的目標

好的,我們找到了一個合適的關注點。然而,在構建你的第一個“CI/CD流水線”時,它涉及到將代碼從本地遷移到部署時的所有事情,你需要記住三個主要目標。我們可以方便地使用CI/CD/CD三重唱來對這些目標進行分類。我們將把它們作為你在構建自己的CI/CD流水線時可以問自己的問題:

1. 為了確保來自多個開發人員的新代碼可以安全地添加到現有代碼中,需要做些什麼? (又名持續集成)

考慮一下測試、版本控制、代碼評審和構建。

2. 為了確保我們的代碼庫可以在任何時候發佈到我們的生產環境中,需要做些什麼? (又名持續交付)

考慮一下質量保證(QA)測試、產品經理評審、用戶測試和反饋,以及各種測試代碼的環境(例如,部署到開發或準生產環境中,在發布之前測試所有內容)。

3.需要做什麼才能使我們的代碼在更新時自動部署? (又名持續部署)

設想一下腳本和流程,它們將監控代碼庫中的Git分支,並在更改和批准之後自動部署它。

現在,如果你感到有點不知所措,可能是因為這些目標在上午九點從一個雄心勃勃的經理嘴裡說出來時顯得很宏偉,它們不是條例……它們是目標。完成之後,每個組織和團隊看上去都會有些不同。例如,如果你是個一人軍團,你的CI/CD流水線可能是這樣的:

a)有一個github代碼庫(持續集成)

b)在合併新代碼之前,運行單元測試(持續集成)

c)將新代碼部署到準生產環境(已部署了模擬生產環境的基礎設施),並確保其運轉正常(持續交付)

d)如果©通過,將新代碼合併到主分支中,並將其自動部署到生產環境中(持續部署)

然而,如果你是一個擁有更多部署和測試需求的大型團隊,那麼你的CI/CD流水線將包含更多的步驟和細節。但是首要的、最終的目標還是一樣的:

有一個半自動到全自動的過程,憑此過程在舊代碼中安全地添加新代碼並將其發布給用戶。

一個實用的方法

“定義和目標都很好,但是我從哪裡開始呢?”

即使我們已經對定義和目標有了更清晰的認識,那麼如何坐下來真正做到這一點呢?首先,我假設你有某種代碼庫(軟件),你在本地開發代碼,並最終部署到某個地方供用戶使用。第二,讓我問你一個問題:

你目前採取哪些步驟將代碼庫從本地機器發佈到生產基礎設施或託管解決方案?

按照以下步驟來回答上面的問題:

1. 列出將代碼從本地發佈到生產環境所需的所有步驟。

把這個列表寫下來,就好像你要手動去做一樣。 “我會對它進行測試。然後我再讓人評審一下。然後我們再合併它。”等等等等。

2. 基於這個列表,哪些步驟可以自動化?

像代碼評審這樣的事情是不能自動化的,但是運行你的測試套件或者將它部署到你的基礎設施上是可以自動化的。

3.有了可以自動化的步驟,你需要編寫什麼腳本,或者你可以使用什麼工具來自動化它們?

例如,你可能有一個命令一覽表,其中列出了你需要運行的所有命令,以使你的代碼庫在你的主機或IaaS服務上運行。這將是一條候選的可以腳本化的工作流。

你明白我們要怎麼做了嗎?完成了上述3個步驟之後,你就有了構建持續集成、持續交付和持續部署流水線所需的所有工作的列表。現在你可以開始乾起來了,看著你的業務經理像素材圖片裡的模特一樣面露微笑!

那麼CI/CD服務呢?

“但是科爾,你覺得Jenkins / CircleCI / TravisCI / SemphoreCI等等怎麼樣?”如果我們不邀請他們,他們會知道的……”

確實。事情是這樣的,與流行的觀點相反,你不需要任何這些來建立CI/CD。如果你已經完成了上面的列表,它主要包括什麼?腳本。所以你真正需要的是運行這些腳本所需的那些東西。

對於大多數人來說,這將是一台遠程服務器。它不受任何開發人員本地主機精神負擔的束縛。它具有足夠的權限和足夠的軟件來完成你所編寫的所有自動化操作。

…如果你以前曾經將任何應用程序部署到遠程服務器,那麼你就已經完成這件事了。你已經準備好了一台服務器,給它足夠的東西來運行你的應用程序代碼,然後讓互聯網/內部用戶訪問你的服務器和應用程序。搭建一台“CI/CD服務器”幾乎是一樣的。主要的區別是:

1.運行腳本所需的依賴項。

2.CI/CD服務器獲取你的代碼庫所需的的訪問/權限。

3.CI/CD服務器將代碼庫部署到生產基礎設施或託管解決方案所需的訪問/權限。

在某種意義上,你擁有一個全新的應用程序要處理、開發、擴展和部署。這正是第三方CI/CD服務和解決方案開始發揮作用的地方。他們把這個過程從你的工作中抽像出來,讓你只專注於寫那些自動化腳本。通常要用他們自己的語言或語法。

然而,它確實可以像搭建另一個服務器來執行上述步驟一樣簡單。我之所以提出這個問題,是因為在討論CI/CD時,人們往往會直接跳到第三方解決方案。雖然我相信對於90%的團隊來說,使用這些是正確的方向,但是首先討論它們可能會讓人注意不到CI/CD是多麼簡單。人們將首先選擇一個工具,然後將他們的方形CI/CD需求放入工具的圓形功能中,而不是弄清楚需要做什麼。

也就是說,如果你確實知道需要腳本化和自動化哪些內容,那麼選擇CI/CD服務或解決方案就會變得容易得多。你想要自己掌控它嗎?你喜歡它們的語言或語法嗎?他們的文件是“垃圾箱火災”嗎? 【譯註:指的是某人、某個機構、或某種情況處於絕望境地,或者處於災難性的失控狀態。 】你要了解全局。

知易、行難

那麼,如果這一概念如此容易,為什麼實施起來會相當困難呢?嗯,在我們當前的DevOps生態系統中,這是一個技能反饋週期。不像開發,你改完之後可以立即知道它是否正常運轉,而DevOps系統(即CI/CD流水線)則需要幾分鐘到一個小時的時間來查看你所做的是否正確。最重要的是,你經常在本地機器之外測試這些基礎設施……這意味著學習是要付出代價的。

例如,假設你已經了一批服務器來處理CI/CD。假設你的自動化工作流應該測試你的代碼庫並將其部署到一系列準生產、開發或生產服務器上。好,為了確保事情是準確的,你可能會在實際的基礎設施中進行測試。此外,如果其中一項服務器配置是壞的怎麼辦?現在,你必須深入到服務器中,更改它們的配置,可能還要重新啟動它們,然後等待,看看新做的修復是否有效。如果你需要5到10分鐘來完成和部署這個變更,而且你在正常運行之前你還得必須進行50到100次變更的話……

但是,當第一個蜿蜒綿長的自動化系統平穩運行時,你會有什麼感覺?無可比擬。看著你的團隊對代碼進行一些更改,將其向上推送到版本控制、檢查、合併並自動部署,這些事多麼值得關注呀。儘管構建這些系統的過程很長,但它極大地縮短了開發人員、業務人員和用戶之間的反饋週期。

什麼是持續集成、持續交付和持續部署(CI/CD)?

“嗯,持續集成、持續交付和持續部署讓我們通過持續地集成和部署新功能不斷地向我們的關鍵涉眾交付價值。”

“現在回答這個問題時,不要使用持續、集成、交付、部署這些詞,以及它們的任何同義詞。”

“嗯……它,嗯,幫助我們幫助我們的利益相關者……我的意思是,更多的時候。”

“那麼…你能詳細說說嗎?”

“嗯……pull requests?”

這種做法的定義很難弄得很明確。我認為這主要是許多不同學科參與其中的結果。管理者、營銷人員、銷售人員、開發人員、運維、產品。很多人在這條流水線中都插了一手,對他們每個人來說,它意味著日常工作中有些事有了不同。

但是在想出需要做什麼工作以及這些工作是如何實際結合在一起的時候?同樣,它也很簡單,CI/CD有一個半自動到全自動的過程,憑此過程在舊代碼中安全地添加新代碼並將其發布給用戶。

作者介紹:

J Cole Morrison,雲架構師,軟件工程師,前Techstars Hackstar, AWS解決方案架構師,awsdevops.io創始人。

原文鏈接:

A Practical Approach to CI/CD for Developers