DevOps进阶(三):走近 DevOps 工程师


一、前言

在软件开发生命周期中,通常会遇到以下两个瓶颈:

  1. 在需求分析和系统开发阶段之间,针对不断变化的需求,对软件开发者提出了高要求,所以出现了敏捷开发方法论,强调需求敏捷响应、快速迭代、持续交付。
  2. 在系统开发和构建部署阶段之间,大量完成的开发任务可能阻塞在应用部署阶段,影响交付,于是有了DevOps

我们之前已经听到很多谈论DevOpsDevOps世界最新趋势的事情,但是就DevOps工程师本身,到底干些什么工作呢?

从最纯粹的存在形式上来说,DevOps工程师是为了加快开发和运营团队之间的交付效率而存在的桥梁。

在这里插入图片描述

二、DevOps 工程师在软件生命周期中能带来什么?

在传统的软件系统交付周期中,软件开发人员会在经年累月的编写代码后,将软件交给QA团队进行测试,然后将最终版本交给运营团队部署。这三个阶段,即开发测试部署之间是缺乏协作的。

开发编写的代码最终并交给运维团队,然后运维团队来解决代码部署过程中出现的问题,或者将代码交还给开发团队来解决遇到的问题。所有这些都导致了软件开发过程的放慢。
在这里插入图片描述
但是在DevOps模式下,这三个团队不再孤立。大多数时间内,从开发、测试、部署到运营,相关的工程师合并成一个团队并且贯穿整个软件生命周期,开发不再限制于某一个技能而是一整套技术解决方案。当然安全团队也因此有可能在这个软件生命周期中与开发和运营更紧密地工作,以便及早发现安全问题。

三、为什么 DevOps 工程师的角色各不相同呢?

DevOps工程师并不是什么新鲜事物。比如系统工程师,自动化工程师,软件工程师,Linux工程师等等工程师都能成为DevOps工程师

但是,DevOps工程师的工作性质因组织而异。比如有些是在基础设施自动化和维护中发挥作用,而在另外一些组织中却是在整个交付链中发挥作用而已。

DevOps工程师的角色各不相同,因为他必须通过克服传统协作障碍与开发和运维人员进行协作。而不同的组织有不同的障碍,因此其扮演的角色自然不同。

四、DevOps 工程师日常工作中最重要的两个方面

尽管DevOps工程师的角色各不相同,但几乎所有DevOps工程师每天都会触及两件事 - 自动化持续集成

4.1 自动化

与维护基础设施有关的大部分任务仍然是手动的。公司更喜欢使用传统的经过验证的方法,而不是自动化流程,因为他们不想冒任何风险。但事实是自动化任务将有助于更快速地开发和部署软件,这意味着能加快公司从客户处赚取利益的速度。

为了阐明这一点,我们可以考虑下面这个情况:

系统工程师如果每天按要求手动备份所有服务两次,那么他可以通过在云端设施上编写脚本来完成这项工作而不是浪费时间来完成这项工作。通过自动执行备份过程,可以让系统工程师更专注于重要的事情,例如对由于某些虚拟机问题而需要关闭的服务进行故障排除。手动执行相同的操作会导致您的系统工程师负担过重,而这些工程师的效率将大大降低。这只是一个非常简单的例子,通过不实施自动化来阐述资源浪费的概念。

DevOps因此可以作为敏捷的扩展,因为它可以降低由于开发人员、QA和运维团队之间的非协作而可能出现的风险。DevOps通过认识到高质量的软件开发要求包括质量保证和运营专家在内的所有利益相关方的持续参与和反馈,扩大了敏捷原则的范围。

有很多事情可以通过自动的方式来完成,比如在发布新补丁的时候更新Apache Web服务器,更新部署在服务器上的开源软件版本。

DevOps工程师可以通过创建脚本环境自动完成配置服务器的过程。可以在一个节点上运行脚本,但如果在数千上百个节点上手工运行相同的脚本将变得不切实际。脚本在这里就变得不再是一个可扩展的解决方案了。

因此,需要以可扩展的方式跨大量节点自动化进行软件配置、配置管理和应用程序部署。这是配置管理工具(如ChefPuppetAnsible)在DevOps世界中派上用场的地方。

4.2 持续集成

关于DevOps的另一个重要方面是在软件开发实践中实施持续集成(CI), CI允许开发人员不断更新自动化构建、测试使用到的资源库。

持续集成系统通常包含一个可以持续监控版本控制系统的工具。只要检测到对版本控制系统的更改,系统就会自动构建并测试你的应用程序。如果构建失败或测试没有通过,系统会立即通知开发人员解决问题。

持续集成可确保持续交付,因为所有代码更改都会不断部署到构建阶段之后的测试和生产环境中。

通过持续集成,开发人员可以从人工任务中解脱出来,提高工作效率,因为现在以CI中以自动化方式完成自动构建任务,并且由于更加频繁的测试,错误和bug更容易找到和解决,从而最终用户的更新可以更快,更频繁地进行。

有不同的产品和工具可以帮助您在组织中实现持续集成。有些工具可让你将CI 服务器托管在自己的网络基础架构中。最受欢迎的是从SunHudson项目现更名为Jenkins的工具。

还有一些其他托管的CI产品,如完全托管在云中的CircleCITravis CI。这些托管的CI产品越来越受到小组织的欢迎,因为它使工程团队能够尽快开始持续集成。
在这里插入图片描述

五、总结

  • DevOps工程师扮演的最重要角色是弥合软件开发和运营团队之间的差距,提高软件交付速度。

  • 尽管DevOps工程师在组织中的角色各不相同,但有两个重要共同点:自动化持续集成

六、拓展阅读

  • 4
    点赞
  • 7
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
刚刚发布的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测试,那太好了,现在是考虑您是否准备好实施持续交付的时候了。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

No Silver Bullet

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值