蚊章汇 - DevOps
type: channel
link: https://linuxcn.bwsl.wang/tag/DevOps/
items: DevOps 文档成熟度的四个层次
items: 构建高效的 DevOps 文化的 6 个技巧
items: 文档写作的 DevOps 指南
items: 开源 DevOps 工具的平台化未来
items: DevOps 将去向何方？
items: 2021 总结：DevOps 促进转型的 13 个例子
items: 使用 Powershell 来自动化 Linux、macOS 以及 Windows 流程
items: 如何实现 DevOps 工具链
items: 《代码英雄》第一季（4）：DevOps，拆掉那堵墙
items: DevOps 和敏捷：究竟有什么区别？

DevOps 文档成熟度的四个层次
type: item
date: 2023-09-16T22:00:09+08:00
description: 提升 DevOps 文档成熟度的过程与达到 DevOps 或 DevSecOps 成熟化的历程是类似的。为了能在软件迭代交付周期内按时交付优质的文档，DevOps 和 DevSecOps 的文档实践也需要是敏捷的。这与实现 DevOps 类似，只是更偏向自动化和敏捷的内容处理方法。如果文档现在才进入你的机构的 DevOps 讨论，那么是时候让文档实践追上 DevOps 的步伐了。下面是 DevOps 文档成熟度的四个层次：第一层：临时且孤立在最低一级成熟度（最不成熟），文档编制工作没有和 DevOps 开发对齐。开发团队和文档团队按照各自的路线开展工作，常常导致文档落后于开发。在竞争激烈的“云”世界里，因为文档问题而推迟产品发布是不可接受的。人员这个阶段的文档编制人员还没有摆脱传统的工作方式。 技术写作 technical writer 人员隶属于一个中心化的单独团队，与开发团队是脱节的。技术写作组和开发团队之间的鸿可能是由多方面原因造成的：造成团队分裂和孤立的公司政治团队只是将技术文档视为项目验收清单上的检查项，而不是推动项目成功的资产事后才雇佣技术写作人员技术写作的优先级与开发团队的实际情况不匹配这个阶段，另一个在人员配置上的挑战是如何“界定工作完成”。刚接触敏捷实践的技术写作可能难以适应 CI/CD 工具链和流程。文档工具和流程这个阶段的技术写作仍习惯于使用传统的办公工具，比如办公套件和布局程序。这些工具不够敏捷，没有版本控制和内容管理的要求。它们无法与 DevOps 工具链高效集成，不能支撑快速开发。在这个成熟度，技术写作仍然参照遗留的模板和流程。成果这个级别交付的文档可能是过时的，甚至缺乏技术准确性的。如果开发团队以 DevOps 的速度推进工作，而技术文档编制却遵循传统的非敏捷流程（使用专有的工具和交付格式），这就很难让文档迭代速度并跟上应用程序的变化。第二层：实验和试点DevOps 文档成熟度的第二层是实验/试验阶段。这个阶段是 DevOps 团队主管和技术写作采取行动打造更敏捷的文档实践和工具的第一步。理想的情况下，这些实验是 相关方 stakeholder 支持的试点项目的一部分。他们能够从文档交付流程的改善以及其与 DevOps 实践的集成中获益。人员本阶段的人员可能来自以下三种形式：有远见的技术写作为了更好地完成工作，用自己的时间来实验更敏捷的工具。并且向领导层提出更敏捷的文档编制过程的想法。DevOps 负责人或工程师试用 Hugo 和 Jekyll 等工具，并将这些工具集成到 CI/CD 流水线中。然后 DevOps 小组教授技术写作如何使用它们。团队引入了第三方承包商或顾问，他们在 DevOps 文档工具方面具有专业知识，并且了解文档工具适合嵌入到 CI/CD 工具链和 DevOps 生命周期的位置。文档工具和实践Hugo 和 Jekyll 是本阶段开始出现的工具。在这个阶段也出现新的内容策略和技术写作方法。成果实验试点阶段理想的成果应该能够“ 落地并推广 land and expand ”。也就是说其它项目组也可以将其付诸实践。这个阶段的实验也包括内容策略和发布流程上的根本性变化。其它非试点项目组的技术写作可以学习和使用它们。试点带来的另一个可能的产出是 技术写作招聘流程 的变化。你需要针对 DevOps 和你新引入的文档工具对内部编写人员进行培训。新的文档工具和流程是此阶段的关键成果，你需要通过演示、状态报告和内部案例研究等方式，将这一成果推给领导层、相关方和其它团队。第三层：部分自动化和扩展DevOps 文档成熟度的第三层（部分自动化和扩展）就是“落地并推广”的进一步行动。在这个阶段，其它 DevOps 团队借用试点项目中产生的 DevOps 文档工具和流程，吸取其中的经验教训。人员在这个成熟度，技术写作和 DevOps 团队开始更紧密的协作。招聘新的技术写作主要关注具有 DevOps 环境经验的人选。工具和文档实践技术写作开始从抛弃传统的工具和流程，转到更敏捷的文档工具上，比如：docToolchainDocbookHugoJekyll在这个成熟度，技术写作也负责调整遗留的文档实践。成果DevOps 文档工具和实践超越试点项目，成为标准实践。在这个成熟度，随着新团队使用新的文档工具和流程，持续学习是必不可少的。第四层：完全采用在最高一级的 DevOps 文档成熟度（完全采用且自动化）所有工具、实践和流程已经到位，以支持将文档为项目中的高优先级事项。要达到这一成熟度，需要不断实验、迭代和团队协作。人员完全自动化使 DevOps 团队与技术写作之间的协作更紧密。这一阶段的标志是，技术写作牢牢地融入到项目团队的工作流程中。文档工具的维护工作由一些大型企业负责，它们拥有专职维护 DevOps 工具链…

构建高效的 DevOps 文化的 6 个技巧
type: item
date: 2023-01-20T07:58:37+08:00
description: 无论你是刚刚开始在你的组织中使用 DevOps，还是仅仅想改善你现有的文化，请考虑这些技巧以及它们与你组织的未来的关系。你为什么要构建 DevOps 文化？开发团队和运维团队的精简协作有很多好处。效率是首要目标：提高新软件部署的速度，减少等待的时间。培养同事之间的信任可以提升员工的满意度，激发新的创新，并对盈利能力产生积极的影响。DevOps 是一个很广泛的思想，大家的理解也见仁见智。每个公司对于如何实行 DevOps 也各不相同。这种意见的多样性实际上是一件好事 —— 这么多的观点对于建立更强大的团队是很有用的。本指南将探讨在 DevOps 文化中鼓励同事之间更好地合作的最高技巧。下面每个部分从不同的视角介绍 DevOps 文化，并探讨了将它引入员工队伍的方法。流程的持续发展DevOps 文化的这一核心原则使它与许多其他类型的工作场所的风气区别开来。DevOps 哲学说，犯错是有积极意义的，因为这表明你在尝试新的想法。DevOps 文化的核心是不停地创造。实际上，这意味着当测试结果显示事情由于你的改动而变坏时，不要懊恼。我们要认识到，进化的过程不是线性的，通往成功的道路也从来不是一条直线。DevOps 专家 Gene Kim 主张勇于承担风险和进行实验。鼓励你的团队尝试不寻常的任务，以得到新的领悟。你的组织应该以利润为导向吗？你能允许你的团队尝试一些新东西（非指个人兴趣项目）吗？持续的流程发展意味着对升级目前的方法持开放态度。优秀的销售领导懂得，结果比出勤率更重要，因此，关注团队的工作方式而不是工作量的多少始终是关键。随时提供反馈并积极寻求反馈成员之间增加信任是蓬勃发展的 DevOps 文化的另一个关键特征。无论你的员工是在学习如何建立联盟网络联系，还是试图设计他们的下一个 用户体验 调查，每个人都应该对他们工作的反馈持开放态度。但是，除非你的团队成员尊重彼此的意见，并相信反馈是本着善意的精神提出的，否则这永远不会发生。这种文化听起来可能是很难培养的；事实上，一些公司会比其他公司更努力地实现这一点。诚然，给予和接受反馈的成功很大程度上取决于员工的个性。在招聘过程中，也可以对此进行筛选。在你期望员工随时向同事提供反馈并主动寻求反馈之前，你应该以身作则。高管应该以身作则，公开要求公司成员对其战略决策提出探究性问题，并提供相应的反馈。不断改进在同事之间增加对智力信任的基础上，你的团队应该寻找方法来改善其工作。DevOps 的性质意味着软件开发团队将比传统方法更迅速地进行部署。这种开放的改进文化可以对开发和运维以外的部门产生积极的影响。你也可以自己去探索企业还有哪些领域会受到积极的影响。留意培训和提高技能的机会。即使一个培训课程没有广告上说的那么突出，但有机会与行业专家建立联系，并与未来建立联系，这可以提高你的组织内的思想多样性。为以后的开发保存当前的想法频繁使用的 Git 账户应该是你的 DevOps 工具链的一部分。你可以用 Git 作为软件开发和其他相关项目中产生的脚本的共同仓库。Git 作为 “版本控制” 工具而被熟知，Git 允许程序员保存他们工作的迭代、复用或改进其他人的工作。你的目标是能够保留好的想法以供将来使用。某个方法由于某种原因没有成功。然而，那套想法在当时是错误的，并不意味着它在未来永远无法成为有用的东西。由于 DevOps 的整个重点在于生产环境中的软件的端到端所有权，因此节省开发的迭代真正支持这一原则。你希望看到对手头的软件测试项目的持续关注和投入。一个简单的方法是要求开发者在开发者合同和最终项目报告中包含对未来工作的想法。确保技术服务经理知道他们应该要求提供在建设过程中出现的旁门左道的想法的例子。意识到这些小创新的人越多，在需要的时候就越有可能有人记住一个。坐在一起（物理上或逻辑上）目标是对彼此的工作角色以及它们之间的相互关系有一个共同的理解。你可以通过几个简单的方法实现这一目标，用一句话概括：坐在一起。邀请其他团队参加你们的会议，完整地分享用户反馈报告。一起吃午饭，一起计划虚拟的快乐时光，一般来说，要确保你的同事都在一起。大约 90% 的拥有成熟的 DevOps 协议的团队报告说，他们清楚地了解自己对其他团队的责任，而在不成熟的 DevOps 团队中，只有大约 46% 的工作者清楚地了解自己的责任。虽然与志同道合的人结成小团体，只与被雇来执行与你相同任务的员工在一起是很诱人的，但这对整个企业来说是很糟糕的。无论你喜欢与否，所有的人都是多面手，能够在一系列的情况下贡献自己的独特才能。密切协作的理念是尊重任何人对其周围正在进行的产品或工作流程提出改进建议的能力。如果你与公司内的其他部门保持一定的距离，你将会错过无数次分享智慧想法的机会。毕竟，你往往在交流中学习得最好。致力于自动化你应该以提高效率和加速流程的…

文档写作的 DevOps 指南
type: item
date: 2022-12-15T18:15:40+08:00
description: 将文档写作加入到 DevOps 的生命周期中。DevOps 正在挑战技术文档的规范，这在 IT 历史上是前所未有的。从自动化到提高交付速度，再到拆除瀑布式软件开发生命周期模型，这意味着业务和技术文档写作的理念需要做出巨大改变。以下是 DevOps 对技术文档写作不同方面的影响。技术写手的角色变化技术写手必须适应 DevOps。好消息是，许多技术写手已经加入到开发团队中，并且拥有合作关系和不断增长的产品知识的技术写手很具优势。但是如果一个技术写手习惯于独立工作，并依赖于领域专家的草稿作为文档的基础，那么就需要做一些调整。进行一些投资，以确保文档和其他与项目有关的内容开发工作获得所需的工具、结构和支持。从改变 技术写手聘用方式 开始。以 DevOps 的速度 编写文档需要重新思考内容规划，并打破 DevOps 团队和支持项目的技术写手之间长期存在的隔阂。DevOps 使开发团队摆脱了传统文档实践的束缚。首先，文档 完成的定义 必须改变。一些企业的文化使技术写手成为软件开发的被动参与者。DevOps 提出了新的要求：随着 DevOps 文化的转变，技术写手的角色也应发生变化。技术写手需要（且必须适应）DevOps 提供的透明度。他们必须融入 DevOps 团队。取决于组织如何塑造这个角色，将技术写手带入团队可能会带来技能上的挑战。文档标准、方法和规格虽然 DevOps 还没有影响到技术文档本身，但开源社区已经加强了对应用编程接口（API）文档的帮助，已经有不同规模的企业的 DevOps 团队正在使用这些文档。用于记录 API 的开源规范和工具是个非常值得关注的领域。我想这是由于 谷歌文档季 的影响，它使开源软件项目能够获得专业的技术写作人才来解决他们最关键的文档项目。开源 API 属于 DevOps 文档讨论的一部分。云原生应用集成需求的重要性正在上升。OpenAPI 规范（一个定义和记录 API 的开放标准）是在 DevOps 环境下 API 文档的良好资源。然而，该规范会导致文档的创建和更新过程变得很费时，这使其饱受批评。曾经也有短暂尝试过创建 持续文档 Continuous Documentation ，并且还有一个来自 CA（现在的 Broadcom）的创建 DocOps 框架的运动。然而，DocOps 从来没有作为一个行业运动流行起来。DevOps 文档标准的现状意味着 DevOps 团队（包括技术写手）需要在项目的最初阶段就开始创建文档。要做到这一点，你需要把文档作为一个敏捷故事和（同样重要的）管理期望，并且把它与年度绩效评估放在一起执行。文档工具文档的编写应该以一种所有团队成员都可以使用的格式或平台在线进行。MediaWiki、DokuWiki、TikiWiki 和其他 开源维基 为 DevOps 团队提供了一个编写和维护文档的中央仓库。让团队选择他们的维基平台，就像让他们选择他们的其他持续集成/持续开发（CI/CD）工具链一样。开源维基强大之处在于其可扩展性。例如，DokuWiki 包括一系列的扩展，你可以通过安装这些扩展来创建一个符合你的 DevOps 团队的创作要求的平台。如果你有足够的野心来加强你的团队的编写和协作能力，Nextcloud（一个开源的云协作套件）是一个让你的 DevOps 团队上网并给他们提供编写文档所需工具的选择。DevOps 最佳实践文档在 DevOps 转型中也发挥着作用。例如，你会想要记录组织从 DevOps 实现效率和流程增益的最佳实践，这些信息太重要了，不能靠着 DevOps 团中之间口耳相传。如果你所在的组织有多个 DevOps 团队，那么文档就是统一的力量，它可以促进最佳实践的标准化，并设置了衡量代码质量的基准指标。一般情况下，开发人员承担了记录 DevOps 实践的工作。即使他们的组织有技术写手，他们也可能跨开发团队工作。因此，开发人员和系统管理员能够捕捉、记录和交流他们的最佳实践是很重要的。这里有一些朝正确的方向发展的提示：提前花时间为 DevOps 最佳实践创建标准模板。不要陷入复制在线模板的陷阱。采访利益相关者和团队来创建一个符合团队需求的模板。寻找一些创造性的信息收集的方法，例如记录团队会议和使用聊天系统日志来作为文档的基础。建立一个用于发布最佳实践的维基。使用维基可以跟踪编辑和更新。这样的平台可以帮助团队在最佳实践发生变化时进行更新和维护。当在构建 CI/CD 工具链时记录依赖关系是非常明智的。尤其是当加入新的团队成员时，你会发现这些记录非常有用，另外当团队成员忘记一些事情时，这也是一种保险。最后，自动化对 DevOps 利益相关者和从业者都很有吸引力。在自动化中断之前，一切都很有趣。拥有自动化运行手册、管理指南和其他内容的文档（并且是最新的）意味着无论何时发生故障，…

开源 DevOps 工具的平台化未来
type: item
date: 2022-10-24T17:27:50+08:00
description: 当商业 DevOps 工具市场着眼于平台时，是时候让开源 DevOps 工具重新定义它们的未来了。DevOps 的开源根基是无法动摇的，即便有预言称全球的 DevOps 市场将在 2026 年之前达到 178 亿美元。不断变化的工作环境、安全和合规性问题，以及风险投资公司等等因素正在将市场推向 DevOps 平台，开发团队可以在云中获得完整的端到端 DevOps 工具链。开源 DevOps 工具现状我们要搞清楚一件事：开源工具不可能从 DevOps 世界中消失。现在，在开源和供应商提供的 DevOps 工具之间存在着一种平衡，开发人员会在两者间选择适合他们的工具。事实上，很多情况下，一个开发团队起初会为他们的 DevOps 流水线选择一个开源工具，后来又升级到商业版本。三种开源 DevOps 工具实例下面我们介绍一些开源 DevOps 工具的例子，每种工具都已经有了围绕其建立的商业化生态。Git源代码管理工具 Git 作为源代码库，可能是 DevOps 工具链的主要基础之一。Git 的两个最佳商业案例是 GitLab 和 GitHub。GitLab 接受开发者对其贡献开源项目。GitHub 也在着手努力成为一个 DevOps 平台，推出了人工智能版的结对编程 GitHub Copilot，在推出后受到了一些开源团体的褒贬不一的评价。Jenkins作为一个开源的自动化服务，Jenkins 因其易于安装、配置和可扩展性而受到推崇。CloudBees 提供了 JenkinsX，JenkinsX 是一套开源的解决方案，可以为 Kubernetes 上的云原生应用提供自动化持续集成和持续交付（CI/CD）以及自动化测试工具。他们还为JenkinsX 提供商业支持，包括：访问 CloudBees 的专业技术技能24x7 技术支持访问 CloudBees 的文档和在线知识库Kubernetes随着越来越多的组织寻求企业级的容器编排解决方案，Kubernetes 的发展成为必然。尽管有人批评其复杂性。自然而然的，Kubernetes 周边有完整的、蓬勃发展的产业。根据 Allied 市场调研的数据，全球容器和 Kubernetes 安全 市场在 2020 年的估值为 7.14 亿美元，预计到 2030 年将达到 8.42 亿美元。目前的 DevOps 工具链各个行业仍有很多 自建 build-your-own （BYO）的 CI/CD 工具链在发挥作用。支持 DevOps 功能的开源项目仍在蓬勃发展。BYO 工具链可以集成其他工具，而且非常具有扩展性，这对于持续迭代其 DevOps 实践的组织来说一直是一个优势。在出于业务、IT 和安全原因寻求标准化的企业中，缺乏标准的材料清单可能是个麻烦。虽然 DevOps 平台的出现并没有被忽视，但许多组织早在大流行之前就将他们的 CI/CD 工具链迁移到了公有云。长期以来，工具链本身的安全性一直是一个不断上升的问题，而公有云基础设施提供了身份访问管理（IAM）和其他安全功能来控制访问。DevOps 平台是敌是友？DevOps 平台是一个端到端的解决方案，它将 CI/CD 工具链的所有功能放入云中。DevOps 平台的例子包括 GitLab 和 Harness。GitHub 也在采取行动，使自己成为一个 DevOps 平台。优势（即便只从企业买家角度考虑）DevOps 平台对那些已经适应了 SaaS 和云计算行业的基于消费和订阅的定价的企业买家很有吸引力。在这个远程和混合工作的世界里，对可维护性、安全、合规性和开发人员的生产力的担忧肯定是技术领导者的首要考虑。对这些人来说，在 DevOps 平台上实现标准化是很有吸引力的。劣势在依赖供应商提供的 DevOps 工具链时，人们会想到对供应商锁定功能的古老担忧。开发团队构建和维护其工具链的可扩展性不会像他们从头开始制作工具链时那样，更不用说引入新的工具来改善他们的工作流程了。DevOps 平台供应商也有潜在的经济方面的劣势。想一想，一个被高估的 DevOps 工具初创公司如果没有达到其投资者的高额财务目标，可能会发生什么。同样，也可能有一些较小的初创供应商得不到下一轮的资金，而慢慢消失。虽然 DevOps 平台的出现在很多方面都是有意义的，但它确实违背了促成我们今天使用的 DevOps 工具的开源精神。DevOps 工具：一个拐点随着工作模式的改变，人们对 DevOps 工具链的安全和合规性的关注必然会增加。正在变化的工作环境我们的工作方式与企业其他部门一样影响着 DevOps 团队。远程和混合 DevOps 团队需要安全的工具链。整个流水线中不断变化的协作和报告要求，如异步工作和经理要求返回办公室等，也是日益增长的必要条件。软件供应链安全市场在高调的攻击和美…

DevOps 将去向何方？
type: item
date: 2022-10-08T23:09:43+08:00
description: 微软、谷歌、亚马逊、IBM 和甲骨文如今都在关注云上的 DevOps。这些大公司正在给企业提供 IT 自动化的服务。然而，DevOps 仍然在持续的演进中。DevSecOps、AIOps 和 NoOps 正在成为下一个流行词。随着开发和管理人员看到及时交付高质量软件的商业价值， 敏捷 Agile 方法论和 DevOps 也变得流行起来。拥有灵活的发布周期，并且交付具有 可扩展 scalable 和 可定制 customizable 的软件，是世界上每个企业的目标。通过将 CI/CD 工具和 管道 pipeline 部署到云端，DevOps 使发布过程变得更加流畅。融合了 DevOps 的 Polyglot 微服务架构正在帮助企业降低总拥有成本（TCO）。他们现在有能力用渐进式网络应用程序和最新的 UI 框架升级他们的技术栈。总的来说，团队正在以更好的效率执行任务，并且正在开发高质量的软件模块。自治 DevOps容器和 DevOps 与云原生应用走到了一起。Kubernetes 和 Docker 正在被用作容器，一个新的名词 NoOps 现在正在流行。对于不同的容器， 编排 Orchestration 都是一个重要的功能。为了扩展应用，开发环境中要创建容器集群。有一些新的容器正在进入云原生应用这个领域，比如 Mesos、Swarm、Openshift Rancher 和 Nomad。NoOps 有助于缩短编码周期，从而监控和管理应用程序。缺陷修复和热修复是不同的活动，它们都是 NoOps 的一部分。NoOps 有助于提高技术团队和业务运营人员之间的协同作用。它也有助于更好的监控、管理和流程自动化。NoOps 基础设施能够控制应用程序在云上的部署。企业从中获得的好处包括更好的交付、弹性的服务、更快的发布、良好的质量和 CI/CD 自动化。DevSecOpsDevSecOps 算是另一个流行趋势，它与在开发操作中的安全问题有关。最近与 漏洞 vulnerabilities （log4j）， 安全泄露 security breach （谷歌、脸书、微软），和安全攻击相关的问题增加了 DevSecOps 在企业中的重要性。 左移 shift left 方法强调了在软件生命周期的早期处理安全性和质量的重要性。在架构阶段就需要考虑隐私和 遵从性 compliances （如 GDPR）。这有助于降低成本，并且提升软件交付的速度。审计工具和安全检查列表是 DevOps 工具和系统的一部分，现在我们称为 DevSecOps。AIOpsAI DevOps 现在被称为 AIOps。据预测，将来 AI 应用会由 AIOps 来管理。与 AIOps 相关的工具和软件正在开发中，并且将很快发布首个版本。AI/ML 应用部署和模型更新可以由 AIOps 来处理。这将在 工业 4.0 Industry 4.0 以及数据科学中扮演重要角色。有一种观点认为，NoOps 将会是 AIOps 的最终形态。AIOps 包括数据集管理、模型训练、模型服务、元数据管理、模型更新和服务更新。分布式训练将由 AIOps 来完成，这会提供 超参数 hyper parameter 优化，工作流程管理和“ 假设 what if ”的分析能力。微服务配置管理当前，DevOps 和微服务正在成为标准部署和 架构蓝图 architectural blueprints 来实施。应用可以在模块级别上就进行扩展。微服务可以在简化缺陷修复和问题区域隔离上提供帮助。经过设计，微服务可以通过添加更多 计算能力 computing power 的 实例 instances 来进行扩展。但是当它们没有被正确实现的时候，数据安全和管理的问题就会突然出现。平台即产品云上的 软件即服务 Software as a Service 和 平台即产品 Platform as a Product 最近非常流行。通过加速向平台部署和功能交付，DevOps 使这些变成现实。从编码到上线阶段，CI/CD 管道有助于可视化应用的部署。持续交付、集成和部署都是 DevOps 的一部分。DevOps 生产线模拟工业生产线是未来要关注的。DevOps 正在慢慢地向 DevSecOps 和 AIOps 转变。对于企业，NoOps 才是未来。现在需要的是减少与安全相关的攻击、事故和破坏发生。对于企业来说，数据安全和隐私的优先级更高，并且这些新技术都将在这方面有所帮助。via: https://www.opensourceforu.com/2022/09/where-is-devops-headed/作者：Bhagvan Kommadi 选题：lkxed 译者：Yufei-Yan 校对：wxy本文由 LCTT 原创编译，Linux中国 …

2021 总结：DevOps 促进转型的 13 个例子
type: item
date: 2022-03-03T19:24:34+08:00
description: 2021 年，我们的顶级 DevOps 文章聚焦于工具、最佳实践和最关键的部分：转型。2021 年对于 DevOps 来说是激动人心的一年，开发团队不断适应远程和混合工作模式。这一年最受欢迎的 DevOps 文章展示了我们的社区如何关注工具、创新、最佳实践和转型。DevOps 工具和创新该行业的工具仍然是读者的首选读物。Nimisha Mukherjee 是红帽的一名工程经理，她编写了 面向开发人员的 13 个开源工具。她将工具分为“内环”和“外环”两个部分，“内环”是开发人员最常见的任务，“外环”是开发人员的代码通过持续集成和交付（CI/CD）部署到生产环境的地方。我们的读者对实现 DevOps 工具链的兴趣也很高。首次投稿的 Tereza Denkova 是一家 IT 专业服务公司 Accedia 的营销助理，他撰写了 如何实现 DevOps 工具链，并将其与创新紧密联系在一起。DevOps 实践Daniel Oh 是我们的主要支持者，也是一位多产的内容创作者，他写了 2021 年需要关注的 3 个无服务器策略，概述了当今无服务器应用程序开发和部署方法是如何加速采用 DevApps 实践的。Evan “Hippy” Satis 在他的文章 解决 CI/CD 中的存储库阻抗不匹配 中提供了调整部署映像和描述符的策略。他是红帽公司的高级顾问，他在文章中采用的有条不紊的方法证明了他的行业经验。另外，请参阅他的文章 在 shell 中处理模块化和动态配置文件。在我的文章 DevOps 文档指南 中，我提出了让文档成为 DevOps 讨论的一部分的理由。我从读者那里得到了一些有见地的评论，因此我正在为未来的一篇文章跟进这些评论。DevOps 转型我们有时不相信 DevOps 能够适应组织需求。理解其他形式的运维的潜在影响是非常必要的，这些运维可能在现在或将来补充或增强 DevOps。Bryant Son，一个自称是 章鱼猫 Octocat 的人，在 GitOps 和 DevOps 有何不同？ 中提出 GitOps 是 DevOps 的进化形式。Mike Calizo 是新西兰奥克兰的一位红帽公司解决方案架构师，他撰写了 如何成功采用 DevSecOps。本文将介绍他作为解决方案架构师的经验。他解释了在你迁移到 DevSecOps 的过程中可能会遇到的一些安全挑战。我写了一系列关于 DevOps 到 DevSecOps 转型的文章。它们是：启动从 DevOps 到 DevSecOps 的转型开始 DevSecOps 转型的 3 个阶段遵循 DevSecOps 成熟度模型DevSecOps 转型的另外 3 个阶段使 DevSecOps 的采用成为团队努力的 4 个步骤2022 年和 DevOps 的未来看到 DevOps 的文章登上了 2021 年最受欢迎的名单，说明 DevOps 将迎来一个更加有趣的 2022 年，因为组织正在继续掌握他们的工具，改进他们的战略，并继续他们的 数字化转型，以便在不断变化的市场中有效地竞争。感谢所有阅读我们的 DevOps 文章、喜欢这些文章，并通过网站和社交媒体给我们发送评论的人。via: https://opensource.com/article/22/1/devops-transformation作者：Will Kelly 选题：lujun9972 译者：CN-QUAN 校对：wxy本文由 LCTT 原创编译，Linux中国 荣誉推出

使用 Powershell 来自动化 Linux、macOS 以及 Windows 流程
type: item
date: 2021-11-23T20:30:08+08:00
description: 自动化是 DevOps 的关键，但是，是否任何事都可以自动化？自动化控制了那些手工的、费力的和容易出错的过程，用运行自动化脚本的计算机代替了执行手工任务的工程师。每个人都认同手工流程是健康的 DevOps 模式的敌人。一些人认为自动化不是一件好事，因为它取代了辛勤工作的工程师，而另一些人则意识到它提高了一致性、可靠性和效率，节省了时间，（最重要的是）使工程师能够聪明地工作。“DevOps 并不只是自动化或者基础架构即代码。” — Donovan Brown自从上个世纪 80 年代早期开始使用自动化流程和工具链以来，每当我听到或读到“自动化一切”的建议时，我总是会激动不已。虽然在技术上可以实现一切自动化，但自动化是复杂的，并且需要付出开发、调试和维护方面的代价。如果你曾经重新启用一个许久不用的 Azure 资源管理器（ARM）模板或很久以前编写的宝贵维护脚本，并期望它在几个月或几年之后仍然能够完美地执行，那么你就会明白，自动化就像任何其他代码一样，是脆弱的，需要持续的维护和培养。所以，你应该对什么进行自动化并在何时进行自动化？当你手动执行自动化流程超过一两次当你需要经常地持续地执行自动化流程自动化任何可被自动化的更重要的是，什么是你不应该自动化的？不要自动化一次性的流程，因为不值得投入，除非你会重新使用它作为参考文档，并定期验证它的可用性不要自动化高度不稳定的流程，因为太复杂且昂贵不要自动化有问题的流程，在自动化前先修复它们举例来说，我的团队使用我们通用的协作和工程系统来不断的监控数百个用户活动。如果一个用户在三个月或者更长时间处于非活动状态，并且这个用户被分配了一个昂贵的许可证，我们就会重分配这个用户一个功能少一些但是免费的许可证。如图 1 所示，这是一个没有技术挑战性的流程。这是一个令人费解且容易出错的过程，尤其是在执行上下文时与其他开发和运维任务切换时。图 1 手工流程切换用户许可证顺带的，这里有一个用简单三步创建的价值流图的例子:可视化所有活动: 列出用户、过滤用户、重置许可证。确定利益相关者，即运营和授权团队。措施：* 总交货时间（TLT）= 13 小时 * 总周期时间（TCT） = 1.5 小时 * 总效率百分比 = TLT/TCT*100 = 11.5% 如果你在人群流量大和容易看到的区域挂一个这些可视化的副本，比如在你的团队的讨论区、餐厅，或在去洗手间的路上，你将引发大量的讨论和主动反馈。例如，从视觉上看，很明显，手工任务是一种浪费，主要是由于漫长的流程等待时间造成的。让我们研究一个简单的 PowerShell 脚本，它可以自动化该流程，如图 2 所示，将总交付时间从 13 小时减少到 4 小时加 60 秒，并将总体效率从 11.5 提高到 12.75%。图 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/userentit…

如何实现 DevOps 工具链
type: item
date: 2021-01-29T23:39:46+08:00
description: 一套完整启用的 DevOps 工具链可推动你的创新计划，实现快速部署并节约成本。不同规模和不同行业组织都致力于为提高软件交付的速度和质量提供解决方案。这不仅保证了他们的生存，还令他们在全球市场取得了成功。DevOps 可以帮助他们规划出一条最佳路线。DevOps 是一个系统，通过引入不同的工具链连接不同工作流程，以便及时交付项目并降低所需的开销。在我工作的 IT 服务公司 Accedia，我们会帮助客户落地一套完整的 DevOps 工具链，这套工具链能帮助他们达到甚至超越他们的业务目标。在这篇文章，我会分享目前为止从 DevOps 项目中汲取的经验。DevOps 工具链是什么？一套完善的 DevOps 工具链可以在不同阶段中使用不同的 DevOps 工具来解决特定的业务带来的挑战。一条工具链能保证前端和后端开发者、质量测试人员、客户都能够从中获得收益。构建工具链的目的是为了自动化开发和部署过程，以确保快速、可靠、预算友好地交付与创新。我们发现成功构建一套 DevOps 工具链不是一个简单的事情。它需要实验和不断的完善，保证必要的流程是完全自动化的。为什么你需要 DevOps 工具链DevOps 工具链自动化了工作流中的所有技术元素。它能让不同团队在一个平台上进行工作，因此可以使你专注于业务战略以推动组织走向未来。我们总结了五个实现 DevOps 工具链所带来的好处。你可以让管理层相信，是值得为 DevOps 工具链的开发投入资源和时间的。更快、更高效的生产部署：DevOps 工具自动化了大部分软件开发进程。这会使产品开发专注于创新，交付更加敏捷，更领先于竞争对手。预算和时间优化：将手动的任务转变为自动化会使你的组织节省时间和资源。当没有人为的错误和时间管理不足带来的额外支出，预算自然会得到优化。高效的开发：DevOps 工具链会减少开发工作中不必要的延时，提高开发效率。前端、后端、质量测试人员的工作是一致的，所以没有人需要协调不同团队之间人员的交付。更快的部署意味着更高的质量：DevOps 工具链保证了缺陷能够很快被解决，并且迅速完成高质量的部署进程。怎么样？它可以生成有针对性的告警，并将重要的事件通知给你的团队。这会让你主动地发现并解决潜在的问题，从而规避故障的不断的升级从而导致的客户服务不可用。及时事件管理：DevOps 工具链有助于优化事件管理记录。它能够识别 IT 事件并且逐渐升级事件级别，通知给指定团队的成员，直到问题被解决。这意味着消息的接受和处理会更加的迅速，因为它们发送给了正确的目标。DevOps 工具链的实践对我的团队来说，DevOps 并不新鲜。我们已经敏捷开发很长时间了，并且我们总是热衷于探索最优的工作流。在我们的实践中，往往都是应用复杂性增加从而带来了自动化的需求。这是我们为一个客户配置的工具链。这个项目包含了移动运营方案，连接了金融交易的所有参与者 （卖方、买方、银行）。这个客户需要动态响应用户反馈并且将故障时间缩短到最小，从而来提高用户体验。我的团队设计了一套工具链用于自动化应用的维护和部署新功能。(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，拆掉那堵墙
type: item
date: 2020-08-19T02:23:13+08:00
description: 代码英雄讲述了开发人员、程序员、黑客、极客和开源反叛者如何彻底改变技术前景的真实史诗。什么是《代码英雄》 代码英雄 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： 归根结底，这是一个心态问题。这种开发者和…

DevOps 和敏捷：究竟有什么区别？
type: item
date: 2020-03-24T04:06:40+08:00
description: 两者之间的区别在于开发完毕之后发生的事情。早期，软件开发并没有特定的管理流程。随后出现了 瀑布开发流程 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 教练、产品经理和开发人员组成，该团队以跨职能、自主的工作方式运作，能够加快软件交付速度从而给客户带来巨大的商业价值。其关注点是较小增量的快速迭代。看板 是一个敏捷框架，有时也叫工作流管理系统，它能帮助团队可视化他们的工作从而最大化效率（因而变得敏捷）。看板通常由数字或物理展示板来呈现。团队的工作在展示板上随着进度而移动，例如从未启…