DevOps成功的秘诀是什么，从持续集成和持续部署开始！

Posted 2021-04-16 CloudMSP社区

DevOps成功的秘诀是什么，从持续集成和持续部署开始！

DevOps可能是软件开发中最危险的术语之一，我们大多数人都认为五项活动会使DevOps成为现实：持续集成，持续交付，云基础架构，测试自动化和配置管理。如果你做对了这五件事，你就做成了DevOps。显然，所有这五件都做正确很重要，但很容易出错。特别是持续集成和持续交付（CI/CD）可能是最难掌握的难点。

持续集成（CI）是开发人员和测试人员协作验证新代码的过程。传统上，开发人员每月编写代码并将其集成以进行测试。这是低效的--四周前代码中的错误可能迫使开发人员修改一周前编写的代码。为了克服这个问题，CI依靠自动化来连续集成和测试代码。敏捷团队至少每天使用CI提交代码，而其中大多数都为每次引入的更新提交代码。

持续交付（CD）是不断创建发布的过程。有些公司每天向用户发布一次甚至多次，而其他公司则出于市场原因以较慢的速度发布软件。无论哪种方式，都会持续释放测试能力。由于云环境，可以实现持续部署。配置服务器，以便可以在不关闭和手动更新服务器的情况下部署到生产环境。

因此，CI/CD是一个持续开发，测试和交付新代码的过程。Facebook和Netflix等公司使用CI/CD每周完成10次或更多次发布。其他公司很难达到这个速度，因为他们屈服于接下来要讨论的五个陷阱中的一个或多个。

CI/CD陷阱＃1：错误的自动化流程优先级

这个陷阱倾向于阻止组织从瀑布式开发转向DevOps。新组织具有从头开始实施CI/CD的优势。现有公司必须逐步从手动到高度自动化的发展。完全过渡可能需要几个月，这意味着需要反复采用CI/CD。

当询问“这需要现在自动化吗？”时，请查看以下清单：

1. 流程或方案重复的频率如何？

2. 这个过程有多长？

3. 流程中涉及哪些人员和资源依赖项？ 它们会导致CI/CD延迟吗？

4. 如果它不是自动化的，那么该过程是否容易出错？

5. 使流程自动化的紧迫性是什么？

使用此核对表，可以确定CI/CD实施中的步骤的优先级。首先，是编译代码的过程自动化。理想情况下，将每天多次集成代码。手动，这个过程需要几分钟到几个小时。会停止输出，直到编译器完成任务。也容易受到人为错误的影响，因为没有自动集成的流水线，CI/CD只是一个梦想，所以很迫切。

我们可以在测试时运行相同的清单。当转换到CI/CD时，可能想知道：我们应该首先自动执行功能测试或UI测试吗？两者每天至少重复一次。对于中型应用程序，两者都需要两到三个小时。但它们涉及多个依赖关系。如果自动执行功能测试，则可能不必经常更新自动化脚本。另一方面，UI经常发生变化，因此需要频繁更改脚本。虽然两者都容易出错，但应该在UI测试之前优先考虑功能测试，以便充分利用资源。

让我们再一次在设置环境的过程中这样做。如果正在招聘狂欢或经历大量人才流失，则此方案会频繁重复。这是一个相当耗时的过程，如果不是几天，可能需要几个小时。没有环境，新团队成员无法做任何有用的事情，所以显然存在依赖性和延迟。我不会说这个过程容易出错，所以它仍然是紧急的？我倾向是，但我仍然首先优先考虑集成和功能测试。

没有超自然的东西。如果拥有无限的资源，可以自动化所有可能的资源。也就是说，无法实现全面的测试自动化。有时可以将任务分解为较小的段并自动执行修补程序。有时应该只是详细记录流程并手动执行。

CI/CD陷阱＃2：混淆持续部署和持续交付

持续部署的概念是，如果部署流水线的结果成功，代码库中的每个更新都将立即部署到生产中。这对大多数组织来说都是可怕的，因为快速的产品更改可能会吓跑用户。

公司认为，如果他们不进行持续部署，他们就不会做持续交付。他们无法区分持续部署和持续交付。

持续交付是代码库的每次更改都经过流水线直到部署到非生产环境的概念。该团队立即发现并解决问题，而不是在他们计划发布代码库时。

代码库始终处于可安全发布的质量级别。什么时候将代码库发布到生产是一个商业决策。

虽然持续部署使大多数组织感到不安，但持续交付会使他们产生共鸣。持续交付使他们能够控制产品的推出，功能和风险因素。有时间进行alpha测试，测试用户，早期采用者，等等。

CI/CD陷阱＃3：缺乏有意义的仪表板和指标

在CI/CD实施中，敏捷团队可以在成员知道他们需要跟踪的内容之前创建仪表板。因此，团队成为逻辑谬误的牺牲品：“这些是我们拥有的指标，因此它们必须很重要。”相反，在设计仪表板之前执行渐进式评估。

IT组织的不同成员，甚至是敏捷团队的各个成员，都有不同的优先级。例如，网络运维中心（NOC）的人们喜欢红色，黄色和绿色指示灯。这种交通灯仪表板使NOC工作人员能够在不阅读密集文本或对其分析能力征税的情况下区分问题。交通信号灯有助于使数百台服务器易于管理。

你可能也想使用CI/CD的仪表板。绿色，我们正在走上正轨。黄色，我们偏离轨道，但我们有计划解决这个问题。红色，我们偏离轨道，可能需要改变我们的目标。

该仪表板对于敏捷大师可能很有用，但是开发副总裁还是CTO呢？如果一个敏捷团队提前350个小时的工作进行为期两周的冲刺，并且其10个成员每个负责35个小时，他们将获得相应数量的故事。高层管理人员可能对故事不太感兴趣，对“燃尽”率更加好奇：任务完成的速度。团队成员是否携带他们的负载？太快了？它们会随着时间而改善吗？

不幸的是，如果各利益相关方不了解敏捷团队商定的习惯，那么燃尽率可能会产生误导。有些团队在他们离开时会尽早烧掉积分。其他人等到接近冲刺结束时烧掉开放点。仪表板应考虑到这一点。

如果可以评估每个人想要的数据并为数据的含义建立标准叙述，那么可以设计一个有用的仪表板。但不要以牺牲外表为代价来痴迷于物质。询问利益相关者如何看待它。图表，文字或数字最好吗？

这些是在渐进式评估中进行调查的考虑因素。它们说明制作有用的CI/CD仪表板并让每个人都满意是多么棘手。很多时候，最有声音的团队成员劫持了这个过程，而其他人则对仪表板只满足一个人的偏好感到沮丧。请听取大家的意见。

CI/CD陷阱＃4：持续集成和持续交付之间缺乏协调

这个陷阱让我们回到了我们对DevOps的共识定义，认为持续集成和持续交付是两个不同的项目。CI提供CD。实施体面的持续集成流水线和完整的持续交付系统需要数月时间，需要协作。质量保证，DevOps团队，运维工程师，敏捷大师--所有人都必须做出贡献。也许CI/CD最棘手的方面是人为因素，而不是我们讨论过的任何技术挑战。正如无法在两个人之间建立健康的关系一样，无法实现协作和沟通的自动化。

要衡量这种协调水平，请将CI/CD流程与业务中的最佳流程进行对比。像Netflix这样的公司可以在两到三个小时内完成集成，测试和交付。他们建立了一个系统，可以在不进行犹豫不决和讨论的情况下手动传递代码。不，它不是100％自动化，因为使用当前技术是不可能的。

CI/CD陷阱＃5：平衡运行持续集成作业的频率和资源利用率

应该为代码中引入的每个更改触发持续集成作业。成功的工作允许更新通过，而拒绝故障更新。这鼓励开发人员检查较小的代码块，在一天内触发更多的构建。但是，不必要的持续集成工作会消耗资源，从而浪费时间和金钱。

由于此过程涉及大量资源利用（CPU，功率，时间），因此应将软件分解为更小的组件以创建运行速度更快的流水线。或者，连续集成作业应设计为首次在本地测试的批量签入。目标是在执行持续集成作业的频率和资源利用之间找到平衡点。

保持目标在前方

当我们深入研究CI/CD的缺陷时，所有的深奥术语都很容易忽视为什么这很重要。最终，CI/CD是必不可少的，因为它符合业务目标。

技术主管知道，持续发展，快速修复和质量结果可以创造和留住客户。他们知道，如果用一个失败的版本邀请大家对App Store的评论，重新获得高评价比保留它们更难。DevOps可能会为你的团队创造更好的工作体验，但这并不是公司实施DevOps的原因。

简而言之，CI/CD的缺陷值得复盘，因为数十亿美元处于危险之中。虽然我不建议你在CI/CD仪表板中添加行情自动收录机或App Store评论跟踪器，但我建议你继续认识到这一点。很大程度上取决于CI/CD的细节。

原文链接：

https://www.infoworld.com/article/3113680/devops/5-common-pitfalls-of-cicd-and-how-to-avoid-them.html?nsdr=true

推荐阅读：

（加管理员微信入群一起交流云管理：cloudmspcn）