如何在六個月或更短的時間內成為DevOps工程師（三）：版本控制-知識星球

快速回顧

讓我們快速回顧一下。

簡而言之，這一系列文章講述了這麼一個故事，那就是指導我們儘快地學習如何將想法轉化為收入，這就是現代DevOps運動的精髓。

具體來說，在第1部分中，我們討論了DevOps的文化和標的。

在第2部分中，我們討論瞭如何使用Terraform為程式碼部署建設基礎。當然了，Terraform也是程式碼！

因此，在這篇文章中，我們將討論如何使所有這些程式碼無處不在。劇透一下，接下來講的會是關於Git的！

另外我們還將討論如何使用此Git業務來構建和打造你的個人形象（影響）。

作為參考，我們將以此開始我們的學習之旅：

那麼當我們談論“版本控制”時我們是想表達什麼？

想象一下，你正在開發一些軟體，變更非常頻繁，你需要根據需求來新增或刪除功能。在一些情況下，最新的一次變更將會產生阻斷性變化。換句話來說就是無論你最後做了什麼，它都打破了之前的工作。

怎麼辦？

如果你相對落後的話，你可能傾向於將第一個檔案命名為：awesome_code.pl。

在你開始做出改變之前你需要保留有用的東西，以防你需要回滾到這一階段。

因此，你會將檔案重新命名為：awesome_code.12.25.2018.pl。

這樣做也OK，直到某一天你會在每天進行多次更改，所以你最終會得到這樣的結果：awesome_code.GOOD.12.25.2018.pl。

諸如此類。

當然，在專業的環境中，你有多個團隊會在相同的程式碼庫上進行協作，這將進一步打破這個模型。

毋庸置疑，這種做法很快就會產生混亂。

原始碼控制

原始碼控制，顧名思義，一種將檔案儲存在集中位置的方法，多個團隊可以在公共程式碼庫上協同工作。

現在，這個想法已經不新奇了。最早提到這種東西甚至可以追溯到1972年！所以，我們應該將程式碼集中在一個地方的想法肯定是很古老的了。

然而，相對較新的一個想法就是所有生產環境的產物都必須進行版本控制。

那是什麼意思呢？

這意味著涉及生產環境的所有內容都必須儲存在版本控制中，他們需要被跟蹤追溯，審核以及更改歷史記錄。

此外，強制執行“所有產品必須版本化”的規定實際上迫使你以“自動化為先”的思維方式處理問題。

例如，當你決定在AWS的開發環境中單擊操作複雜問題時，你可以停下來並思考，“所有這些都是點選操作可以成為版本化產物嗎？”

當然，這個問題的答案是“不”。因此雖然可以透過UI進行快速原型檢視是否有效，但這些原型必須是短暫執行的。從長遠來看，請確保使用Terraform或其他基礎設施即程式碼工具來執行所有操作。

那麼如果一切都是可版本化的，那麼我們如何儲存和管理這些東西呢？

答案就是Git。

Git

直到Git出現之前，使用像SVN或其他的原始碼控制系統會很笨重，使用者不友好的，並且通常使用起來非常痛苦。

Git的不同之處在於它包含了分散式原始碼控制的概念。

換句話說，當你正在處理更改時，你不會將其他人鎖定在集中式原始碼倉庫外。相反，你正在處理的只是程式碼庫的一個完整的副本，最後將該副本合併到主儲存庫中。

請記住，以上對Git如何工作的講述有些粗略，過度簡化了。但就本文想要表達的內容來說，這已經足夠了，即使知道Git的內部工作方式有價值，我們還需要一段時間才能掌握。

現在，只需要記住Git不像SVN那樣古老。它是一個分散式原始碼控制系統，可供多個團隊安穩、安全地在共享程式碼庫上工作。

這對我們意味著什麼呢？

明確一下，我強烈支援這一說法，如果不知道Git是如何工作的，你就無法成為一名專業的DevOps（雲）工程師。就這麼簡單。

好的，那麼如何學習Git呢？

我必須說，在Google上搜索Git教程可能會得到非常全面和非常令人困惑的教程。

即便如此，其中某一些還是非常好的。

我比較推薦大家閱讀，學習和練習的一系列教程是Atlassian的Git教程[1]。

這個教程講的非常好，特別是Git Workflows[2]這一部分，它被世界各地的專業軟體工程師所使用。

另一個非常好的教程是Learn Git Branching[3]。

Atlassian教程只是讓你閱讀和學習（如果那是你喜歡的方式），而Learn Git Branching是一個互動教程。

無論如何，如果你不明白Git是如何工作的，你將無法在這個領域走得更遠！

我不得不再次強調這一點，缺乏對Git特性分支如何工作的理解，或者未能解釋Gitflow，是導致DevOps工程師中99%的人落選的原因。

這很關鍵，你可以在參加面試前不知道Terraform或是其他流行的基礎設施即程式碼工具是什麼，這沒關係，你都可以在以後的工作中學習它。

但是不知道Git及其工作方式的話，表明你缺乏現代軟體工程最佳實踐的基礎知識，DevOps思想或者其他。這向招聘經理傳遞了一種訊號，那就是你的學習曲線會非常陡峭。你肯定不希望這樣！

相反，如果你能自信地談論關於Git的最佳實踐的話，這將能讓招聘經理覺得你首先具有軟體工程的思維方式，這正是你想要表現的形象。

總結一下：你不需要成為世界上最重要的Git專家來獲得很棒的DevOps角色，但你確實需要正確地使用Git一段時間以便能夠自信地談論關於它的一些最佳實踐。

至少你應該精通以下幾項：

為一個Git倉庫開一個分支
建立分支
從上游和下游合併更改
建立PR

現在，一旦你學習完Git的教程之後，那麼去開通一個GitHub帳戶吧。

當然GitLab也可以，但是在寫這篇文章時，GitHub是當前最流行的開源Git倉庫，很多人都在使用它。

開通GitHub帳戶後，開始在上面貢獻程式碼！無論你學到什麼需要你編寫程式碼的東西，請確保定期將它提交給GitHub。

這不僅可以灌輸良好的原始碼控制規則，還可以幫助你打造自己的個人形象。

註意：當你在學習如何使用Git+GitHub時，請特別註意Pull Request（或PR，如果你想扮酷的話）。

品牌：向更多人展示你能力的一種方式。

有一個非常好的做法是建立GitHub倉庫以此來展示你的能力。在當今很多僱主都會要求你要有一個（維護或者說是包裝的很好的）Github賬戶。

因此，你應該努力擁有一個整潔、精心管理的GitHub賬戶，這樣你就可以把它放在簡歷上，並以此為傲。

在後面的部分中，我們將討論如何使用Hugo框架在GitHub上構建一個簡單但酷炫的網站。現在你只需要將程式碼推上GitHub即可。

在之後，隨著你的經驗越來越豐富，你可能會考慮使用兩個GitHub帳戶。一個用於儲存你編寫的練習程式碼，另一個用於儲存你想要向他人展示的程式碼。

總結一下：

學習Git
將你學到的所有知識提交貢獻到GitHub
展示截至目前為止在第一篇和第二篇中所學到的知識
從中學習受益

最後，請記住這個領域的最新發展的一些工具，如GitOps[4]。

GitOps將我們迄今為止討論的所有想法提升到新的水準，所有一切操作都是透過Git，拉取請求和部署管道來完成。

請註意，GitOps和類似的方法是針對業務方面的。具體來說，我們使用Git等複雜的東西並不是因為它們很酷。

相反，我們使用Git來實現業務敏捷性，加速創新並更快地交付功能，這些最終都可以讓我們的業務賺到更多錢！

現在就先講這麼多吧！更多內容可以關註我的部落格~

相關連結：

https://www.atlassian.com/git/tutorials
https://www.atlassian.com/git/tutorials/comparing-workflows
https://learngitbranching.js.org/
https://queue.acm.org/detail.cfm?ref=rss&id;=3237207

原文連結：https://medium.com/@devfire/how-to-become-a-devops-engineer-in-six-months-or-less-part-3-version-76034885a7ab

如何在六個月或更短的時間內成為DevOps工程師（三）：版本控制

相關推薦

熱門標籤

熱門文章

分享創造快樂