2019 DevOps 必备面试题——持续集成篇

原文地址：medium.com/edureka/dev…
原文做者：Saurabh Kulshrestha
翻译君：CODING 戴维奥普斯

Q1：什么是持续集成？

我会建议你以持续集成的最小定义做为开始来回答这个问题。这是一种研发实践，须要开发人员天天屡次将代码集成到共享代码库中。而后经过自动构建来验证每次代码的修改，以便团队尽早发现问题。

我建议你解释一下在之前的工做中是如何实施持续集成的，能够参考如下示例：

在上图中： 一、开发人员将代码 clone 至私有工做区。 二、完成编码后，他们将更改提交至共享代码库中（版本控制仓库）。 三、CI 服务器监视代码仓库并在发生更改时检出更改。 四、紧接着 CI 服务器提取这些变动进行构建、运行单元以及集成测试。 五、CI 服务器会当即告知团队构建成功与否。 六、若是构建失败，CI 服务器会向团队发送告警。 七、研发团队将尽快解决问题。 八、这个过程会不断重复。

Q2：为何研发团队须要开发与测试的持续集成？

对于这个答案，你应该关注持续集成的需求。我建议你在回答中提到如下解释： 开发和测试的持续集成经过在完成全部开发以后替换传统的测试实践，来提升软件质量并减小交付耗时。它容许开发团队尽早检测和定位问题，由于开发人员须要天天屡次（或更频繁地）将代码集成到代码仓库中，而后自动验证每次集成。

Q3：持续集成的成功因素有哪些？

在这里，你必须提到持续集成的要求，能够在回答中包含如下几点：

• 维护代码仓库
• 自动化构建
• 让构建自我检测
• 每一个人天天都确保已将修改提交至基线
• 保持快速构建
• 在生产环境的克隆环境中进行测试
• 研发团队能够轻松得到最新的可交付成果
• 每一个人均可以看到最新构建的结果
• 自动部署

Q4：如何将 Jenkins 从一台服务器迁移或者复制到另外一台服务器？

我会经过将 jobs 目录从旧服务器复制到新服务器的方式来完成这个事情。有不少种方法能够作到这一点：

• 只需复制相应的 job 目录，便可将 job 从一个 Jenkins 服务器移动到另外一个。
• 经过使用其它名称克隆 job 目录来制做现有 job 的副本。
• 经过重命名目录来重命名现有 job。请注意，若是你更改了 job 名称，则须要更改尝试调用该重命名 job 的全部 job 。

Q5：如何在 Jenkins 中建立备份和复制文件？

能够很直接地回答这个问题：要建立备份。你须要作的就是按期备份 JENKINS_HOME 目录。这包含全部构建 job 配置，从属节点配置和构建历史记录。要建立 Jenkins 的备份，只需复制此目录便可，你还能够复制 job 目录或重命名目录。

Q6：如何配置 Jenkins 的 job？

关于这个答案的解决方法是首先提一下如何建立 job：转到 Jenkins 首页，选择“New Job”，而后选择“Build a free-style software project”。而后你能够设置这个自由式 job 的元素：

• 可选的 SCM，例如源代码所在的 CVS 或 Subversion。
• 用于控制 Jenkins 什么时候执行构建的触发器。
• 某种构建脚本，用于执行实际工做的构建（ant，maven，shell 脚本，批处理文件等）。
• 从构建中收集信息的可选步骤，例如归档制品、记录 javadoc 和测试结果。
• 配置构建结果通知其余人/系统的步骤，例如发送电子邮件、即时消息、更新问题跟踪器等。

Q7：列举 Jenkins 中一些有用的插件

下面我将提到一些重要插件：

• Maven 2 project
• Amazon EC2
• HTML publisher
• Copy artifact
• Join
• Green Balls

我以为这些是最有用的插件，你也能够添加你认为有用的插件。可是请确保首先提到上述插件，而后添加你本身的插件。

Q8：如何保证 Jenkins 的安全？

• 确保 global security 配置项已经打开。
• 确保用适当的插件将 Jenkins 与企业员工目录进行集成。
• 确保启用项目矩阵的权限访问设置。
• 经过自定义版本控制的脚原本自动化 Jenkins 中设置权限/特权的过程。
• 限制对 Jenkins 数据/文件夹的物理访问。
• 按期对其进行安全审核。

点击使用 CODING 体验 DevOps 全工具链敏捷研发