标签 DevOps 下的文章

使用 Powershell 来自动化 Linux、macOS 以及 Windows 流程

Willy-peter Schaub 发布于 2021-11-23
另请参阅: 技术,PowerShell, 自动化, DevOps
2 条评论

自动化是 DevOps 的关键，但是，是否任何事都可以自动化？

title=

自动化控制了那些手工的、费力的和容易出错的过程，用运行自动化脚本的计算机代替了执行手工任务的工程师。每个人都认同手工流程是健康的 DevOps 模式的敌人。一些人认为自动化不是一件好事，因为它取代了辛勤工作的工程师，而另一些人则意识到它提高了一致性、可靠性和效率，节省了时间，（最重要的是）使工程师能够聪明地工作。

“DevOps 并不只是自动化或者基础架构即代码。” — Donovan Brown

自从上个世纪 80 年代早期开始使用自动化流程和工具链以来，每当我听到或读到“自动化一切”的建议时，我总是会激动不已。虽然在技术上可以实现一切自动化，但自动化是复杂的，并且需要付出开发、调试和维护方面的代价。如果你曾经重新启用一个许久不用的 Azure 资源管理器（ARM）模板或很久以前编写的宝贵维护脚本，并期望它在几个月或几年之后仍然能够完美地执行，那么你就会明白，自动化就像任何其他代码一样，是脆弱的，需要持续的维护和培养。

所以，你应该对什么进行自动化并在何时进行自动化？

当你手动执行自动化流程超过一两次
当你需要经常地持续地执行自动化流程
自动化任何可被自动化的

更重要的是，什么是你不应该自动化的？

不要自动化一次性的流程，因为不值得投入，除非你会重新使用它作为参考文档，并定期验证它的可用性
不要自动化高度不稳定的流程，因为太复杂且昂贵
不要自动化有问题的流程，在自动化前先修复它们

举例来说，我的团队使用我们通用的协作和工程系统来不断的监控数百个用户活动。如果一个用户在三个月或者更长时间处于非活动状态，并且这个用户被分配了一个昂贵的许可证，我们就会重分配这个用户一个功能少一些但是免费的许可证。

如图 1 所示，这是一个没有技术挑战性的流程。这是一个令人费解且容易出错的过程，尤其是在执行上下文时与其他开发和运维任务切换时。

title=

图 1 手工流程切换用户许可证

顺带的，这里有一个用简单三步创建的价值流图的例子:

可视化所有活动: 列出用户、过滤用户、重置许可证。
确定利益相关者，即运营和授权团队。
措施：

* 总交货时间（TLT）= 13 小时
* 总周期时间（TCT） = 1.5 小时
* 总效率百分比 = TLT/TCT*100 = 11.5%

如果你在人群流量大和容易看到的区域挂一个这些可视化的副本，比如在你的团队的讨论区、餐厅，或在去洗手间的路上，你将引发大量的讨论和主动反馈。例如，从视觉上看，很明显，手工任务是一种浪费，主要是由于漫长的流程等待时间造成的。

让我们研究一个简单的 PowerShell 脚本，它可以自动化该流程，如图 2 所示，将总交付时间从 13 小时减少到 4 小时加 60 秒，并将总体效率从 11.5 提高到 12.75%。

title=

图 2 半自动化的 PowerShell 脚本切换用户许可

PowerShell 是一种开源的基于任务的脚本语言。它可以在 GitHub 上找到。它构建在 .NET 上，允许你自动化 Linux、macOS 和 Windows 流程。具有开发背景的用户，特别是 C# 用户，将享受到 PowerShell 的全部好处。

下面的 PowerShell 脚本示例通过它的服务 REST API 与 Azure DevOps 进行通信。脚本结合了在图 1 中的手动列表用户和过滤用户任务，识别了 Demo 组织中的所有两个月没有活动的、使用基本许可证或更昂贵的基本+测试许可证的用户，并将用户的详细信息输出到控制台。很简单！

首先，设置认证标头和其他变量，这些变量将在稍后的初始化脚本中使用：

param(
  [string]   $orgName       = "DEMO",
  [int]      $months        = "-2",
  [string]   $patToken      = "<PAT>"
)

# Basic authentication header using the personal access token (PAT)
$basicAuth = ("{0}:{1}" -f "",$patToken)
$basicAuth = [System.Text.Encoding]::UTF8.GetBytes($basicAuth)
$basicAuth = [System.Convert]::ToBase64String($basicAuth)
$headers   = @{Authorization=("Basic {0}" -f $basicAuth)}

# REST API Request to get all entitlements
$request_GetEntitlements    = "https://vsaex.dev.azure.com/" + $orgName + "/_apis/userentitlements?top=10000&api-version=5.1-preview.2";

# Initialize data variables
$members              = New-Object System.Collections.ArrayList
[int] $count          = 0;
[string] $basic       = "Basic";
[string] $basicTest   = "Basic + Test Plans";

接下来，使用此脚本查询所有授权，以识别不活动用户：

# Send the REST API request and initialize the members array list.
$response = Invoke-RestMethod -Uri $request_GetEntitlements -headers $headers -Method Get
$response.items | ForEach-Object { $members.add($_.id) | out-null }

# Iterate through all user entitlements
$response.items | ForEach-Object {
  $name    = [string]$_.user.displayName;
  $date    = [DateTime]$_.lastAccessedDate;
  $expired = Get-Date;
  $expired = $expired.AddMonths($months);
  $license = [string]$_.accessLevel.AccountLicenseType;
  $licenseName = [string]$_.accessLevel.LicenseDisplayName;
  $count++;

  if ( $expired -gt $date ) {

    # Ignore users who have NEVER or NOT YET ACTIVATED their license
    if ( $date.Year -eq 1 ) {
      Write-Host " **INACTIVE** " " Name: " $name " Last Access: " $date "License: " $licenseName
    }
    # Look for BASIC license
    elseif ( $licenseName -eq $basic ) {
         Write-Host " **INACTIVE** " " Name: " $name " Last Access: " $date "License: " $licenseName
    }
    # Look for BASIC + TEST license
    elseif ( $licenseName -eq $basicTest ) {
        Write-Host " **INACTIVE** " " Name: " $name " Last Access: " $date "License: " $licenseName
    }
  }
}

当你运行脚本时，你将得到以下输出，你可以将其转发给授权团队，以重置用户许可证：

**INACTIVE** Name: Demo1 Last Access: 2019/09/06 11:01:26 AM License: Basic
**INACTIVE** Name: Demo2 Last Access: 2019/06/04 08:53:15 AM License: Basic
**INACTIVE** Name: Demo3 Last Access: 2019/09/26 12:54:57 PM License: Basic
**INACTIVE** Name: Demo4 Last Access: 2019/06/07 12:03:18 PM License: Basic
**INACTIVE** Name: Demo5 Last Access: 2019/07/18 10:35:11 AM License: Basic
**INACTIVE** Name: Demo6 Last Access: 2019/10/03 09:21:20 AM License: Basic
**INACTIVE** Name: Demo7 Last Access: 2019/10/02 11:45:55 AM License: Basic
**INACTIVE** Name: Demo8 Last Access: 2019/09/20 01:36:29 PM License: Basic + Test Plans
**INACTIVE** Name: Demo9 Last Access: 2019/08/28 10:58:22 AM License: Basic

如果你将最后一步自动化，自动将用户许可设置为一个自由的利益相关方许可，如图3所示，你可以进一步将总体交付时间减少到65秒，并将总体效率提高到77%。

title=

图 3 完全自动化的基于 Powershell 的流程来切换用户许可证。

这个 PowerShell 脚本的核心价值不仅在于能够实现 自动化，还在于能够定期、持续和 快速地 执行这个流程。进一步的改进是使用 Azure 管道等调度器每周或每天触发脚本，但我将把程序化的许可证重置和脚本调度保留在未来的文章中。

这里有一个图表，可以直观地看到进展情况：

title=

图 4，措施，措施，措施

我希望你能喜欢这个简短的关于自动化、PowerShell、REST API 和价值流图的介绍。请在评论中分享你的想法和反馈。

via: https://opensource.com/article/20/2/devops-automation

作者：Willy-Peter Schaub 选题：lujun9972 译者：FigaroCao 校对：wxy

本文由 LCTT 原创编译，Linux中国荣誉推出

如何实现 DevOps 工具链

Tereza Denkova 发布于 2021-01-29
另请参阅: 观点,DevOps
评论

一套完整启用的 DevOps 工具链可推动你的创新计划，实现快速部署并节约成本。

title=

不同规模和不同行业组织都致力于为提高软件交付的速度和质量提供解决方案。这不仅保证了他们的生存，还令他们在全球市场取得了成功。DevOps 可以帮助他们规划出一条最佳路线。

DevOps 是一个系统，通过引入不同的工具链连接不同工作流程，以便及时交付项目并降低所需的开销。

在我工作的 IT 服务公司 Accedia，我们会帮助客户落地一套完整的 DevOps 工具链，这套工具链能帮助他们达到甚至超越他们的业务目标。在这篇文章，我会分享目前为止从 DevOps 项目中汲取的经验。

DevOps 工具链是什么？

一套完善的 DevOps 工具链可以在不同阶段中使用不同的 DevOps 工具来解决特定的业务带来的挑战。一条工具链能保证前端和后端开发者、质量测试人员、客户都能够从中获得收益。构建工具链的目的是为了自动化开发和部署过程，以确保快速、可靠、预算友好地交付与创新。

我们发现成功构建一套 DevOps 工具链不是一个简单的事情。它需要实验和不断的完善，保证必要的流程是完全自动化的。

为什么你需要 DevOps 工具链

DevOps 工具链自动化了工作流中的所有技术元素。它能让不同团队在一个平台上进行工作，因此可以使你专注于业务战略以推动组织走向未来。

我们总结了五个实现 DevOps 工具链所带来的好处。你可以让管理层相信，是值得为 DevOps 工具链的开发投入资源和时间的。

更快、更高效的生产部署：DevOps 工具自动化了大部分软件开发进程。这会使产品开发专注于创新，交付更加敏捷，更领先于竞争对手。
预算和时间优化：将手动的任务转变为自动化会使你的组织节省时间和资源。当没有人为的错误和时间管理不足带来的额外支出，预算自然会得到优化。
高效的开发：DevOps 工具链会减少开发工作中不必要的延时，提高开发效率。前端、后端、质量测试人员的工作是一致的，所以没有人需要协调不同团队之间人员的交付。
更快的部署意味着更高的质量：DevOps 工具链保证了缺陷能够很快被解决，并且迅速完成高质量的部署进程。怎么样？它可以生成有针对性的告警，并将重要的事件通知给你的团队。这会让你主动地发现并解决潜在的问题，从而规避故障的不断的升级从而导致的客户服务不可用。
及时事件管理：DevOps 工具链有助于优化事件管理记录。它能够识别 IT 事件并且逐渐升级事件级别，通知给指定团队的成员，直到问题被解决。这意味着消息的接受和处理会更加的迅速，因为它们发送给了正确的目标。

DevOps 工具链的实践

对我的团队来说，DevOps 并不新鲜。我们已经敏捷开发很长时间了，并且我们总是热衷于探索最优的工作流。在我们的实践中，往往都是应用复杂性增加从而带来了自动化的需求。

这是我们为一个客户配置的工具链。这个项目包含了移动运营方案，连接了金融交易的所有参与者（卖方、买方、银行）。这个客户需要动态响应用户反馈并且将故障时间缩短到最小，从而来提高用户体验。我的团队设计了一套工具链用于自动化应用的维护和部署新功能。

title=

(Accedia, CC BY-NC-SA 4.0)

首先，我们团队编写了自动化测试，可以立即识别应用程序的变更。
当新版本已经准备就绪的时候，代码将被提交到 Gitlab 中。
通过 Gitlab，提交会自动触发 Jenkins 构建。
在 持续集成中，新的代码版本通过 Chai 和 Mocha 进行了测试，以检测是否运行正常。
当测试通过，持续部署阶段 将会开始并创建一个可用的 Docker 镜像并上传到 Sonatype 的 Nexus。（这是 Sonatype 公司的的一个开源工具）
最后，新版本应用会通过 Nexus 下载并且部署到线上环境中，例如 Docker 容器（持续部署阶段）

简而言之，每当有人在仓库中创建一个新的提交，又或者团队上传新的代码版本、功能、升级、缺陷修复等，应用程序包都会自动更新并且交付给客户。

这套系统拥有良好的事故控制能力以保证快速部署，但不以牺牲质量为代价。它对于用户的反馈是动态的，意味着新功能和旧功能的和更新只需要之前一半的时间，同时将故障时间降低到最低。

把它封装起来

一套完整并且正确实施的 DevOps 工具链可以从始至终推动你的创新计划并且加速部署。

根据你的需求，你的工具链可能看起来和这些不一样，但是我希望我们的工作流能够让你了解如何将自动化作为一种解决方案。

via: https://opensource.com/article/21/1/devops-tool-chain

作者：Tereza Denkova 选题：lujun9972 译者：AnyISalIn 校对：wxy

本文由 LCTT 原创编译，Linux中国荣誉推出

《代码英雄》第一季（4）：DevOps，拆掉那堵墙

Redhat 发布于 2020-08-19
另请参阅: 代码英雄,DevOps, 代码英雄
评论

代码英雄讲述了开发人员、程序员、黑客、极客和开源反叛者如何彻底改变技术前景的真实史诗。

什么是《代码英雄》
代码英雄 Command Line Heroes 是世界领先的企业开源软件解决方案供应商红帽（Red Hat）精心制作的原创音频播客，讲述开发人员、程序员、黑客、极客和开源反叛者如何彻底改变技术前景的真实史诗。该音频博客邀请到了谷歌、NASA 等重量级企业的众多技术大牛共同讲述开源、操作系统、容器、DevOps、混合云等发展过程中的动人故事。

本文是《代码英雄》系列播客第一季（4）：DevOps，拆掉那堵墙的音频脚本。

当应用开发的争斗暂告一段落，横亘在开发者与运维之间的那堵墙开始崩塌。在墙彻底倒塌的时候，墙两边的人都应该学会如何合作，彼此变得亲密无间。

不过到底什么是 DevOps？开发者一方的嘉宾，包括来自微软的 Scott Hanselman 和 Cindy Sridharan（即 @copyconstruct），他们从开发者的角度认为 DevOps 是一种惯实践。而来自运维一方的成员则他们一直在努力捍卫的东西。双方依然存在差异，不过因为 DevOps 的诞生，大家的合作效率会比之前更上一层楼。这集节目讲述了这种方法的诞生对于大家有多重要。

Saron Yitbarek：请你想象这样一堵墙：这堵墙从你目之所及的最右侧延伸到最左侧。墙比你高，你无法看见墙背后。你知道墙的另一侧有很多很多人，但你不清楚他们是否和你一样，不清楚他们是敌是友。

00:00:30 - Gordon Haff：开发者创造代码，然后把代码扔过墙丢给运维，之后发生的问题都是运维的责任了。

Richard Henshall：他们随心所欲，并不真正关心服务质量。

Sandra Henry-Stocker：墙这两面的人几乎做着相反的工作 —— 一方做出改变，另一方尽可能抵制那些改变。

Richard Henshall：但对于他们到底想共同达成什么，却没有在同一幅蓝图中规划过。

00:01:00 - Saron Yitbarek：我是 Saron Yitbarek，这里是《代码英雄》，由红帽公司推出的原创播客栏目。第四期，我们的标题是《DevOps，拆掉那堵墙》。

是的，数十年来，IT 界划分为各种角色。一边是开发者，他们要尽可能快地去创造更多变化。然后另一边是运维团队，他们要去阻止太多改变发生。与此同时，代码在没有充分共鸣和沟通的条件下，被盲目扔过两方之间的墙。怎样才能拆掉这堵墙呢？这需要一个重大的转变。

00:01:30 - Saron Yitbarek：开源运动震撼了整个战场。上一期，我们看到了新的敏捷方法论，它重视不间断的迭代改进，而这种对速度的要求将迫使我们改变彼此的工作方式。一群彼此孤立的人工作的速度是有极限的，而这个极限是一个问题，因为……

00:02:00 - Richard Henshall：因为都是为了更快的将产品推向市场、提高敏捷性、更多的迭代，而不是长期而大量的工作。

Saron Yitbarek： Richard Henshall 是 Ansible 的一位产品经理。

Richard Henshall：是的。还记得你以前下单购买服务器，四个月后到货。所有东西都整合在一起，所以整个堆栈是一个整体，要花几年时间来设计和建造那些东西。现在这种情况已经不存在了，对于很多组织来说，这种方法已经……已经寿终正寝，偶尔拿过来试试，然后放弃它。

00:02:30 - Saron Yitbarek：如今，像亚马逊这样的公司每分钟都会部署几次新的代码。想象一下，用按部就班的瀑布式工作流，简直不可能完成这些工作。所以为了继续快速完成工作，那些关于稳定性、安全性、可靠性的顾虑都会被运维丢到一边不管。

00:03:00 - Saron Yitbarek：同时，开发者也没有意识到他们的责任是创造真实环境可用的代码。开发者对稳定性和安全性毫无兴趣，但这些恰恰是我们需要解决的问题。所以，我们最终会有很多无谓的修改，在双方之间来来回回。

想象一下过度分工会如何拖慢公司效率，但开发法者很少被鼓励思考除代码之外的其他事务。

Sandra Henry-Stocker：他们的目录规模只会越来越臃肿，但他们从不清理。除非已经无法工作才不得不清理。

00:03:30 - Saron Yitbarek： Sandra Henry-Stocker 是位退休的系统管理员，为 IDG 杂志撰稿。

Sandra Henry-Stocker：我过去经常劝说别人，说，“嘿，你看，你用了这么多的磁盘空间。是不是有什么东西你可以整理一下，这样我们就有更多的存储空间来运行了 —— 因为服务器上的存储空间快用完了。”是的，我们经常经历这些事。

Saron Yitbarek：归根结底，这是一个心态问题。这种开发者和运维之间的态度分裂，一方不必去理解另一方的担忧。好吧，在过去这还没太大问题，但随着开发速度成为一种重要的优势，这种分裂的文化急需改进。孤立在自己的工作圈子里，效率太低了。

Jonah Horowitz 在 Stripe 的可靠性工程团队工作。他描述了即使开发人员和运维人员想一起工作，他们也无法做到。因为从某种意义上说，他们被安排在对立的团队中。

00:04:30 - Jonah Horowitz：运维团队经常以正常运行时间和可靠性来衡量，而提高正常运行时间的最大方法之一，就是减少系统的变化量。当然，发布新功能就是在改变系统，而做产品工作的软件工程师有动力去尽快发布尽可能多的功能。所以，当开发和运维的职责不同时，他们自然有了冲突。

00:05:00 - Saron Yitbarek：开发者致力于新建功能，运营致力于维持运行，两者目标相互矛盾。但就像我说的，由于对速度的需求越来越大，对快速迭代发布的需求越来越大，开发和运维之间的脱节已经到了一个临界点，必须要有所改变。

00:05:30 - Saron Yitbarek：在 2009 年左右，将开发和运维分开的那堵墙看起来像是监狱的墙。我们需要的是一种新的方法论，它能使开发和运维之间的隔阂顺畅过度，让双方以更快、更整体化的方式工作。

视频平台 Small Town Heroes 的首席技术官 Patrick Debois 为想要拆掉这堵墙的人发起了一场会议。他把这个的脑洞叫做 DevOps Days（开发运维日）。为了便利，他将其缩短为 DevOps，于是这场改革就有了名字。

00:06:00 - Saron Yitbarek：不过名字并不代表改革的一步，我们知道为什么我们需要 DevOps，但究竟该如何做？我们应该如何将开发和运维结合起来而不引发战争？幸运的是，我有 Scott Hanselman 来指导我。Scott 是微软 .NET 和 ASP.NET 的首席项目经理。

所以，Scott，我认识你确实有几年了，但感觉还是相见恨晚啊。

00:06:30 - Scott Hanselman：我也是，相见恨晚哈。

Saron Yitbarek：我想和你聊聊你如何成为一个开发者，和 DevOps 这些年的变化。觉得如何？

Scott Hanselman：嗯，听上去挺有意思。

00:07:00 - Saron Yitbarek：好的。我认为究竟什么是 DevOps 是一个好的开场问题。你会怎么定义它呢？

Scott Hanselman：在 2008 年，维基百科有个关于 DevOps 的定义确实很棒。它说，这是一套“惯例”，目的是在保证质量的前提下，缩短提交变更和变更投入生产之间的时间。所以，如果你想想，假如今天是周二，我检查了一些代码，而这些代码将在 6 月的版本中上线。这就很糟糕了，因为这不是持续集成，而是一年几次的集成。

00:07:30 - Scott Hanselman：如果你有一个健康的 DevOps 体系，如果你已经有“ 设置 - 上线 set - up ”的惯例，那么你就可以不断地将代码集成到生产中去。那么，你能做什么？你可以定义、创造怎样是最佳“惯例”，这将决定你能否成功。所以，我在周二检查的一些代码，周四就上线了。那么现在，为了保证高质量，最重要的事情就会是 —— 谨慎上线。

00:08:00 - Saron Yitbarek：这个定义真的很有趣呢，是个“惯例”。但我觉得当我听人们谈论 DevOps 时，它具体一点。他们谈论它就像它是一个角色、一个工作、一个职位或一个头衔。你觉得这与它是一套“惯例”的观点是否有冲突？

Scott Hanselman：我认为，当一套新的方法或一个新的流行语出现时，人们喜欢把它加在名片上。我不是不尊重那些正在收听这个播客，并且感到被我冒犯、正骂骂咧咧把名片掏出来看的人们。虽然，他们现在可能正要怒盖笔电、退出这个播客。

00:08:30 - Scott Hanselman：有一个帖子写得非常好，作者是 Brian Guthrie，他是一个脑力劳动者，在 SoundCloud 工作。他是一个超级聪明的人，几天前他在 Twitter 上的帖子中说到 DevOps。他说 DevOps 就是一套惯例，不是一个工作头衔、不是一个软件工具、不是一个你安装的东西、也不是一个团队的名字。

00:09:00 - Scott Hanselman：他的原话是：“DevOps 不是神奇的‘企业万能药’”。如果你没有好的惯例，如果你没有良好的习惯，你就没有 DevOps。所以，这更多的是一种心态，而不是摆出一个工作头衔，然后“我们要雇佣一个 DevOps 工程师，然后我们要把这些神奇的 DevOps 工程师撒到组织中。虽然整个组织没有意志力，也没有信奉 DevOps 的想法。” 所以，如果你认为 DevOps 是一个工具或者是用来安装的东西，那么你就完全理解错了。

00:09:30 - Saron Yitbarek：好吧，让我们回到过去，在 DevOps 这个名词出现之前，在我们往名片上写 DevOps 或者把它作为一套“惯例”来讨论之前。在 10 年前，你会如何描述开发者和那些运维人员之间的关系？

Scott Hanselman：那是相当的水火不容。举个例子，运维控制着生产，但开发人员从来没有接近过生产。我们站在一堵不透明的墙的两侧。我们在开发部的时候，尽可能地去做一些看起来像生产环境能用的东西，但实际上从来没有……从来没有像样的产品。

00:10:00 - Scott Hanselman：我们有相当多问题。我们的开发环境从各个方面来说都不像生产环境，所以你不可避免地会遇到那些 “嘿，它在生产环境中的工作方式和在开发环境中的不同” 的问题。然后，从开发到投入生产之间的间距是几周几周的长久间隔，所以你的大脑甚至不在正确的频道上。比如说，我在一月份的时候就在研究这个功能，现在四月份才刚刚上线，那么当 bug 不可避免地出现的时候，要等到六月份才能修复，我甚至不记得我们之前在干嘛。

所以运维团队的人，他们的工作是……他们的工作几乎就是有意识地让我们慢下来。好像他们的存在是为了让开发人员更慢，然后他们还觉得我们随时会让生产环境崩坏。

00:11:00 - Saron Yitbarek：那么为什么会这样呢？是对开发者想要做什么和他们做了什么不了解？还是信任问题？为什么会有这么大的冲突？

Scott Hanselman：我觉得你已经回答了，而且回答得很到位。你说的很对，确实是信任的问题。我觉得开发人员认为他们是特殊的，或者某些方面比 IT 人员更优越，而 IT 人员认为开发人员不尊重生产。

00:11:30 - Scott Hanselman：我认为这种文化的产生，一部分来源于高层。他们认为我们是不同的组织，并且我们的目标也不同。我认为软件业正在走向成熟，因为我们都意识到，无论业务是什么，我们写软件都是为了推动业务发展。

所以现在有种 “我们都在往正确的方向推进” 的感觉，就像他们说的，“专注一件产品并做到极致”。但这是需要绝对的信任，可 DevOps 工程师不信任产品工程师来部署代码，对吧？

00:12:00 - Scott Hanselman：但 DevOps 工程师传统上并不写代码，所以他们并不了解什么被修改了。所以他们对于在各个层面的人都缺乏信任。没有人理解部署过程，人们只信任自己，他们的心态……举个例子，就像“我只信任自己的工作。我不能相信 Saron 的工作，她甚至不知道她在干些什么。我会做完所有的事情。”

00:12:30 - Scott Hanselman：所以如果没有人真正理解这个系统，那么全栈工程师 full stack engineer 的概念就是一个神话。但是现在，我们开始将一整个组织称之为全栈。我们已经有了全产品所有权 full product ownership 这样的名词，敏捷方法论也出现了，也就是说每个人都应该拥有产品。社区对于软件所有权和对于代码的想法都慢慢发生了变化，这种改变带来了一个充满信任的环境。

00:13:00 - Saron Yitbarek：我是 Saron Yitbarek，你现在收听的是《代码英雄》，来自红帽公司的一档原创播客栏目。所以，要想让 DevOps 发挥出它的潜力，我们就需要双方都有更多的信任，这就意味着要有更多的沟通。回到 Richard Henshall 身上，他认为双方的共情是 DevOps 的基石。

00:13:30 - Richard Henshall：一些 DevOps 的从业者，一群真正优秀的从业者，都参与过这两种角色。我认为这才是真正的力量所在 —— 当人们真正做过了两种角色，而不是只看到其中一种。所以，你不该保持孤立，你实际上……你应该去和双方都一起工作一段时间。我想这才是让人恢复同理心的方法。

Saron Yitbarek：现在，这不仅仅是为了温情的沟通。Richard Henshall 所描述的是行业重点的转向 —— Scott 刚刚提到过。

00:14:00 - Saron Yitbarek：一个关于持续集成 continuous integration （CI）的观点。软件不仅要以小批量快速编写和发布，还要以小批量进行快速测试。这意味着，开发人员需要即时反馈他们正在编写的代码在现实世界中的表现。

随着上市时间从几个月缩短到几天，再到几个小时，我们四处寻找一套新的工具，可以将任何可以自动化的元素自动化。

00:14:30 - Gordon Haff：你需要一个全新的生态系统和工具，来最有效地进行 DevOps。

Saron Yitbarek： Gordon Haff 是一位红帽公司高级工程师。

Gordon Haff：我们看到有很多巨大的、DevOps 可以利用的新种集合工具和平台，它们都诞生于开源。

Saron Yitbarek： Gordon 是对的。新的集合工具是很庞大，关于开源这点他说的也对。在一个严格的专有系统中，自动化工具是不可能发展的。

00:15:00 - Gordon Haff：其中有很多监控工具，Prometheus 是其中一个常见的工具。它开始引起很多人兴趣，用于编排服务的 STO 也出自这里。

Saron Yitbarek： GitHub 让你跟踪变化，PagerDuty 管理数字业务，NFS 可以跨网络挂载文件系统，Jenkins 让你自动测试你的构建。

00:15:30 - Saron Yitbarek：这么多工具，这么多自动化流程。最终的结果是，开发人员可以将他们的变更直接推送到生产现场，自动创建构造，实行经过严格管理的编译与针对性的自动测试。Sandra Henry-Stocker 描述了这是怎样的变化。

Sandra Henry-Stocker：所以，我可以把我正在工作编写的东西快速部署。我可以只在一个系统上，通过命令行控制许多系统，而不是必须在在很多不同的系统上工作，也不用学习就可以利用网络，将代码部署到其他机器上。

00:16:00 - Sandra Henry-Stocker：现在，在计算机系统中进行改动更容易了。坐在一个地方，就能实行一切操作。

Saron Yitbarek：自动化工具已经解决了速度问题。但我不希望我们只赞美工具，而忽略了实际的方法论，文化的转变。Scott Hanselman 和我谈到了这个微妙的界限。

00:16:30 - Saron Yitbarek：你在这次谈话开始时说，DevOps 是一套惯例，是一种心态，是一种思维方式。听起来，我们创造的工具是我们应该思考和操作方式的具体代码实现。

Scott Hanselman：我喜欢这句话，你真是个天才。没错，我们以前让产品开发在 Word 文档中写下这些代码是如何工作的。他们写的是规范，对吧？这些文档过期了吗？

00:17:00 - Saron Yitbarek：没错。（答非所问）

Scott Hanselman：哈？

Saron Yitbarek：好吧，我只是很高兴 Scott 刚才说我是天才。但我也确实认为，这些工具几乎是我们文化转变的象征。它们鼓励我们拓宽我们的角色定义。我们开发者已经被迫，至少偶尔关注代码的运行。这样一来，开发和运维的主要职责就部分统一了。事实上，DevOps 的兴起告诉我们的是，在一个速度不断提升的世界里，没有人能够保持孤岛状态。

00:17:30 - Saron Yitbarek： Jonah Horowitz 曾在湾区多家公司工作，包括 Quantcast 和 Netflix。他说即使是世界上一些最大的公司，也从这个角度重新塑造了他们的文化。

Jonah Horowitz：我们在文化上得到了整个公司的认同，就像，“这就是我们要部署软件的方式，我们将以小批量的方式进行部署，我们将使用这些程序帮助部署。” 如果 DevOps 只是被运营团队所驱动，我不认为它可以……我不认为它可以成功。

00:18:00 - Jonah Horowitz：这必须成为公司的管理层和领导层所认同的东西才能发挥作用，而这件事很大程度上，意味着一种文化转变。

Saron Yitbarek：当 MacKenzie 对 800 名 CIO 和 IT 高管进行调查时，80% 的人表示，他们正在规划让自己的一部分下属组织实施 DevOps，超过一半的人计划到 2020 年，在全公司范围内实施。高管们意识到，自动化工具可以提升交付速度。

00:18:30 - Saron Yitbarek：这些人过去也是这样的人，他们习惯于让一个货板先到达数据中心，然后在新机器上线之前让它在那里放上整整一个月。不过在今天，如果你等待的时间超过 10 分钟，就说明你做错了什么。随着竞争对手的速度增加，没有人能够承受得起落后。

00:19:00 - Saron Yitbarek：我可以想象，运维团队一定很紧张，因为他们把所有的工具都交给开发人员。运维团队习惯了做成年人，而现在叫他们把车钥匙交给一贯的孩子 —— 开发人员？呀，我想我们开发人员正在学习，如何在不破坏东西的前提下快速移动。但随着 DevOps 革命的尘埃落定，变化最大的可能是运维团队。

00:19:30 - Saron Yitbarek： DevOps 是否真的威胁到了运维的存在？开发是否在用它闪亮的新工具来吃掉运维？Cindy Sridharan 是一位开发者，她写了一篇长篇调查文章来讨论这些问题。在你的文章和博客中，你提到运维人员对事情这样的发展并不一定满意。到底发生了什么？你会说什么？

Cindy Sridharan：这么说吧，DevOps 的理想是责任共享。开发者和运维将有，就像你知道的，更多的是五五分成，以真正确保软件的整体交付。

00:20:00 - Cindy Sridharan：我认为很多运维工程师的不快乐源于这样一个事实，那就是这些改变都没有实际功效。他们仍然是总被鸡蛋挑骨头的人，他们仍然是总做苦力工作的那些人，他们还是那些主要肩负着实际运行应用的责任的人，而开发者不一定要做得足够好。

Saron Yitbarek：这个问题在未来几年将至关重要。DevOps 的作用到底有多大？随着我们的自动化进程，运维的作用是会被削弱，还是会发生转变？

00:20:30 - Saron Yitbarek：但是我们要记住，DevOps 不仅仅是工具和新技术的应用。这种方法论实际上是在塑造技术，反过来技术也在塑造方法论，这样就有了一个神奇的反馈循环。文化造就了工具，而工具又强化了文化。

00:22:00 - Saron Yitbarek：最后，我们在节目开头描述的那堵墙，也就是把开发和运维划分开来的那堵墙，我甚至不知道五年后“把你的代码扔过墙”的比喻对一个开发者来说是否有意义，如果五年后大家都听不懂这个比喻，那真是一件大好事。不过目前为止的访谈很有价值，我听到了很多新的故事。

现在说话的是云架构师 Richard Henshall。

Richard Henshall：我觉得 DevOps 开始让人们意识到对方关心的是什么，我看到了更多对彼此的理解。

00:23:00 - Saron Yitbarek：现在是系统管理员 Jonah Horowitz。

00:23:00 - Jonah Horowitz：我认为你需要很棒的技巧来写出真正好的软件，我在与我合作过最棒的开发者身上看到了一件事，那就是他们真的，他们贡献了关于的软件工程新技巧，或者说他们推动了软件开发这个行业的发展。

Saron Yitbarek：最后一个是系统管理员 Sandra Henry-Stocker。

Sandra Henry-Stocker：我认为，开发者会变得更加精明、更加谨慎。他们始终要提升自己的技能，我知道这需要很多辛苦的学习。

00:23:30 - Saron Yitbarek： DevOps 是个爱的结晶。原来，在那堵墙的另一边还有一些朋友，很高兴认识你们。所以，坦白一下，我以前总觉得 DevOps 很无聊，就是一堆硬核的自动化脚本和扩展问题。我的抵触情绪有一部分是出于它的实践难度。作为开发者，我每周都要面对一些新出来的工具，一些新的框架。DevOps 一直是那些可怕的、快速变化的一部分。但现在，尤其是听了这些故事之后，我明白了。

00:24:00 - Saron Yitbarek： DevOps 不仅仅是其工具。它是教导我们如何合作，更快地构建更好的产品的方法。

好消息是，随着为你我这样的开发者准备的新平台出现，我们的工作变得更好、更快、更能适应不同的环境，我的业务圈也可以不断扩大。你会看到人们将 DevOps 扩大到安全部分，所以我们能得到 Sec DevOps。或者他们开始包含商务，那我们就得到了 Business DevOps。我们现在要辩论的话题是：对于一个开发者来说，不仅要了解如何使用这些工具，还有了解所有 DevOps 的东西是如何工作的必要吗？以及我们需要所有开发者都去了解这个新世界吗？

00:24:30 - Saron Yitbarek：这场辩论的结果将决定未来一期《代码英雄》的内容。

你可能已经注意到，在所有关于工具和自动化的谈话中，我漏掉了一些工具。好吧，我把这些留到下一期，当所有这些 DevOps 自动化达到光速时，我们将追踪容器的崛起。

00:25:00 - Saron Yitbarek：是的，这些都会留到第五期。

《代码英雄》是红帽公司推出的原创播客栏目。想要了解更多关于本期节目和以往节目的信息，请访问 redhat.com/commandlineheroes 。在那里，你还可以注册我们的新闻资讯。想免费获得新剧集的自动推送，请务必订阅该节目。

00:25:30 - Saron Yitbarek：只要在苹果播客、Spotify、Google Play、CastBox 中搜索《代码英雄》，或者通过其他方式收听，并点击订阅，这样你就能在第一时间知道最新剧集。我是 Saron Yitbarek。感谢您的收听，编程不止。

什么是 LCTT SIG 和 LCTT LCRH SIG
LCTT SIG 是 LCTT 特别兴趣小组 Special Interest Group ，LCTT SIG 是针对特定领域、特定内容的翻译小组，翻译组成员将遵循 LCTT 流程和规范，参与翻译，并获得相应的奖励。LCRH SIG 是 LCTT 联合红帽（Red Hat）发起的 SIG，当前专注任务是《代码英雄》系列播客的脚本汉化，已有数十位贡献者加入。敬请每周三、周五期待经过我们精心翻译、校对和发布的译文。
欢迎加入 LCRH SIG 一同参与贡献，并领取红帽（Red Hat）和我们联合颁发的专属贡献者证书。

via: https://www.redhat.com/en/command-line-heroes/season-1/devops-tear-down-that-wall

作者：Red Hat 选题：bestony 译者：LikChung 校对：acyanbird

本文由 LCRH 原创编译，Linux中国荣誉推出

DevOps 和敏捷：究竟有什么区别？

Taz Brown 发布于 2020-03-24
另请参阅: 软件开发,DevOps, 敏捷
评论

两者之间的区别在于开发完毕之后发生的事情。

早期，软件开发并没有特定的管理流程。随后出现了瀑布开发流程 Waterfall ，它提出软件开发活动可以用开发和构建应用所耗费的时间来定义。

那时候，由于在开发流程中没有审查环节和权衡考虑，常常需要花费很长的时间来开发、测试和部署软件。交付的软件也是带有缺陷和 Bug 的质量较差的软件，而且交付时间也不满足要求。那时候软件项目管理的重点是长期而拖沓的计划。

瀑布流程与三重约束模型 triple constraint model 相关，三重约束模型也称为项目管理三角形 project management triangle 。三角形的每一个边代表项目管理三要素的一个要素: 范围、时间和成本。正如 Angelo Baretta 写到，三重约束模型“认为成本是时间和范围的函数，这三个约束以一种确定的、可预测的方式相互作用。……如果我们想缩短时间表（时间），就必须增加成本。如果我们想增加范围，就必须增加成本或时间。”

从瀑布流程过渡到敏捷开发

瀑布流程来源于生产和工程领域，这些领域适合线性化的流程：正如房屋封顶之前需要先盖好支撑墙。相似地，软件开发问题被认为可以通过提前做好计划来解决。从头到尾，开发流程均由路线图清晰地定义，沿着路线图就可以得到最终交付的产品。

最终，瀑布模型被认为对软件开发是不利的而且违反人的直觉，因为通常直到开发流程的最后才能体现出项目的价值，这导致许多项目最终都以失败告终。而且，在项目结束前客户看不到任何可以工作的软件。

敏捷 Agile 采用了一种不同的方法，它抛弃了规划整个项目，承诺估计的时间点，简单的遵循计划。与瀑布流程相反，它假设和拥抱不确定性。它的理念是以响应变化代替讨论过去，它认为变更是客户需求的一部分。

敏捷价值观

敏捷由敏捷宣言 Agile Manifesto 代言，敏捷宣言定义了 12 条原则（LCTT 译注：此处没有采用本文原本的简略句式，而是摘录了来自敏捷软件开发宣言官方的中文译本）：

我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。
欣然面对需求变化，即使在开发后期也一样。
经常交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。
业务人员和开发人员必须相互合作，项目中的每一天都不例外。
激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。
面对面沟通是传递信息的最佳的也是效率最高的方法。
可工作的软件是进度的首要度量标准。
敏捷流程倡导可持续的开发，责任人、开发人员和用户要能够共同维持其步调稳定延续。
坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。
以简洁为本，它是极力减少不必要工作量的艺术。
最好的架构，需求和设计出自自组织团队
团队定期地反思如何能提高成效，并依此调整自身的举止表现。

敏捷的四个核心价值观是（LCTT 译注：此处译文同样来自敏捷软件开发宣言官方）：

个体和互动 高于流程和工具
工作的软件 高于详尽的文档
客户合作 高于合同谈判
响应变化 高于遵循计划

这与瀑布流程死板的计划风格相反。在敏捷流程中，客户是开发团队的一员，而不仅仅是在项目开始时参与项目需求的定义，在项目结束时验收最终的产品。客户帮忙团队完成验收标准，并在整个过程中保持投入。另外，敏捷需要整个组织的变化和持续的改进。开发团队和其他团队一起合作，包括项目管理团队和测试团队。做什么和计划什么时候做由指定的角色领导，并由整个团队同意。

敏捷软件开发

敏捷软件开发需要自适应的规划、演进式的开发和交付。许多软件开发方法、框架和实践遵从敏捷的理念，包括：

Scrum
看板 Kanban （可视化工作流）
极限编程 Xtreme Programming （XP）
精益方法 Lean
DevOps
特性驱动开发 Feature-Driven Development （FDD）
测试驱动开发 Test-Driven Development （TDD）
水晶方法 Crystal
动态系统开发方法 Dynamic Systems Development Method （DSDM）
自适应软件开发 Adaptive Software Development （ASD）

所有这些已经被单独用于或一起用于开发和部署软件。最常用的是 Scrum、看板（或 Scrumban）和 DevOps。

Scrum 是一个框架，采用该框架的团队通常由一个 Scrum 教练、产品经理和开发人员组成，该团队以跨职能、自主的工作方式运作，能够加快软件交付速度从而给客户带来巨大的商业价值。其关注点是较小增量的快速迭代。

看板是一个敏捷框架，有时也叫工作流管理系统，它能帮助团队可视化他们的工作从而最大化效率（因而变得敏捷）。看板通常由数字或物理展示板来呈现。团队的工作在展示板上随着进度而移动，例如从未启动到进行中，一直到测试中、已完成。看板使得每个团队成员可以随时查看到所有工作的状态。

DevOps 价值观

DevOps 是一种文化，是一种思维状态，是一种软件开发的方式或者基础设施的方式，也是一种构建和部署软件和应用的方式。它假设开发和运维之间没有隔阂，他们一起合作，没有矛盾。

DevOps 基于其它两个领域的实践: 精益和敏捷。DevOps 不是一个公司内的岗位或角色；它是一个组织或团队对持续交付、持续部署和持续集成的坚持不懈的追求。Gene Kim（Phoenix 项目和 Unicorn 项目的作者）认为，有三种方式定义 DevOps 的理念：

第一种: 流程原则
第二种: 反馈原则
第三种: 持续学习原则

DevOps 软件开发

DevOps 不会凭空产生；它是一种灵活的实践，它的本质是一种关于软件开发和 IT 或基础设施实施的共享文化和思维方式。

当你想到自动化、云、微服务时，你会想到 DevOps。在一次访谈中，《加速构建和扩张高性能技术组织》的作者 Nicol Forsgren、Jez Humble 和 Gene Kim 这样解释到：

软件交付能力很重要，它极大地影响到组织的成果，例如利润、市场份额、质量、客户满意度以及组织战略目标的达成。
优秀的团队能达到很高的交付量、稳定性和质量；他们并没有为了获得这些属性而进行取舍。
你可以通过实施精益、敏捷和 DevOps 中的实践来提升能力。
实施这些实践和能力也会影响你的组织文化，并且会进一步对你的软件交付能力和组织能力产生有益的提升。
懂得怎样改进能力需要做很多工作。

DevOps 和敏捷的对比

DevOps 和敏捷有相似性，但是它们不完全相同，一些人认为 DevOps 比敏捷更好。为了避免造成混淆，深入地了解它们是很重要的。

相似之处

毫无疑问，两者都是软件开发技术。
敏捷已经存在了 20 多年，DevOps 是最近才出现的。
两者都追求软件的快速开发，它们的理念都基于怎样在不伤害客户或运维利益的情况下快速开发出软件。

不同之处

两者的差异在于软件开发完成后发生的事情。
- 在 DevOps 和敏捷中，都有软件开发、测试和部署的阶段。然而，敏捷流程在这三个阶段之后会终止。相反，DevOps 包括后续持续的运维。因此，DevOps 会持续的监控软件运行情况和进行持续的开发。
敏捷中，不同的人负责软件的开发、测试和部署。而 DevOps 工程角色负责所有活动，开发即运维，运维即开发。
DevOps 更关注于削减成本，而敏捷则是精益和减少浪费的代名词，侧重于像敏捷项目会计和最小可行产品的概念。
敏捷专注于并体现了经验主义（适应、透明和检查），而不是预测性措施。

敏捷	DevOps
从客户得到反馈	从自己得到反馈
较小的发布周期	较小的发布周期，立即反馈
聚焦于速度	聚焦于速度和自动化
对业务不是最好	对业务最好

总结

敏捷和 DevOps 是截然不同的，尽管它们的相似之处使人们认为它们是相同的。这对敏捷和 DevOps 都是一种伤害。

根据我作为一名敏捷专家的经验，我发现对于组织和团队从高层次上了解敏捷和 DevOps 是什么，以及它们如何帮助团队更高效地工作，更快地交付高质量产品从而提高客户满意度非常有价值。

敏捷和 DevOps 绝不是对抗性的（或至少没有这个意图）。在敏捷革命中，它们更像是盟友而不是敌人。敏捷和 DevOps 可以相互协作一致对外，因此可以在相同的场合共存。

via: https://opensource.com/article/20/2/devops-vs-agile

作者：Taz Brown 选题：lujun9972 译者：messon007 校对：wxy

本文由 LCTT 原创编译，Linux中国荣誉推出

DevOps 专业人员如何成为网络安全拥护者

Jessica Repka 发布于 2019-10-25
另请参阅: 观点,DevOps, DevSecOps
评论

打破信息孤岛，成为网络安全的拥护者，这对你、对你的职业、对你的公司都会有所帮助。

安全是 DevOps 中一个被误解了的部分，一些人认为它不在 DevOps 的范围内，而另一些人认为它太过重要（并且被忽视），建议改为使用 DevSecOps。无论你同意哪一方的观点，网络安全都会影响到我们每一个人，这是很明显的事实。

每年，黑客行为的统计数据都会更加令人震惊。例如，每 39 秒就有一次黑客行为发生，这可能会导致你为公司写的记录、身份和专有项目被盗。你的安全团队可能需要花上几个月（也可能是永远找不到）才能发现这次黑客行为背后是谁，目的是什么，人在哪，什么时候黑进来的。

运维专家面对这些棘手问题应该如何是好？呐我说，现在是时候成为网络安全的拥护者，变为解决方案的一部分了。

孤岛势力范围的战争

在我和我本地的 IT 安全（ITSEC）团队一起肩并肩战斗的岁月里，我注意到了很多事情。一个很大的问题是，安全团队和 DevOps 之间关系紧张，这种情况非常普遍。这种紧张关系几乎都是来源于安全团队为了保护系统、防范漏洞所作出的努力（例如，设置访问控制或者禁用某些东西），这些努力会中断 DevOps 的工作并阻碍他们快速部署应用程序。

你也看到了，我也看到了，你在现场碰见的每一个人都有至少一个和它有关的故事。一小撮的怨恨最终烧毁了信任的桥梁，要么是花费一段时间修复，要么就是两个团体之间开始一场小型的地盘争夺战，这个结果会使 DevOps 实现起来更加艰难。

一种新观点

为了打破这些孤岛并结束势力战争，我在每个安全团队中都选了至少一个人来交谈，了解我们组织日常安全运营里的来龙去脉。我开始做这件事是出于好奇，但我持续做这件事是因为它总是能带给我一些有价值的、新的观点。例如，我了解到，对于每个因为失败的安全性而被停止的部署，安全团队都在疯狂地尝试修复 10 个他们看见的其他问题。他们反应的莽撞和尖锐是因为他们必须在有限的时间里修复这些问题，不然这些问题就会变成一个大问题。

考虑到发现、识别和撤销已完成操作所需的大量知识，或者指出 DevOps 团队正在做什么（没有背景信息）然后复制并测试它。所有的这些通常都要由人手配备非常不足的安全团队完成。

这就是你的安全团队的日常生活，并且你的 DevOps 团队看不到这些。ITSEC 的日常工作意味着超时加班和过度劳累，以确保公司，公司的团队，团队里工作的所有人能够安全地工作。

成为安全拥护者的方法

这些是你成为你的安全团队的拥护者之后可以帮到它们的。这意味着，对于你做的所有操作，你必须仔细、认真地查看所有能够让其他人登录的方式，以及他们能够从中获得什么。

帮助你的安全团队就是在帮助你自己。将工具添加到你的工作流程里，以此将你知道的要干的活和他们知道的要干的活结合到一起。从小事入手，例如阅读公共漏洞披露（CVE），并将扫描模块添加到你的 CI/CD 流程里。对于你写的所有代码，都会有一个开源扫描工具，添加小型开源工具（例如下面列出来的）在长远看来是可以让项目更好的。

容器扫描工具：

代码扫描工具：

Kubernetes 安全工具：

保持你的 DevOps 态度

如果你的工作角色是和 DevOps 相关的，那么学习新技术和如何运用这项新技术创造新事物就是你工作的一部分。安全也是一样。我在 DevOps 安全方面保持到最新，下面是我的方法的列表。

每周阅读一篇你工作的方向里和安全相关的文章.
每周查看 CVE 官方网站，了解出现了什么新漏洞.
尝试做一次黑客马拉松。一些公司每个月都要这样做一次；如果你觉得还不够、想了解更多，可以访问 Beginner Hack 1.0 网站。
每年至少一次和那你的安全团队的成员一起参加安全会议，从他们的角度来看事情。

成为拥护者是为了变得更好

你应该成为你的安全的拥护者，下面是我们列出来的几个理由。首先是增长你的知识，帮助你的职业发展。第二是帮助其他的团队，培养新的关系，打破对你的组织有害的孤岛。在你的整个组织内建立由很多好处，包括设置沟通团队的典范，并鼓励人们一起工作。你同样能促进在整个组织中分享知识，并给每个人提供一个在安全方面更好的内部合作的新契机。

总的来说，成为一个网络安全的拥护者会让你成为你整个组织的拥护者。

via: https://opensource.com/article/19/9/devops-security-champions

作者：Jessica Repka 选题：lujun9972 译者：hopefully2333 校对：wxy

本文由 LCTT 原创编译，Linux中国荣誉推出

变异测试是测试驱动开发（TDD）的演变

Alex Bunardzic 发布于 2019-10-17
另请参阅: 观点,DevOps, TDD
评论

测试驱动开发技术是根据大自然的运作规律创建的，变异测试自然成为 DevOps 演变的下一步。

在 “故障是无懈可击的开发运维中的一个特点”，我讨论了故障在通过征求反馈来交付优质产品的过程中所起到的重要作用。敏捷 DevOps 团队就是用故障来指导他们并推动开发进程的。测试驱动开发 Test-driven development （TDD）是任何敏捷 DevOps 团队评估产品交付的必要条件。以故障为中心的 TDD 方法仅在与可量化的测试配合使用时才有效。

TDD 方法仿照大自然是如何运作的以及自然界在进化博弈中是如何产生赢家和输家为模型而建立的。

自然选择

title=

1859 年，查尔斯·达尔文 Charles Darwin 在他的《物种起源 On the Origin of Species 》一书中提出了进化论学说。达尔文的论点是，自然变异是由生物个体的自发突变和环境压力共同造成的。环境压力淘汰了适应性较差的生物体，而有利于其他适应性强的生物的发展。每个生物体的染色体都会发生变异，而这些自发的变异会携带给下一代（后代）。然后在自然选择下测试新出现的变异性 —— 当下存在的环境压力是由变异性的环境条件所导致的。

这张简图说明了调整适应环境条件的过程。

title=

图1. 不同的环境压力导致自然选择下的不同结果。图片截图来源于理查德·道金斯的一个视频。

该图显示了一群生活在自己栖息地的鱼。栖息地各不相同（海底或河床底部的砾石颜色有深有浅），每条鱼长的也各不相同（鱼身图案和颜色也有深有浅）。

这张图还显示了两种情况（即环境压力的两种变化）：

捕食者在场
捕食者不在场

在第一种情况下，在砾石颜色衬托下容易凸显出来的鱼被捕食者捕获的风险更高。当砾石颜色较深时，浅色鱼的数量会更少一些。反之亦然，当砾石颜色较浅时，深色鱼的数量会更少。

在第二种情况下，鱼完全放松下来进行交配。在没有捕食者和没有交配仪式的情况下，可以预料到相反的结果：在砾石背景下显眼的鱼会有更大的机会被选来交配并将其特性传递给后代。

选择标准

变异性在进行选择时，绝不是任意的、反复无常的、异想天开的或随机的。选择过程中的决定性因素通常是可以度量的。该决定性因素通常称为测试或目标。

一个简单的数学例子可以说明这一决策过程。（在该示例中，这种选择不是由自然选择决定的，而是由人为选择决定。）假设有人要求你构建一个小函数，该函数将接受一个正数，然后计算该数的平方根。你将怎么做？

敏捷 DevOps 团队的方法是快速验证失败。谦虚一点，先承认自己并不真的知道如何开发该函数。这时，你所知道的就是如何描述你想做的事情。从技术上讲，你已准备好进行单元测试。

“ 单元测试 unit test ”描述了你的具体期望结果是什么。它可以简单地表述为“给定数字 16，我希望平方根函数返回数字 4”。你可能知道 16 的平方根是 4。但是，你不知道一些较大数字（例如 533）的平方根。

但至少，你已经制定了选择标准，即你的测试或你的期望值。

进行故障测试

.NET Core 平台可以演示该测试。.NET 通常使用 xUnit.net 作为单元测试框架。（要跟随进行这个代码示例，请安装 .NET Core 和 xUnit.net。）

打开命令行并创建一个文件夹，在该文件夹实现平方根解决方案。例如，输入：

mkdir square_root

再输入：

cd square_root

为单元测试创建一个单独的文件夹：

mkdir unit_tests

进入 unit_tests 文件夹下（cd unit_tests），初始化 xUnit 框架：

dotnet new xunit

现在，转到 square_root 下, 创建 app 文件夹:

mkdir app
cd app

如果有必要的话，为你的代码创建一个脚手架：

dotnet new classlib

现在打开你最喜欢的编辑器开始编码！

在你的代码编辑器中，导航到 unit_tests 文件夹，打开 UnitTest1.cs。

将 UnitTest1.cs 中自动生成的代码替换为：

using System;
using Xunit;
using app;

namespace unit_tests{

   public class UnitTest1{
       Calculator calculator = new Calculator();

       [Fact]
       public void GivenPositiveNumberCalculateSquareRoot(){
           var expected = 4;
           var actual = calculator.CalculateSquareRoot(16);
           Assert.Equal(expected, actual);
       }
   }
}

该单元测试描述了变量的期望值应该为 4。下一行描述了实际值。建议通过将输入值发送到称为calculator 的组件来计算实际值。对该组件的描述是通过接收数值来处理CalculateSquareRoot 信息。该组件尚未开发。但这并不重要，我们在此只是描述期望值。

最后，描述了触发消息发送时发生的情况。此时，判断期望值是否等于实际值。如果是，则测试通过，目标达成。如果期望值不等于实际值，则测试失败。

接下来，要实现称为 calculator 的组件，在 app 文件夹中创建一个新文件，并将其命名为Calculator.cs。要实现计算平方根的函数，请在此新文件中添加以下代码：

namespace app {
   public class Calculator {
       public double CalculateSquareRoot(double number) {
           double bestGuess = number;
           return bestGuess;
       }
   }
}

在测试之前，你需要通知单元测试如何找到该新组件（Calculator）。导航至 unit_tests 文件夹，打开 unit_tests.csproj 文件。在 <ItemGroup> 代码块中添加以下代码：

<ProjectReference Include="../app/app.csproj" />

保存 unit_test.csproj 文件。现在，你可以运行第一个测试了。

切换到命令行，进入 unit_tests 文件夹。运行以下命令：

dotnet test

运行单元测试，会输出以下内容：

title=

图2. 单元测试失败后 xUnit 的输出结果

正如你所看到的，单元测试失败了。期望将数字 16 发送到 calculator 组件后会输出数字 4，但是输出（Actual）的是 16。

恭喜你！创建了第一个故障。单元测试为你提供了强有力的反馈机制，敦促你修复故障。

修复故障

要修复故障，你必须要改进 bestGuess。当下，bestGuess 仅获取函数接收的数字并返回。这不够好。

但是，如何找到一种计算平方根值的方法呢？我有一个主意 —— 看一下大自然母亲是如何解决问题的。

效仿大自然的迭代

在第一次（也是唯一的）尝试中要得出正确值是非常难的（几乎不可能）。你必须允许自己进行多次尝试猜测，以增加解决问题的机会。允许多次尝试的一种方法是进行迭代。

要迭代，就要将 bestGuess 值存储在 previousGuess 变量中，转换 bestGuess 的值，然后比较两个值之间的差。如果差为 0，则说明问题已解决。否则，继续迭代。

这是生成任何正数的平方根的函数体：

double bestGuess = number;
double previousGuess;

do {
   previousGuess = bestGuess;
   bestGuess = (previousGuess + (number/previousGuess))/2;
} while((bestGuess - previousGuess) != 0);

return bestGuess;

该循环（迭代）将 bestGuess 值集中到设想的解决方案。现在，你精心设计的单元测试通过了！

title=

图 3. 单元测试通过了。

迭代解决了问题

正如大自然母亲解决问题的方法，在本练习中，迭代解决了问题。增量方法与逐步改进相结合是获得满意解决方案的有效方法。该示例中的决定性因素是具有可衡量的目标和测试。一旦有了这些，就可以继续迭代直到达到目标。

关键点!

好的，这是一个有趣的试验，但是更有趣的发现来自于使用这种新创建的解决方案。到目前为止，bestGuess 从开始一直把函数接收到的数字作为输入参数。如果更改 bestGuess 的初始值会怎样？

为了测试这一点，你可以测试几种情况。首先，在迭代多次尝试计算 25 的平方根时，要逐步细化观察结果：

title=

图 4. 通过迭代来计算 25 的平方根。

以 25 作为 bestGuess 的初始值，该函数需要八次迭代才能计算出 25 的平方根。但是，如果在设计 bestGuess 初始值上犯下荒谬的错误，那将怎么办？尝试第二次，那 100 万可能是 25 的平方根吗？在这种明显错误的情况下会发生什么？你写的函数是否能够处理这种低级错误。

直接来吧。回到测试中来，这次以一百万开始：

title=

图 5. 在计算 25 的平方根时，运用逐步求精法，以 100 万作为 bestGuess 的初始值。

哇！以一个荒谬的数字开始，迭代次数仅增加了两倍（从八次迭代到 23 次）。增长幅度没有你直觉中预期的那么大。

故事的寓意

啊哈！当你意识到，迭代不仅能够保证解决问题，而且与你的解决方案的初始猜测值是好是坏也没有关系。不论你最初理解得多么不正确，迭代过程以及可衡量的测试/目标，都可以使你走上正确的道路并得到解决方案。

图 4 和 5 显示了陡峭而戏剧性的燃尽图。一个非常错误的开始，迭代很快就产生了一个绝对正确的解决方案。

简而言之，这种神奇的方法就是敏捷 DevOps 的本质。

回到一些更深层次的观察

敏捷 DevOps 的实践源于人们对所生活的世界的认知。我们生活的世界存在不确定性、不完整性以及充满太多的困惑。从科学/哲学的角度来看，这些特征得到了海森堡的不确定性原理 Heisenberg’s Uncertainty Principle （涵盖不确定性部分），维特根斯坦的逻辑论哲学 Wittgenstein’s Tractatus Logico-Philosophicus （歧义性部分），哥德尔的不完全性定理 Gödel’s incompleteness theorems （不完全性方面）以及热力学第二定律 Second Law of Thermodynamics （无情的熵引起的混乱）的充分证明和支持。

简而言之，无论你多么努力，在尝试解决任何问题时都无法获得完整的信息。因此，放下傲慢的姿态，采取更为谦虚的方法来解决问题对我们会更有帮助。谦卑会给为你带来巨大的回报，这个回报不仅是你期望的一个解决方案，还会有它的副产品。

总结

大自然在不停地运作，这是一个持续不断的过程。大自然没有总体规划。一切都是对先前发生的事情的回应。反馈循环是非常紧密的，明显的进步/倒退都是逐步实现的。大自然中随处可见，任何事物的都在以一种或多种形式逐步完善。

敏捷 DevOps 是工程模型逐渐成熟的一个非常有趣的结果。DevOps 基于这样的认识，即你所拥有的信息总是不完整的，因此你最好谨慎进行。获得可衡量的测试（例如，假设、可测量的期望结果），进行简单的尝试，大多数情况下可能失败，然后收集反馈，修复故障并继续测试。除了同意每个步骤都必须要有可衡量的假设/测试之外，没有其他方法。

在本系列的下一篇文章中，我将仔细研究变异测试是如何提供及时反馈来推动实现结果的。

via: https://opensource.com/article/19/8/mutation-testing-evolution-tdd

作者：Alex Bunardzic 选题：lujun9972 译者：Morisun029 校对：wxy

本文由 LCTT 原创编译，Linux中国荣誉推出