轉載自? ?DevOps通用及版本控制面試題

通用DevOps面試問題

此類別將包含與任何特定DevOps階段無關的問題。這里的問題旨在測試您對DevOps的理解，而不是關注特定工具或階段。?

問題一：

DevOps和Agile之間的根本區別是什么？
兩者之間的差異列于下表中。

?

問題二：

為什么需要DevOps？
據我所知，這個答案應該從解釋一般市場趨勢開始。公司不是發布大量功能，而是試圖通過一系列發布列表來查看是否可以將小功能傳輸給客戶。這具有許多優點，例如來自客戶的快速反饋，更好的軟件質量等，這反過來導致高的客戶滿意度。為實現這一目標，公司必須：

• 增加部署頻率

• 降低新版本的故障率

• 修復之間縮短的提前期

• 新版本崩潰時平均恢復時間更快

DevOps滿足所有這些要求，有助于實現無縫的軟件交付。您可以舉出像Etsy，Google和亞馬遜這樣的公司的例子，在5年前，這些公司已經采用DevOps達到了無法想象的性能水平。他們每天進行數十，數百甚至數千次代碼部署，同時提供世界級的穩定性，可靠性和安全性。

問題三：

DevOps與Agile / SDLC有何不同？

Agile是一套關于如何生成即開發軟件的價值觀和原則。示例：如果您有一些想法，并且希望將這些想法轉變為可用的軟件，則可以使用Agile的價值觀和原則來實現這一點。但是，該軟件可能只適用于開發人員的筆記本電腦或測試環境。如果您希望以安全，簡單的方式快速，輕松，可重復地將該軟件移植到生產基礎架構中。那么，您需要DevOps工具和技術。

Agile軟件開發方法側重于軟件的開發，但另一方面，DevOps負責開發以及以最安全和最可靠的方式部署軟件。

問題四：

最頂級的DevOps工具有哪些？

最受歡迎的DevOps工具如下所述：

• Git：版本控制系統工具

• Jenkins：持續集成工具

• Selenium：連續測試工具

• Puppet，Chef，Ansible：配置管理和部署工具

• Nagios：持續監控工具

• Docker：容器化工具

問題五：

所有這些工具如何協同工作？
下面給出了一個通用的邏輯流程，其中所有內容都自動進行無縫交付 但是，根據要求，此流程可能因組織而異。

1.開發人員開發代碼，此源代碼由Git等版本控制系統工具管理。

2.開發人員將此代碼發送到Git存儲庫，并且代碼中所做的任何更改都將提交到此存儲庫。

3.Jenkins使用Git插件從存儲庫中提取此代碼，并使用Ant或Maven等工具構建它。

4.配置管理工具，如puppet部署和配置測試環境，然后Jenkins在使用selenium等工具進行測試的測試環境中發布此代碼。

5.一旦代碼被測試，Jenkins就會將其發送到生產服務器上進行部署（甚至生產服務器也由puppet等工具進行配置和維護）。

6.部署后，Nagios等工具會持續監控。

7.Docker容器提供測試環境以測試構建功能。

?

問題六：

DevOps有哪些優勢？

對于這個答案，您可以使用您過去的經驗并解釋DevOps如何幫助您完成上一份工作。如果您沒有任何此類經驗，那么您可以提及以下優勢。

技術優勢：
持續的軟件交付
修復不太復雜的問題
更快地解決問題

商業利益：

更快速地傳遞功能

更穩定的操作環境
有更多時間可以增加價值（而不是修復/維護）

問題七：

DevOps幫助我們實現的最重要的事情是什么？
據我所知，DevOps幫助我們實現的最重要的事情是盡可能快地將更改投入生產，同時最大限度地降低軟件質量保證和合規性的風險。這是DevOps的主要目標。

但是，您可以添加DevOps的許多其他積極效果。例如，團隊之間更清晰的溝通和更好的工作關系，即Ops團隊和開發團隊合作共同提供高質量的軟件，從而提高客戶滿意度。

問題八：

DevOps的反模式有哪些？
模式是通常遵循的常見用法。如果其他人普遍采用的模式對您的組織不起作用，并且您繼續盲目地遵循它，那么您實際上采用的是反模式。有關于DevOps的謬見。包括下面一些：

DevOps是一個過程
Agile等于DevOps
我們需要一個單獨的DevOps組
Devops將解決我們所有的問題
DevOps意味著開發人員管理生產
DevOps是開發驅動的發布管理
DevOps不是開發驅動的。
DevOps不是IT運營驅動的。
我們不能做DevOps - 我們是獨一無二的
我們不能做DevOps - 我們遇到了錯誤的人

版本控制系統（VCS）面試問題

下面讓我們看一下關于VCS的面試問題：

問題一：

什么是版本控制？
這可能是您在面試中將面臨的最簡單的問題。我的建議是首先給出版本控制的定義。它是一個記錄文件或文件集隨時間變化的系統，以便您以后可以調用特定版本。版本控制系統由一個中央共享存儲庫組成，隊友可以在其中提交對文件或文件集的更改。然后你可以提到版本控制的用途。

版本控制允許您：

將文件還原為以前的狀態。
將整個項目還原為以前的狀態。
比較一段時間內的變化
查看最后一次修改可能導致問題的內容。
誰在何時引入了一個問題。

問題二：

使用版本控制有什么好處？

我建議你包括版本控制的以下優點：

使用版本控制系統（VCS），所有團隊成員都可以隨時在任何文件上自由工作。稍后VCS將允許您將所有更改合并到一個通用版本中。

所有過去的版本和變體都整齊地打包在VCS中。當您需要它時，您可以隨時請求任何版本，您將獲得完整項目的快照。

每次保存項目的新版本時，VCS都要求您提供已更改內容的簡短說明。此外，您還可以查看文件內容的確切更改內容。這可以讓您知道誰在項目中做了哪些更改。

像Git這樣的分布式VCS允許所有團隊成員擁有項目的完整歷史記錄，因此如果中央服務器出現故障，您可以使用任何團隊成員的本地Git存儲庫。

問題三：

描述您使用的分支策略。
這個問題被要求測試你的分支經驗，告訴他們你在以前的工作中如何使用分支以及它的用途是什么，你可以參考以下幾點：

功能分支：
功能分支模型保留分支內特定功能的所有更改。通過自動化測試對功能進行全面測試和驗證后，分支將合并為主服務器。
任務分支
在此模型中，每個任務都在其自己的分支上實現，任務鍵包含在分支名稱中。很容易看出哪個代碼實現了哪個任務，只需在分支名稱中查找任務鍵。

發布分支：
一旦開發分支獲得了足夠的發布功能，您就可以克隆該分支以形成發布分支。創建此分支將啟動下一個發布周期，因此在此之后不能添加任何新功能，只有錯誤修復，文檔生成和其他面向發布的任務才能進入此分支。一旦準備好發布，該版本將合并到主服務器并標記版本號。此外，它應該合并回到開發分支，自發布以來可能已經取得了進展。
最后告訴他們分支策略因組織而異，所以我知道基本的分支操作，如刪除，合并，檢查分支等。

問題四：

您熟悉哪種VCS工具？

你可以提到你曾經使用過的VCS工具：“我已經研究過Git，它對SVN等其他VCS工具的一個主要優勢就是它是一個分布式版本控制系統。”?
分布式VCS工具不一定依靠中央服務器來存儲項目文件的所有版本。相反，每個開發人員都“克隆”存儲庫的副本，并在自己的硬盤上擁有項目的完整歷史記錄。

問題五：

什么是Git？
我建議您首先解釋一下git的體系結構來嘗試這個問題，如下圖所示。您可以參考下面給出的解釋：

Git是一個分布式版本控制系統（DVCS）。它可以跟蹤文件的更改，并允許您恢復到任何特定的更改。

與SVN等其他版本控制系統（VCS）相比，其分布式架構具有許多優勢，一個主要優點是它不依賴于中央服務器來存儲項目文件的所有版本。相反，每個開發人員“克隆”我在下圖中使用“本地存儲庫”顯示的存儲庫副本，并在其硬盤驅動器上具有項目的完整歷史記錄，以便在出現服務器中斷時，只需要恢復所需的全部內容是你隊友的本地Git存儲庫之一。

還有一個中央云存儲庫，開發人員可以在其中提交更改并與其他團隊成員共享，如圖所示，所有協作者都在提交更改“遠程存儲庫”。?

?

問題六：

在Git中，您如何還原已經推送并公開的提交？
此問題可以有兩個答案，因此請確保包含兩個答案，因為根據具體情況可以使用以下任何選項：

在新提交中刪除或修復錯誤文件，并將其推送到遠程存儲庫。這是修復錯誤的最自然方式。對文件進行必要的更改后，將其提交到遠程存儲庫，使用

git?commit?-m?“commit?message”

創建一個新的提交，撤消在錯誤提交中所做的所有更改。為此，我將使用命令

git?revert?<錯誤提交的名稱>

問題七：

你如何將N次提交壓縮成一次提交？

將N個提交壓縮成單個提交有兩種選擇。在您的答案中包括以下兩個選項：
如果要從頭開始編寫新的提交消息，請使用以下命令

git?reset?–soft?HEAD~N?&& git?commit

如果你想用現有提交消息的串聯開始編輯新的提交消息，那么你需要提取這些消息并將它們傳遞給Git commit，我將使

git?reset?–soft?HEAD~N?&& git?commit?–edit?-m”$(git?log?–format=%B?–reverse?.HEAD@{N})”

問題八：

什么是Git bisect？你怎么用它來確定（回歸）bug的來源？
我建議你先給出一個Git bisect的小定義，Git bisect用于查找使用二進制搜索引入bug的提交。Git bisect的命令是

git?bisect?<子命令>?<選項>

現在你已經提到了上面的命令，解釋一下這個命令會做什么，這個命令使用二進制搜索算法來查找項目歷史中的哪個提交引入了一個bug。您可以通過首先告訴它已知包含該錯誤的“錯誤”提交以及在引入錯誤之前已知的“良好”提交來使用它。然后Git bisect在這兩個端點之間選擇一個提交，并詢問您所選的提交是“好”還是“壞”。它繼續縮小范圍，直到找到引入更改的確切提交。

問題九：

什么是Git rebase以及它如何在合并之前用于解決功能分支中的沖突？

根據我的說法，您應該首先說git rebase是一個命令，它將另一個分支合并到您當前正在工作的分支中，并將所有位于重新分支之前的本地提交移到該歷史記錄的頂部。

現在，一旦您為一個示例定義了Git rebase時間，以顯示如何在合并之前使用它來解決功能分支中的沖突，如果從master創建了一個功能分支，從那時起主分支已收到新的提交，Git rebase可用于將要素分支移動到主要提示。

該命令有效地將重放在master的tip處的功能分支中所做的更改，從而允許在該過程中解決沖突。完成后，這將允許功能分支相對容易地合并到主服務器中，有時作為簡單的快進操作。

問題十：

如何配置Git存儲庫以在提交之前運行代碼健全性檢查工具，并在測試失敗時阻止它們？

我建議你先做一個簡單的檢查，完整性測試或煙霧測試，確定繼續測試是否合理可行。

現在解釋如何實現這一點，可以通過與存儲庫的預提交hook相關的簡單腳本來完成。即使在您需要輸入提交消息之前，也會在提交之前觸發預提交hook。在此腳本中，可以運行其他工具，例如linters，并對提交到存儲庫中的更改執行完整性檢查。

最后給出一個例子，你可以參考下面的腳本：

#!/bin/sh files=$(git?diff?–cached?–name-only?–diff-filter=ACM?|?grep?‘.go$’) if?[?-z?files?];?then exit?0 fi unfmtd=$(gofmt?-l?$files) if?[?-z?unfmtd?];?then exit?0 fi echo?“Some?.go?files?are?not?fmt’d” exit?1

如果需要通過標準Go源代碼格式化工具gofmt傳遞任何即將提交的.go文件。可以通過非零狀態退出，使腳本有效地阻止將提交應用于存儲庫。

問題十一：

如何找到特定提交中已更改的文件列表？

對于這個問題，答案不僅僅只是告訴命令，解釋這個命令究竟會做什么。
你可以這么說，為了獲得在特定提交中更改的列表文件使用命令

git?diff-tree?-r?{hash}

給定提交哈希，這將列出在該提交中更改或添加的所有文件。-r標志使命令列表單個文件，而不是僅將它們折疊到根目錄名稱中。

你也可以包括下面提到的點，雖然它是完全可選的，但有助于給面試官留下深刻的印象。

輸出還將包含一些額外的信息，可以通過包含兩個標志來輕松抑制：

git?diff-tree?–no-commit-id?–name-only?-r?{hash}

這里-no-commit-id將禁止提交哈希值出現在輸出中，而-name-only只會打印文件名而不是它們的路徑。

問題十二：

每次存儲庫通過推送接收新提交時，如何設置腳本運行？

每次存儲庫通過push接收新提交時，有三種方法可以配置腳本運行，需要根據需要觸發腳本的時間來定義預接收，更新或后接收hook。

將提交提交到目標存儲庫時，將調用目標存儲庫中的預接收hook。綁定到此hook的任何腳本都將在更新任何引用之前執行。這是一個有用的hook，用于運行有助于實施開發策略的腳本。

Update hook以類似于預接收hook的方式工作，并且在實際進行任何更新之前也會觸發。但是，對于已推送到目標存儲庫的每個提交，都會調用一次update hook。

最后，在將更新接受到目標存儲庫后，將調用存儲庫中的post-receive hook。這是配置簡單部署腳本，調用一些持續集成系統，向存儲庫維護人員發送通知電子郵件等的理想場所。

hook是每個Git存儲庫的本地存儲，并且沒有版本化。腳本可以在“.git”目錄內的hooks目錄中創建，也可以在別處創建，并且可以在目錄中放置這些腳本的鏈接。

問題十三：

如果分支已經合并為主分支，你怎么知道Git？

我建議你包括下面提到的命令：

git branch -merged ? ? //列出已合并到當前分支的分支。 git branch -no-merged ?//列出了尚未合并的分支。

?

總結

以上是生活随笔為你收集整理的DevOps通用及版本控制面试题的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。