- 原文地址:How To Become a DevOps Engineer In Six Months or Less, Part 3: Version
- 原文作者:Igor Kantor
- 譯文出自:掘金翻譯計劃
- 本文永久連結:github.com/xitu/gold-m…
- 譯者:jianboy
- 校對者:lihanxiang
注意:這是《如何如何在六個月或更短的時間內成為 DevOps 工程師》系列的第三部分,第一部分請點選這裡。第二部分點選這裡。
讓我們快速回顧一下上期內容。
簡而言之,這一系列文章講述了一個故事。
而這個故事正在學習如何將想法轉化為金錢,快速 —— 現代化 DevOps 開發的精髓。
具體而言,在第一部分我們談到了 DevOps 的文化和目標。
在第二部分,我們討論瞭如何使用 Terraform 為未來的程式碼部署奠定基礎。當然,Terraform 也是程式碼!
因此,在這篇文章中,我們將討論如何防止所有這些程式碼完全失控。劇透,這都是關於 git!
額外獎勵:我們還將討論如何使用此 git business 來構建和推廣您自己的個人品牌。
作為參考,我們從這裡開始:
![[譯] 如何在六個月或更短的時間內成為 DevOps 工程師,第三部分:版本控制](https://i.iter01.com/images/d1352b8633eeea4f02dad95acb5d100c81ce38b3b51c11092b10b29410fed01f.png)
DevOps 之旅
那麼,當我們談論“版本控制”時,我們在說什麼?
想象一下,你正在開發一些軟體。您正在不斷更改它,根據需要新增或刪除功能。 通常情況下,最新的變化將是一次“破壞性”的變化。 換句話說,無論你最後做了什麼,都打亂之前的工作。
怎麼辦?
好。如果您在以前的學校,您可能傾向於將您的第一個檔案命名為:
awesome_code.pl
複製程式碼
然後你開始對檔案做一些修改,你需要保留有用的東西,萬一你必須恢復它。
因此,您將檔案重新命名為:
awesome_code.12.25.2018.pl
複製程式碼
這很好。直到有一天你每天進行多次更改,所以你最終會得到這樣的結果:
awesome_code.GOOD.12.25.2018.pl
複製程式碼
等等。
當然,在專業環境中,您有多個團隊在相同的程式碼庫上進行協作,這進一步打破這種文件備份方案。
毋庸置疑,上面這種檔案重新命名來版本管理肯定行不通。
原始碼控制:一種將檔案儲存在集中位置的方法,其中多個團隊可以在公共程式碼庫上一起工作。
現在,這個想法並不新鮮。我能找到的最早提及的文章可以追溯到 1972 年!因此,我們應該將程式碼集中在一個地方的想法肯定是老的。
然而,相對較新的是所有開發過程必須被版本化的想法。
什麼意思呢?
這就是說涉及生產環境的所有內容都必須儲存在版本控制中,並受到跟蹤、稽核和記錄歷史更改。
此外,強制執行“所有開發過程必須版本化”的原則實際上迫使您以“自動化第一”的思維方式處理問題。
例如,當您決定在 Dev AWS 環境中只通過點選解決複雜問題時,您可以暫停並思考這麼一個問題:“所有點選操作都受版本控制了嗎?”
當然,答案是“不”。因此,雖然可以通過 UI 進行快速原型檢視是否有效,但這些努力必須是短暫的。從長遠來看,請確保您使用 Terraform 或其他架構即程式碼工具來執行所有操作都受版本控制。
好的,所以如果一切都受版本控制,那麼我們如何儲存和管理這些東西呢?
答案是 git。
在 git 出現之前,使用像 SVN 或其他的原始碼控制系統是笨重的,不是使用者友好的,並且通常是非常痛苦的經歷。
git 的不同之處在於它包含分散式原始碼控制的概念。
換句話說,當您正在處理更改時,您不會將其他人鎖定在集中式原始碼儲存庫之外。相反,您正在編寫程式碼庫的完整副本。然後該副本會 merged 進入 master 儲存庫。
請記住,以上是對 git 如何工作的粗略過度簡化。但就本文而言,這已經足夠了,即使知道 git 的內部工作方式既有價值又需要一段時間才能掌握。
![[譯] 如何在六個月或更短的時間內成為 DevOps 工程師,第三部分:版本控制](https://i.iter01.com/images/bd5845b9e219103b9e6478406b83e8939d9e1cc849ca46ef4aca83578094565b.png)
現在,請記住,git 不是像舊版的 SVN 一樣。它是一個分散式原始碼控制系統,多個團隊可以安全,可靠地在共享程式碼庫上工作。
這對我們意味著什麼?
具體來說,如果沒有使用 git 版本管理而自稱作專業的 DevOps(雲)工程師,我嚴重懷疑你的能力。就這麼簡單。
好的,那麼如何學習 git 呢?
我必須說,Google 搜尋 “git 教程”的區別在於它提供的教程非常全面但非常令人困惑。
但是,有一些非常非常好。
我推薦大家閱讀,學習和練習的一系列教程是 Atlassian’s Git Tutorials。
事實上,它們都非常好,但特別是世界各地的專業軟體工程師使用的部分:Git Workflows。
我再怎麼強調也不為過。一次又一次地,缺乏理解 git 分支是如何工作的,或者沒有解釋 Gitflow 是什麼讓 99% 有抱負的 DevOps 工程師落選的原因。
這是關鍵。你可以參加面試,即使不知道 Terraform 或者最新的架構及程式碼是什麼,沒關係 — 你可以在工作中學習它。
不知道 git 及其工作方式表明你缺乏現代軟體工程最佳實踐的基礎知識,DevOps 與否。這向招聘經理髮出訊號,表明你的學習曲線非常陡峭。你不想發出訊號!
相反,您自信地談論 git 最佳實踐的能力告訴招聘經理您首先要具備軟體工程思維模式 —— 這正是您想要應用到工作中的思維。
總而言之,你不需要成為世界上最重要的 git 專家,來獲得令人敬畏的 DevOps 角色,但你確實需要在一段時間內生活和呼吸 git,才能自信地談論正在發生的事情。
至少,你應該精通如下:
- Fork 一個倉庫
- 建立分支
- 合併兩個不同的 commit
- 建立 Pull 請求
現在,一旦您完成介紹性的 git 教程,請獲取 GitHub 帳戶。
注意:GitLab 也可以,但在撰寫本文時,GitHub 是最流行的開源 git 儲存庫,因此您肯定希望和其他人分享。
獲得 GitHub 帳戶後,開始為其提供程式碼!無論你學到什麼,都需要你編寫程式碼,請確保定期將它提交給 GitHub。
這不僅可以灌輸良好的原始碼控制思想,還可以幫助您建立自己的個人品牌。
注意:當你學習如何使用 git + GitHub 時,要特別注意 Pull Requests(也叫 PRs,如果你想變酷)。
![[譯] 如何在六個月或更短的時間內成為 DevOps 工程師,第三部分:版本控制](https://i.iter01.com/images/f7abe045cf067de5c76889134b8316c8a71cf7bd6c3db4d4a7bfd16b4f3b2847.jpg)
Pull Request, by Vidar Nordli-Mathisen
品牌:向更廣闊的世界展示您的能力的一種方式。
這種方式(目前,更好的方式之一!)是建立一個 GitHub 賬戶,作為您的品牌代表。這些天幾乎所有的面試官都會要求求職者有 GitHub 賬戶。
因此,您應該努力擁有一個整潔、精心策劃的 GitHub 帳戶 — 您可以將其放在簡歷上併為此感到自豪。
在後面的部分中,我們將討論如何使用 Hugo 框架在 GitHub 上構建一個簡單但酷炫的網站。現在,只需將程式碼放入 GitHub 即可。
稍後,隨著您的經驗越來越豐富,您可能會考慮使用兩個 GitHub 帳戶。一個用於儲存您編寫的練習程式碼的個人資料,另一個用於儲存您想要向其他人展示的程式碼。
總結一下:
- 學習 git
- 將您學到的所有知識貢獻給 GitHub
- 利用#1和#2作為迄今為止所學到的所有知識的展示
- 從中受益!
最後,請記住這個領域的最新發展,例如 GitOps。
GitOps 將我們迄今為止討論的所有想法提升到新的水平 — 一切都通過 git、pull requests 和管道的部署。
請注意,GitOps 和類似的工具應用於商業方面的事情。具體來說,我們不是在使用像 git 之類的複雜東西,因為它們很酷。
相反,我們使用 git 來實現業務敏捷性,加速創新並更快地交付功能 —— 這些都可以讓我們的業務最終賺到更多錢!
目前為止就這樣了!
如果發現譯文存在錯誤或其他需要改進的地方,歡迎到 掘金翻譯計劃 對譯文進行修改並 PR,也可獲得相應獎勵積分。文章開頭的 本文永久連結 即為本文在 GitHub 上的 MarkDown 連結。
掘金翻譯計劃 是一個翻譯優質網際網路技術文章的社群,文章來源為 掘金 上的英文分享文章。內容覆蓋 Android、iOS、前端、後端、區塊鏈、產品、設計、人工智慧等領域,想要檢視更多優質譯文請持續關注 掘金翻譯計劃、官方微博、知乎專欄。