转载自 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 //列出了尚未合并的分支。
