DevOps通用及版本控制面试题

本文探讨了DevOps与敏捷的区别,DevOps的优势及其在软件交付中的关键作用。同时,深入讲解了版本控制的概念、Git的使用技巧及面试中常见的问题解答。

转载自   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的面试问题:

问题一:

什么是版本控制?
这可能是您在面试中将面临的最简单的问题。我的建议是首先给出版本控制的定义。它是一个记录文件或文件集随时间变化的系统,以便您以后可以调用特定版本。版本控制系统由一个中央共享存储库组成,队友可以在其中提交对文件或文件集的更改。然后你可以提到版本控制的用途。

版本控制允许您:

将文件还原为以前的状态。
将整个项目还原为以前的状态。
比较一段时间内的变化
查看最后一次修改可能导致问题的内容。
谁在何时引入了一个问题。

问题二:

使用版本控制有什么好处?

我建议你包括版本控制的以下优点:

  1. 使用版本控制系统(VCS),所有团队成员都可以随时在任何文件上自由工作。稍后VCS将允许您将所有更改合并到一个通用版本中。

  2. 所有过去的版本和变体都整齐地打包在VCS中。当您需要它时,您可以随时请求任何版本,您将获得完整项目的快照。

  3. 每次保存项目的新版本时,VCS都要求您提供已更改内容的简短说明。此外,您还可以查看文件内容的确切更改内容。这可以让您知道谁在项目中做了哪些更改。

  4. 像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  //列出了尚未合并的分支。

 

刚刚发布的ThoughtWorks技术雷达 建议技术团队“暂缓或谨慎”使用反模式“CI theatre(伪CI,可以理解为不完整的持续集成)”。 “伪CI”描述的是实践持续集成(CI)过程中的一些错觉,然而这些并不是真正的CI实践。 基于持续集成,我和同事 Emily Luke做了一些研究, 我将分享伪CI是什么样的,为什么我们建议你“暂缓或谨慎使用”,以及预防伪CI的方法。持续集成我最喜欢的CI定义来自于continuousdelivery.comCI开发人员定期(至少每天)将他们所有的工作集成到主干(也称为主线或主干分支)这个引用中暗含了CI实践的两个基本原则。第一个是“把他们所有的工作集成到主干”;第二个是“至少每天”。对于CI还有一系列其他原则和实践,例如:将所有内容都检入您的代码库,构建每个提交,自动化构建,保持快速构建,并有可以自我验证的代码, 还有Martin Fowler 关于持续集成的评论中的可视化故障并立即修复故障等。我个人认为 每天至少检入代码到主干分支一次 是CI的基础。没有达到这一点就只是伪CI而不是真正意义上的CI。伪CI是什么样的?这是我们调研到的一个故事,一位经验丰富的开发人员(让我们称他为David)来自湾区的一个中型创业公司,每周有两次产品交付。 David说他的组织正在践行CI,他说:“是的,我们用Circle CI”,他描述了一个具有挑战性的场景,曾经在一个分支上工作了一段时间,大约修改了100个文件和7000行代码,然后在代码审查阶段就开始招架不住了,因为他要向他的同事解释所有的代码变更的原因。“最具挑战性的事情是你最终要将一大堆功能集中到一个提交里,因为它们都是这个组件的一部分”,他解释说:“我希望有一个更好的方式来分解这些提交,因为很难把所有事情(变更历史)记在脑子里。”如果这个情况你听起来很熟悉,那么你也在做伪CI。 如果有下面的这些场景,那么你们就是在做伪CI:当有人问起你们在实践CI吗? 如果你说我们有一个CI服务器并且我们使用X工具在我们的调查中,只有10%的参与者承认有CI服务器与CI践行不一样。 相反,90%的个人表示他们正在践行CI,无论他们是否有专门从事CI的基础知识。 所以简单的认为只要有一个CI服务器就是“在做CI”,这就清楚地表明是在做“伪CI”。使用长期开发分支,但不会定期检入master主干在David的故事中,他们并没有实践每天检入master主干,这就是“伪CI”的标志。 这是我们在调研中常看到的一种模式,其中团队在master主干上运行CI,但不频繁构建,也不是每天都在提交。 或者他们在分支上运行CI,但不会频繁的集成到master主干。 只对特性分支运行CI,其实应该称之为持续隔离(continuous isolation)才对.合并分支时感到焦虑和疲惫真正的持续集成要把代码所有者的责任意识扩展到整个团队。 这改变了团队内部人员的观点以及他们对失败构建的态度。 不再是“我的宝贵的分支”,或是“我的错误导致构建被破坏”,而是“我们的代码”和“我们的失败”。David遇到焦虑和疲惫的事实清楚地表明,他忽略了CI的一个重要的优势:持续反馈和代码集体所有权。伪CI还有更多的一些现象,虽然我们发现有一些并不那么常见,但它们仍然存在一些问题,构建的时候,仅有极少的测试覆盖允许构建长时间处于失败状态虽然David的团队引入了一个备受尊崇的CI工具和常见的流程,如特征分支和代码审查,但他们并没有实施全套CI实践,因此错过了许多好处。 我们遗憾的发现,在我们的研究的组织中90%发生了这种情况。一些组织实施伪CI中反而错失了CI的主要优势 - 快速反馈,代码集体所有权,并准备达成持续交付如何避免,预防和解决伪CI的问题?如果您确定可能正在遭受伪CI之苦,则可以通过三种方式来解决问题并进行持续改变。1. 提交更频繁回到根本,尽量频繁地提交,每天至少提交一次应该是最低目标。 如果你还没有开始做CI,这就是你可以开始的地方,即使你在做CI,依然会有改进的空间。我喜欢“频率降低难度”的说法。 往往我们在做一些事情时,任务变得越小,则其更容易被实现。 持续集成就是是一个典型例子。 我的建议是要更加频繁地检入你的代码到代码库并且将开发分支集成到主干分支,至少每天集成一次”。2. 基于主干分支开发有很多论坛在讨论基于主干还是基于开发分支进行开发,我不想讨论那些血淋淋的细节。 然而,在我们的调研中,当我们与一些曾经在实践CI过程中感到痛苦的人交谈时,没有引入主干开发的团队对此有更深刻的感受。 DevOps现状调查报告-2016 还发现,基于主干开发和持续集成是达成持续交付的关键因素,同时也能建设更高效能的团队。基于主干的开发肯定会有一定的挑战,但它可以把问题提前暴露出来,而不是要等到代码合并、代码审查甚至到延迟发布的时候。如果你想达到更好效果的CI和CD,我建议在主干上做开发,或者如果你更愿意使用短周期的临时分支(合并到主干之前不到一天)进行开发,那么最好同时不要超过三个以上的活跃分支。3. 自动化自动化是做好持续集成的基石,所以如果你还没有自动化一切,现在是开始的好时机。 如果你认为已经实现了所有自动化的功能,那么每次有人手动地做任何事情超过一次,便要问自己“这个为什么不能自动化”? 我已经观察到自动化不仅可以帮助您在CI中变得更好,还可以帮助您开始持续交付。总结现在你知道什么是伪CI了,如果你的团队正在这么实践伪CI,那么你可以阻止这种情况继续发生了。 如果您仍然感到困惑,我建议你在Martin Fowler的博客“CI Certification test”做一个测试, 以确认你的组织是否正在做可靠的CI。 如果你通过了CI测试,那太好了,现在是考虑您是否准备好实施持续交付的时候了。
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值