Willy-peter Schaub 发布的文章

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

 title=

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

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

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

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

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

更重要的是,什么是你不应该自动化的?

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

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

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

 title=

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

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

  1. 可视化所有活动: 列出用户、过滤用户、重置许可证。
  2. 确定利益相关者,即运营和授权团队。
  3. 措施:
* 总交货时间(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 APIAzure 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中国 荣誉推出

统一的持续集成与持续交付的流水线的构想是一种梦想吗?

当我加入 WorkSafeBC 负责云端运维和工程流程优化的云端运维团队时,我和大家分享了我的梦想,那就是一个工具化的流水线,每一个产品都可以持续集成和持续交付。

根据 Lukas Klose 的说法, 流程 flow (在软件工程的语境内)是“软件系统以稳定和可预测的速度创造价值的状态”。我认为这是最大的挑战和机遇之一,特别是在复杂的新兴解决方案领域。我力求通过一种持续、高效和优质的解决方案,提供一种持续交付模式,并且能够构建正确的事物让我们的用户感到满意。想办法把我们的系统分解成更小的碎片,这些碎片本身是有价值的,使团队能够渐进式地交付价值。这需要业务和工程部门改变思维方式。

持续集成和持续交付的(CI/CD)流水线

CI/CD 流水线是一种 DevOps 实践,用于更频繁、一致、可靠的地交付代码变更。它可以帮助敏捷开发团队提高部署频率,减少变更准备时间变更失败率和关键绩效指标(KPI)的平均恢复时间,从而提高质量并且实现更快的交付。唯一的先决条件就是坚实的开发流程、对质量的心态和对需求从构想到废弃的责任心,以及一个全面的流水线(如下图所示)。

 title=

它简化了工程流程和产品,以稳定基础架构环境;优化工作流程;并创建一致的、可重复的、自动化的任务。正如 Dave Snowden 的 Cynefin Sensemaking 模型所说的那样,这样就允许我们将复杂不可解决的任务变成了复杂可解决的任务,降低了维护成本,提高了质量和可靠性。

精简流程的一部分是将 浪费实践类型 wasteful practice types Muri(过载)、Mura(变异)和 Muda(浪费)的浪费降低最低。

  • Muri(过载):避免过度工程化,避免与商业价值不相关的功能以及过多的文档。
  • Mura(变异):改善审批和验证流程(比如,安全签批);推动 左移提前 shift-left 策略以推行单元测试、安全漏洞扫描与代码质量检查;并改进风险评定。
  • Muda(浪费):避免技术债、错误或前期的详细文档等浪费。

看起来 80% 的重点都集中在提供一种可以集成和协作的工程产品上,这些系统可以采用一个创意和计划、开发、测试和监控你的解决方案。然而,一个成功的转型和工程系统是由 5% 的产品、15% 的过程和 80% 的开发人员组成的。

我们可以使用的产品有很多。比如,Azure DevOps 为持续集成(CI)、持续交付(CD)和可扩展性提供了丰富支持,并与 Stryker、SonarQube、WhiteSource、Jenkins 和 Octopus 等开源集成和商用成品(COTS)软件即服务(SaaS)进行集成。对于工程师来说,关注产品总是一种诱惑,但请记住,它们只是我们旅程的 5%。

 title=

最大的挑战是打破数十年的规则、规定和已经步入舒适区的流程:“我们一直都是这样做的;为什么需要改变呢?

开发和运维人员之间的摩擦导致了各种支离破碎的、重复的、不间断的集成和交付流水线。开发人员希望能访问所有东西,以便持续迭代,让用户使用起来和持续地快速发布。运维人员希望将所有东西锁起来,保护业务、用户和品质。这些矛盾在不经意间导致了很难做到一种自动化的流程,进而导致发布周期晚于预期。

让我们使用最近的一次白板讨论中的片段来探索流水线。

想要支持流水线的变化是一项困难并且花费巨大的工作;版本和可追溯性的不一致使得这个问题变得更加复杂,因此不断精简开发流程和流水线是一项挑战。

 title=

我主张一些原则使得每个产品都能使用通用流水线:

  • 使一切可自动化的东西都自动化
  • 一次构建
  • 保持持续集成和持续交付
  • 保持持续精简和改进
  • 保持一个构建的定义
  • 保持一个发布流水线的定义
  • 尽早、频繁地扫描漏洞,并且尽快失败
  • 尽早、频繁地进行测试,并且尽快失败
  • 保持已发布版本的可追踪和监控

但是,如果我要打破这些,最重要的原则就是保持简单。如果你不能说明流水线化的原因(是什么、为什么)和过程(如何),你或许是不了解自己的软件过程的。我们大多数人想要的不是最好的、超现代的和具有革命意义的流水线 —— 我们仅仅是需要一个功能强大的、有价值的和能促进工程的流水线。首先需要解决的是那 80% —— 文化、人员和他们的心态。请你的 CI/CD 骑士们穿上闪亮的盔甲,在他们的盾牌上贴上 TLA( 两个/三个字母的缩写 two/three-lettered acronym )符号,加入到实践和经验工程的力量中来。

统一流水线

让我们逐步完成我们的白板会议实践。

 title=

每个应用使用一套构建定义来定义一个 CI/CD 流水线,用来触发拉取请求的预合并验证持续集成的构建。生成一个带有调试信息的发布的构建,并且将其上传到 符号服务器。这使开发人员可以在本地和远程生产环境进行调试,而在不用考虑需要加载哪个构建和符号,符号服务器为我们施展了这样的魔法。

 title=

在构建过程中进行尽可能多的验证(左移提前),这允许开发新特性的团队可以尽快失败,不断的提高整体的产品质量,并在拉取请求中为代码审核人员提供宝贵证据。你喜欢有大量提交的拉取请求吗?还是一个带有少数提交和提供了漏洞检查、测试覆盖率、代码质量检查和 Stryker 突变残余等支持的拉取请求?就我个人而言,我投后者的票。

 title=

不要使用构建转换来生成多个特定环境的构建。通过一个构建实现发布时转换标记化和 XML/JSON 的值替换。换句话说,右移滞后具体环境的配置。

 title=

安全存储发布配置数据,并且根据数据的信任度敏感度,让开发和运维都能使用。使用开源的密钥管理工具、Azure 密钥保险库、AWS 密钥管理服务或者其他产品,记住你的工具箱中有很多方便的工具。

 title=

使用用户组而不是用户,将审批人管理从跨多个流水线的多个阶段移动到简单的组成员。

 title=

创建一条流水线并且对赋予特定的交付阶段的权限,而不是重复流水线让团队进入他们感兴趣的地方。

 title=

最后,但并非最不重要的是,拥抱拉取请求,以帮助提高对代码仓库的洞察力和透明度,增进整体质量、协作,并将预验证构建发布到选定的环境,比如,开发环境。

这是整个白板更正式的视图。

 title=

所以,你对 CI/CD 流水线有什么想法和经验?我的通过一条流水线来管理它们的这个梦想是空想吗?


via: https://opensource.com/article/19/7/cicd-pipeline-rule-them-all

作者:Willy-Peter Schaub 选题:lujun9972 译者:chunibyo-wly 校对:wxy

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