企业devops持续集成_如何修复损坏的企业DevOps

企业devops持续集成

I love rock climbing. I’ve been climbing since 2002, and over the years, climbing has turned into a family activity. One of the things that I love most about climbing is that it’s all about solving hard problems. Climbing is about getting to the top of the wall without falling. The type of climbing that I do, known as bouldering, is about climbing without a rope, which adds to the challenge. When I work on a bouldering problem, depending on the level of difficulty, it can result in multiple falls off the wall. As frustrating as the falls can be, each time I get back on the wall, I learn a little bit more about the problem, and often am able to successfully top the problem.

我喜欢攀岩。 我从2002年开始爬山，多年来，爬山已成为一项家庭活动。 我最喜欢爬坡的一件事就是解决难题。 攀登是要不跌倒地到达墙顶。 我从事的攀岩类型称为抱石攀岩，是指不用绳索攀登，这增加了挑战。 当我处理抱石问题时，根据难度的不同，它可能导致多次跌落。 就像跌倒一样令人沮丧，每次我回到墙上时，我都会学到更多关于该问题的知识，并且通常能够成功地解决该问题。

DevOps的承诺 (The DevOps Promise)

DevOps, especially DevOps at the Enterprise, is like rock climbing, as it too is all about solving hard problems. And like rock climbing, DevOps is my passion.

DevOps，尤其是Enterprise的DevOps，就像攀岩一样，因为它同样也涉及解决难题。 和攀岩一样，DevOps是我的激情所在。

Before we dive into things, let’s review the DevOps promise. DevOps tells us that we’re supposed to deliver software faster, and more safely. When you factor in DevOps at the enterprise, you need to take the following into account:

在深入探讨之前，让我们回顾一下DevOps的承诺。 DevOps告诉我们，我们应该更快，更安全地交付软件。 在企业中考虑DevOps时，需要考虑以下因素：

• Compliance (to keep regulators happy)

  合规 (让监管者满意)

• Security (to keep client information safe)

  安全 (以确保客户信息安全)

• Scale (how to ensure that the entire organization is following DevOps practices)
  扩展(如何确保整个组织遵循DevOps实践)
• Tons of silos (team, department, company-wide, etc.)
  吨筒仓(团队，部门，公司范围内等)
• Hundreds of projects, many of which need to be delivered concurrently
  数百个项目，其中许多项目需要同时交付
• Fluid and dynamic workforce, comprised of mixture of full-time and contract workforce
  流动和动态的劳动力，由全职和合同劳动力组成

系统开发生命周期 (System Development Life Cycle)

Before we dig a bit deeper into things, let’s examine software delivery at a smaller organization. From top to bottom:

在深入研究之前，让我们检查一下较小组织的软件交付。 从上到下：

• Row 1 represents the system development life cycle (SDLC)

  第1行代表系统开发生命周期(SDLC)

• Row 2 (blue square) represents the parts of the SDLC which can be automated

  第2行 (蓝色正方形)代表SDLC的各个部分，这些部分可以自动执行

• Row 3 represents common tools at the enterprise level which support the automation in Row 2.

  第3行代表企业级的通用工具，支持第2行的自动化。

• Row 4 features the DevOps practices which support all of the above

  第4行具有支持上述所有功能的DevOps实践

In a relatively small organization, this can be a relatively simple task. Smaller orgs tend to hire a small team of DevOps engineers who will manually build CI/CD pipelines to manage DevOps.

在相对较小的组织中，这可能是相对简单的任务。 较小的组织倾向于雇用一小组DevOps工程师，他们将手动建立CI / CD管道来管理DevOps。

When you factor in a large organization, however, with tons of silos, distributed workforces, hundreds of concurrent projects, and all sorts of other complexities, you can end up with this DevOps mess:

但是，当您考虑到一个庞大的组织，大量的孤岛，分散的劳动力，数百个并发项目以及各种其他复杂性时，您最终可能会遇到以下DevOps混乱：

赞！ (YIKES!)

DevOps efforts, from manual pipeline creation to scaling practices, suddenly become exceedingly complex. This leads to:

从手动管道创建到扩展实践的DevOps努力突然变得异常复杂。 这导致：

• Duplication of work
  工作重复
• Maintenance nightmares
  维修噩梦
• Automation sprawl
  自动化蔓延

We’re definitely NOT fulfilling the DevOps promise.

我们绝对不能兑现DevOps的承诺。

规模化DevOps是企业最大的挑战 (DevOps at Scale is the Enterprise’s Biggest Challenge)

Consider some additional problems that we see with DevOps in large enterprises:

考虑我们在大型企业中通过DevOps看到的一些其他问题：

• Frustration with the lack of connectivity between the various DevOps tools in their toolchain
  由于其工具链中各种DevOps工具之间缺乏连通性而感到沮丧
• Limited access to self-service infrastructure
  自助服务基础设施的访问权限有限
• Finding the right DevOps skillset
  找到合适的DevOps技能组
• Difficulty managing the complexity of multiple services and environments
  难以管理多种服务和环境的复杂性
• Lack of urgency/budget
  缺乏紧迫感/预算
• Limited support from executive leadership
  行政领导的支持有限
• A mix of legacy (brownfield) and modern (greenfield) applications. This created complexity in terms of deployment strategies and endpoints, toolchain, etc.
  遗留(棕地)和现代(未开发)应用程序的混合。 这在部署策略和端点，工具链等方面造成了复杂性。
• Struggles with siloed teams that could not collaborate as expected
  与无法按预期进行协作的孤立团队作斗争
• Large portion of testing is manual, which slows things down
  测试的大部分是手动的，这会减慢速度

Scaling is about cost. In DevOps we define it as the unit cost of delivering value to a customer.

扩展与成本有关。 在DevOps中，我们将其定义为向客户交付价值的单位成本。

赞！ (YIKES!)

Executing a successful DevOps transformation isn’t without its challenges. Organizations and software products vary in maturity and implementation, making transformation efforts difficult to design and deploy across teams and organizations. Most importantly, in order to truly deliver DevOps value, it must include more than just tooling and automation — so simply purchasing and installing a solution isn’t sufficient.

成功地进行DevOps转换并非没有挑战。 组织和软件产品的成熟度和实施各不相同，因此很难在团队和组织之间设计和部署转换工作。 最重要的是，为了真正实现DevOps的价值，它不仅需要工具和自动化，还必须包括其他内容-因此，仅仅购买和安装解决方案是不够的。

解决方案 (The Solution)

So how do we solve this problem? We solve it with Ephemeral & Multi-Dimensional Pipelines!

那么我们如何解决这个问题呢？ 我们用临时和多维管道解决它！

Say wut?

说w

As the term implies, an Ephemeral Pipeline is a short-lived pipeline. That may seem counter-intuitive, but consider this. The best way to honour DevOps is to make Git a first-class citizen. This means defining everything as code, including the definition of the Pipeline itself. If the pipeline is defined as code, we can create and destroy it as many times as we’d, and will still get the same pipeline and same behaviour in the pipeline each time we recreate it.

顾名思义，临时管道是短命的管道。 这似乎违反直觉，但请考虑一下。 尊重DevOps的最好方法是使Git成为一流的公民。 这意味着将所有内容都定义为代码，包括管道本身的定义。 如果将管道定义为代码，则我们可以创建和销毁它的次数不限，并且每次重新创建它时 ，管道中仍将获得相同的管道和相同的行为。

The pipelines are multi-dimensional, because we have pipelines for Development, QA, and Ops. The pipelines operate independently and orthogonally to each other.

管道是多维的，因为我们有用于开发，质量保证和运营的管道。 管线独立且彼此正交地操作。

This means that the QA team will write their test automation code, and will have their own DevOps pipeline independent of what the dev team does. All they need from the dev team is the release binary that needs to be tested.

这意味着质量保证团队将编写他们的测试自动化代码，并将拥有自己的DevOps管道，而与开发团队的工作无关。 开发团队所需要的只是需要测试的发行二进制文件。

Similarly, the Ops team will have some automation code to deploy the (tested) release binary into Prod.

同样，Ops团队将拥有一些自动化代码，以将(经过测试的)发行版二进制文件部署到Prod中。

Since Git is a first-class citizen, it means that it’s important to get your Git game on. Remember that in an Enterprise DevOps setting, you’re also having to deal with some high coordination costs across different dev teams just to get your code out the door! If you’ve ever worked in a large enterprise setting, you know what I mean. If you haven’t, then lucky ducky!

由于Git是一流的公民，因此这意味着启动Git游戏非常重要。 请记住，在企业DevOps设置中，您还必须处理不同开发团队之间的高昂协调成本 ，只是为了使您的代码行不通！ 如果您曾经在大型企业环境中工作过，那么您就会明白我的意思。 如果您还没有，那么幸运小鸭！

Because of these high coordination costs, there needs to be a way to minimize noise from other teams working on the same application code simultaneously for a future release, while maintaining your sanity. That’s why Ephemeral Pipelines go hand-in-hand with Ephemeral Release Forking. In a nutshell, Ephemeral Release Forking allows you to work in an isolated fork (representing the release you’re working on) of your application code until the release package is deployed into Prod. And as part of that fork, you have an accompanying pipeline. Once your release has gone into prod, you can merge your fork into the Golden Repo and nuke your pipeline. Because your pipeline has been codified, you can recreate it for your next release. For more info, check out Part 1 and Part 2 of the Ephemeral Release Forking posts.

由于这些高昂的协调成本，因此需要一种方法，在保持您的理智的同时，最大限度地减少其他团队在同一应用程序代码上同时为将来的发行而带来的噪声。 这就是为什么临时管道与临时发布分支并驾齐驱的原因。 简而言之， Ephemeral Release Forking允许您在应用程序代码的独立分支(代表您正在处理的发行版)中工作，直到将发行包部署到Prod中为止。 作为分支的一部分，您将拥有一个随附的管道。 将发行版发布到产品中后，您可以将fork合并到Golden Repo中，并核对管道。 因为您的管道已被编码，所以您可以在下一个版本中重新创建它。 有关更多信息，请查看临时发行分叉文章的第1部分和第2部分 。

Want to learn more about Ephemeral & Multi-Dimensional Pipelines, and scaling DevOps at the enterprise? Be sure to follow us for more DevOps and SRE goodies!

想更多地了解临时和多维管道，以及在企业中扩展DevOps？ 请务必关注我们以获取更多DevOps和SRE好东西！

翻译自: https://medium.com/dzerolabs/how-to-fix-your-broken-enterprise-devops-145be3d52ae2

企业devops持续集成