敏捷看板工具 私有部署_如何在敏捷软件开发中使用部署管道

敏捷看板工具 私有部署

“Pipelines”, that’s what the menu in Azure DevOps says. Nothing more, nothing less. They can be used for anything. They’re a great tool to deploy software to resources in the cloud. But a pipeline can do much more than that.

这就是Azure DevOps中的菜单所说的“管道”。 仅此而已。 它们可以用于任何东西。 它们是将软件部署到云中资源的绝佳工具。 但是管道可以做的远不止这些。

Companies race each other. Who ships something new to the internet first? Who can serve a new market first? Deploying quickly, and often, is a huge competitive advantage. To be able to bring something new to production, the game is to get the software to the end-user as quickly as possible. Preferably before the feature is completed. That way, we can test assumptions and change our plan before we waste a fortune on building the perfect product that nobody needs. And that’s what pipelines are for. Building relevant software, quicker!

公司互相竞争。 谁先向互联网发布新内容？ 谁先为新市场服务？ 快速且经常部署是巨大的竞争优势。 为了能够带来新的生产成果，游戏就是尽快将软件提供给最终用户。 优选在特征完成之前。 这样，我们就可以测试假设并更改计划，然后再浪费大量时间来构建没人需要的完美产品。 这就是管道的用途。 构建相关软件，更快！

Pipelines can do much more than just installing things on cloud resources. They’re a tool to automate OPS-, development-, test- and even administrative processes to get feedback quicker, and to bring value to the client a.s.a.p.!

管道可以做的不仅仅是在云资源上安装东西。 它们是使OPS，开发，测试乃至管理流程自动化的工具，可以更快地获得反馈，并尽快为客户带来价值！

Deploying more often seems to be the obvious answer. If life were only that simple… How many issues are caused by software updates? Just throwing newer software at a resource continuously is reckless. You need to talk to your stakeholders before you install something new, and they want to be sure it won’t ruin their business. And just that, that’s what pipelines are for!

经常部署似乎是显而易见的答案。 如果生活只有这么简单……多少问题是由软件更新引起的？ 只是不断地向资源投放更新的软件是鲁re的。 在安装新产品之前，您需要与利益相关者进行交谈，他们希望确保它不会破坏他们的业务。 就是这样，这就是管道的目的！

This article outlines:

本文概述：

• Things you can do with a pipeline.
  您可以使用管道执行的操作。
• What stages should a pipeline have?
  管道应处于什么阶段？
• Why you need different environments and how your pipeline copes with that.
  为什么需要不同的环境以及您的管道如何应对。
• How to deal with versions and environments.
  如何处理版本和环境。

第1部分。您可以使用管道执行的操作 (Part 1.) Things you can do with a pipeline)

Pipelines are much more than an installation vehicle. Pipelines automate business-processes. Ultimately, a deployment-pipeline automates as many deployment-related business processes as possible. For example:

管道不仅仅是安装工具。 管道使业务流程自动化。 最终，部署管道将尽可能多的与部署相关的业务流程自动化。 例如：

编译和安装软件 (Compiling and installing the software)

The most common use of a pipeline is to compile source-code. A pipeline can pull source-code from a repository and compile it. That will result in artifacts that the pipeline installs on a cloud-resource.

管道最常见的用途是编译源代码。 管道可以从存储库中提取源代码并进行编译。 这将导致管道安装在云资源上的工件。

测试软件的新版本 (Testing the new version of the software)

Quality assurance is an important part of the software delivery process. Everything, ranging from validating requirements, taking screenshots, and generating test-reports, can be done by your pipeline.

质量保证是软件交付过程的重要组成部分。 您可以通过管道完成所有工作，从验证需求，截取屏幕截图到生成测试报告。

This is just the tip of the iceberg, but pipelines typically contain these steps:

这只是冰山一角，但是管道通常包含以下步骤：

Does the new software do what it is supposed to do?Before installing software on a production site, stakeholders would generally like to see it. They want to make sure their features have been implemented correctly before they’re installed on the production site. Perhaps they’ll open a browser, go to your application, click some buttons to see if the application does what they expect. That’s something your pipeline can do, too! Frameworks like Selenium, Cypress, or any other click-automation framework can automatically click through the application and read from the screen to see if anything broke. These frameworks can even take screenshots and generate a report. And if clicking through the application fails, you can use your pipeline to stop the installation.

新软件会执行应做的工作吗？ 在生产现场安装软件之前，利益相关者通常希望看到它。 他们希望在将功能安装到生产站点之前，确保已正确实现其功能。 也许他们会打开浏览器，转到您的应用程序，单击一些按钮以查看该应用程序是否达到了预期的效果。 这也是您的管道可以做的！ 诸如Selenium，赛普拉斯(Cypress)的框架或任何其他单击自动框架都可以自动单击该应用程序，并从屏幕上读取以查看是否有任何问题。 这些框架甚至可以截取屏幕截图并生成报告。 如果单击该应用程序失败，则可以使用管道停止安装。

Will an installation potentially be successful?A pipeline has several stages. One per environment. But who says the environment contains every resource required by the application to run? You can use your pipeline to validate it. Use pre-installation checks to make sure your database is accessible, or to make sure that new third party API you’re going to use hasn’t been blocked in the firewall. Because if that’s the case, just let your pipeline cancel the deployment because it’s going to fail anyway.

安装会成功吗？ 管道有几个阶段。 每个环境一个。 但是谁说环境包含应用程序运行所需的所有资源？ 您可以使用管道进行验证。 使用预安装检查来确保您的数据库可访问，或者确保您要使用的新的第三方API没有在防火墙中被阻止。 因为如果是这样的话，那就让您的管道取消部署，因为部署还是会失败。

Has the installation been successful?Pre-installation checks aren’t a guarantee for working software. They anticipate the expected problems. But the real problem is with the things you don’t expect. That’s what post-installation checks are for. Let your pipeline validate if the updated software is up and running after the installation. Just invoke an endpoint to see if it returns a 200 OK. If it doesn’t, you’ve probably broken something! Use your pipeline to automatically roll-back and restore the environment?

安装成功了吗？ 安装前检查不能保证软件正常运行。 他们预料到了预期的问题。 但是真正的问题是出乎您意料之外的事情。 这就是安装后检查的目的。 让管道验证安装后更新的软件是否已启动并正在运行。 只需调用一个端点以查看它是否返回200 OK。 如果没有，您可能已经损坏了某些东西！ 使用管道自动回滚并还原环境？

There are no out-of-the-box tools that validate the presence of resources in an environment. The development-team usually builds a test-assembly that contains the checks they need, or by a PowerShell script that runs Pester tests in the pipeline.

没有开箱即用的工具可以验证环境中资源的存在。 开发团队通常会构建一个包含所需检查的测试程序集，或者通过 在管道 中运行 Pester 测试 的PowerShell脚本来构建该程序集 。

生成文档和发行说明 (Generating documentation and release notes)

Every sprint, we complete user stories. They are linked to features. Once the user story is completed we close the work-items. When we create a pull request, we’ll mention those work-items.

每次冲刺，我们都会完成用户故事。 它们链接到功能。 用户故事完成后，我们将关闭工作项。 创建拉取请求时，我们会提到这些工作项。

Every release contains one or many pull-requests. Based on the version-control system, the features that are in the release can be traced back. That means you can automatically generate release-notes! Several plug-ins are available that do just this. Check out this plug-in, for example!

每个版本都包含一个或多个拉取请求。 基于版本控制系统，可以追溯该版本中的功能。 这意味着您可以自动生成发行说明！ 有几个插件可以做到这一点。 例如，查看此插件 ！

The same thing goes for your functional documentation. If you write your tests carefully, they can be used to generate functional documentation automatically. Look into Cucumber!

功能文档也一样。 如果您仔细地编写测试，则可以使用它们自动生成功能文档。 看Cucumber ！

安装新的云资源或运行迁移 (Installing new cloud-resources or run migrations)

Not having the resources needed by the software, may not have to be a problem. Why not have a pipeline install these resources during the installation?

没有软件所需的资源，可能不一定是问题。 为什么在安装过程中没有管道安装这些资源？

要求利益相关者批准 (Asking stakeholders for approval)

In many companies, there’s just one more process. Not a technical issue at all. Before updating an environment, someone needs to approve that installation. And these approvals need to be logged for compliancy-reasons.

在许多公司中，只有一个过程。 根本不是技术问题。 在更新环境之前，需要批准某人的安装。 而且，出于合规原因，需要记录这些批准。

Platforms like Azure-DevOps contain steps you can include in your pipeline that will send an e-mail to a list of users. The e-mail contains a link to a page with an approve button. And they can choose to either approve or disapprove a deployment.

像Azure-DevOps这样的平台包含您可以包含在管道中的步骤，这些步骤将向用户列表发送电子邮件。 该电子邮件包含带有批准按钮的页面链接。 他们可以选择批准或不批准部署。

您有管道无法做的任何事情吗？ (Is there anything you can’t do with a pipeline?)

Pipelines can automate pretty much any process. Ranging from generating e-mails to installing software, to migrating databases. It won’t surprise me if you’re able to create a pipeline that performs a phone-call or launches a rocket to Mars.

管道几乎可以使任何过程自动化。 从生成电子邮件到安装软件，再到迁移数据库。 如果您能够创建执行电话呼叫或向火星发射火箭的管道，这也不会令我感到惊讶。

第2部分。管道应处于哪些阶段？ (Part 2.) What stages should a pipeline have?)

Pipelines are much more than just a set of technical tasks. They are the automated version of a complete IT-department (and more). They contain steps that automate multiple disciplines. It’s not just an OPS thing. There’s a virtual software-developer in that pipeline, and a tester, and somebody from OPS, somebody from the legal department perhaps, and a test-coordinator, and many more!

管道不仅仅是一组技术任务。 它们是完整的IT部门(及更多)的自动化版本。 它们包含使多个学科自动化的步骤。 这不仅仅是OPS的事情。 该管道中有一个虚拟软件开发人员，一个测试人员，一个来自OPS的人员，一个来自法律部门的人员，一个测试协调员等等！

A pipeline has a purpose that’s much bigger than just installing software. It’s an automated process that allows you to ship things to production worry-free, without any manual work. Think of a pipeline as a series of quality gates. Consider this:

管道的目的远不只是安装软件。 这是一个自动化的过程，使您无需进行任何手动操作即可将其运送到生产中而无后顾之忧。 可以将管道视为一系列质量门。 考虑一下：

• If the software doesn’t do what it is supposed to do, functionally, it should not be installed in any environment, and most certainly not in production!
  如果该软件在功能上无法实现其应有的功能，则不应将其安装在任何环境中，并且绝对不能在生产环境中安装！
• If the installation of the software doesn’t work, we don’t want to install it in any environment, and most certainly not in production.
  如果无法安装该软件，则我们不希望在任何环境中安装该软件，并且绝不希望将其安装在生产环境中。
• If the software doesn’t work well with the API’s it depends on, we might want to install it on a test environment to be able to analyze and fix the problem, but we certainly don’t want to install it on the production site.
  如果该软件不能很好地依赖于它所依赖的API，则我们可能希望将其安装在测试环境中，以便能够分析和解决问题，但是我们当然不希望将其安装在生产现场。

All of the above can be solved by using the DTAP concept. DTAP is an abbreviation for four environments: The Development environment, the Test environment, the Acceptance environment, and the Production environment. It’s a concept that existed way before deployment pipelines, but relevant nonetheless.

通过使用DTAP概念可以解决以上所有问题。 DTAP是以下四种环境的缩写：开发环境，测试环境，验收环境和生产环境。 这是在部署管道之前存在的概念，但是仍然很重要。

An environment is a group of resources an application runs on. Every environment has a purpose. Different people use the environment for different reasons:

环境是应用程序在其上运行的一组资源。 每个环境都有其目的。 不同的人出于不同的原因使用环境：

• The development environment is the place where work is done. If things are broken there, that’s okay. That’s what it’s for. It is the place where work is in progress. A developer might run a development environment on his local machine. It’s not uncommon to have a resource group in a cloud, either.

  开发环境是完成工作的地方 。 如果那里的东西坏了，那没关系。 这就是它的目的。 这是正在进行工作的地方。 开发人员可以在其本地计算机上运行开发环境。 在云中拥有资源组也很常见。

• When the development team thinks the software is good enough to be tested, they install it in a test environment. The test-environment is the environment where the team makes sure the software works end to end. That includes the integration with third-party API’s or with other APIs in the company they have to integrate with.

  当开发团队认为该软件足以进行测试时，便将其安装在测试环境中。 测试环境是团队确保软件端到端运行的环境。 这包括与第三方API或必须与其集成的公司中的其他API的集成。

• The acceptance environment is a copy of the production environment. Typically, the OPS team is in charge of the Acceptance environment. This environment is used by stakeholders to make sure the software does what they expected it to do, functionally. The installation procedure on the Acceptance environment should be equal to the installation procedure on the Production site. So if that fails, expect trouble in production!

  验收环境是生产环境的副本。 通常，OPS团队负责验收环境。 利益相关者使用此环境来确保软件在功能上达到了他们的预期。 验收环境中的安装过程应与生产站点上的安装过程相同。 因此，如果失败了，请期待生产中的麻烦！

• The production site. That’s where the money is made. Developers don’t have access to it, neither do testers. Only end-users do.

  生产现场。 那就是赚钱的地方。 开发人员无权访问，测试人员也无权访问。 只有最终用户可以。

从开发人员的计算机到生产现场的旅程 (The journey from the developer’s computer to the production site)

A pipeline compiles source-code. That source-code becomes an artifact that will be installed on the environments of a DTAP-street. The deployment pipeline steers that artifact, the package as it were, from one environment to next.

管道编译源代码。 该源代码成为将被安装在DTAP街道环境中的工件。 部署管道将工件(即软件包)从一个环境引导到另一个环境。

Software travels from one stage to another

软件从一个阶段转移到另一个阶段

Don’t think of a deployment pipeline as a deployment vehicle, think of it as an information pipeline. Everybody in the software delivery process has questions about new versions of the software, and the deployment pipeline provides just that. But not everybody is interested in every version of the software:

不要将部署管道视为部署工具，而应将其视为信息管道。 软件交付过程中的每个人都对软件的新版本有疑问，而部署管道就提供了这些问题。 但是并不是每个人都对该软件的每个版本都感兴趣：

The build stage (for the development team):

构建阶段(针对开发团队)：

• Does the application build? Are there any coding errors?
  应用程序会生成吗？ 有编码错误吗？
• What business rules have been implemented correctly?
  哪些业务规则已正确实施？
• What business rules haven’t been implemented correctly?
  哪些业务规则未正确实施？

The development stage (for the development team):

开发阶段(针对开发团队)：

• Does the installation work at all?
  安装工作正常吗？
• Does a deployed version of the software run in any environment?
  该软件的已部署版本是否可以在任何环境中运行？

The test stage (for the development team):

测试阶段(针对开发团队)：

• Does the installation integrate with the systems it depends on?
  安装是否与它所依赖的系统集成？
• Does the software work, end to end?
  该软件可以正常工作吗？

The acceptance stage (for the ops team and the stakeholders):

验收阶段(针对运营团队和利益相关者)：

• Are the stakeholders happy?
  利益相关者高兴吗？
• Will the installation of production go smoothly?
  生产安装会顺利吗？
• Will the software work on an environment that has the same specs production has?
  该软件是否可以在具有相同规格生产的环境上运行？

The production stage (for the ops team and the stakeholders):

生产阶段(针对运营团队和利益相关者)：

• Has the installation been successful?
  安装成功了吗？

创建具有多个阶段的单个管道 (Create a single pipeline with multiple stages)

Not all questions need answering right away. Not every build is going to production. And to make matters more complex, some information can only be collected in a particular environment. In many cases, for example, testing the system end to end results in updates to the data. That may be an issue in an acceptance- or a production environment. That’s why every stage only collects some information.

并非所有问题都需要立即回答。 并非每个构建都将投入生产。 为了使事情变得更复杂，某些信息只能在特定的环境中收集。 例如，在许多情况下，对系统进行端到端测试会导致数据更新。 在验收或生产环境中，这可能是个问题。 这就是每个阶段仅收集一些信息的原因。

Don’t make a pipeline per stage. How will you ensure everything works on production? And how will other teams be able to test if their software integrates with yours? All of the questions above need answering to ensure a properly working version of the software on the production site. And the software needs to be installed on every environment to ensure it keeps working when other teams ship their software to production. Make one pipeline with multiple stages and run the software through every stage of de environment.

不要在每个阶段都制作一条流水线。 您如何确保一切都能在生产中正常进行？ 以及其他团队将如何测试他们的软件是否与您的软件集成在一起？ 以上所有问题都需要回答，以确保生产站点上的软件版本正确。 而且该软件需要安装在每个环境上，以确保当其他团队将其软件交付生产时，该软件可以继续工作。 使一个管道具有多个阶段，并在环境的每个阶段中运行软件。

TAP会做的很好 (TAP will do fine)

Lately, most companies don’t bother to create both the development- and the testing environment. Development is done on a developer’s machine, and the development- and test stage from the deployment pipeline are merged. The result? A pipeline that has a test, acceptance- and production environment only.

最近，大多数公司都不会花时间去创建开发和测试环境。 开发是在开发人员的机器上完成的，并且部署管道中的开发和测试阶段已合并。 结果？ 仅具有测试，验收和生产环境的管道。

本本 (The run-book)

Remember OPS-teams used to write run-books? “First run this script, run that pipeline and then configure that server and finally, go to that website to see if it worked. If it doesn’t, inform John and restore the previous version.”

还记得曾经用来编写运行手册的OPS团队吗？ “首先运行此脚本，运行该管道，然后配置该服务器，最后，访问该网站以查看其是否有效。 如果没有，请通知John并恢复以前的版本。”

A pipeline is a run-book. It is an automated, autonomous installation process people can trigger without spending any thought to it. It automates what used to be in the run-book and much more.

管道是一本运行手册。 这是人们可以自动触发的自动安装过程，无需花任何时间进行思考。 它可以自动化运行手册中的内容，甚至更多。

第3部分。如何处理版本和环境 (Part 3.) How to deal with versions and environments)

Software development and operating IT-environments are two completely different disciplines. Software development it’s all about source-code and producing new features a.s.a.p.. OPS is about keeping an environment alive with compiled versions of the source code of a given point in time. Developers don’t have to do disaster recovery, OPS-people do.

软件开发和运营IT环境是两个完全不同的学科。 软件开发全都涉及源代码并尽快产生新功能。 OPS旨在通过给定时间点的源代码的编译版本使环境保持活动状态。 开发人员不必像OPS人员那样进行灾难恢复。

OPS installs new software. When things go wrong they are the ones that have to restore the environment as quickly as possible. And if that fails, that’s when the business starts losing money.

OPS安装新软件。 当出现问题时，必须尽快恢复环境。 如果失败了，那就是企业开始亏损的时候。

Imagine an IT-environment that runs version A of the source-code. A couple of days later the build-server gets updated and a new version of the compiler has been installed. At some point in time, OPS installs version B onto the production site and that goes wrong. To restore the environment, they run a new build of version A, but it doesn’t compile anymore. Oops…

想象一下一个运行源代码A版的IT环境。 几天后，更新了构建服务器，并安装了新版本的编译器。 在某个时间点，OPS将版本B安装到生产站点上，这是错误的。 为了恢复环境，他们运行了版本A的新版本，但不再编译。 糟糕...

There’s a difference between version control and version control. Developers use GIT for version control, but that’s not going to work for OPS purposes. Retain builds instead. Save the built version of the software too! That way OPS can skip the build step, and be certain to install the same version that used to be in a particular environment.

版本控制和版本控制之间有区别。 开发人员使用GIT进行版本控制，但这不适用于OPS。 保留构建。 也保存软件的内置版本！ 这样，OPS可以跳过构建步骤，并确保安装以前在特定环境中使用的相同版本。

向后兼容 (Backward compatibility)

Installing a previous version of the software onto an environment isn’t going to work if the database-schema is incompatible. And being able to restore a previous version is important. It’s “Plan B” when disaster strikes.

如果数据库架构不兼容，则无法在环境中安装该软件的先前版本。 能够还原以前的版本很重要。 灾难来袭时，这是“计划B”。

Spend some time to figure out a way to make every version backward compatible. When renaming a column of a table, keep the old column up to date too, for at least one version. These little things make the software backward compatible.

花一些时间找出使每个版本向后兼容的方法。 重命名表的列时，对于至少一个版本，也要使旧列也保持最新。 这些小事情使软件向后兼容。

基础设施也是可交付的！ (Infrastructure is a deliverable, too!)

Use your acceptance environment to make sure your software is compatible with the production site. Finding out the software isn’t compatible with the production site, on the production site, causes down-time. Testing it on the acceptance-environment is the next best thing. To be able to draw any conclusions at all, the acceptance- and the production site need to be more or less similar.

使用接受环境来确保您的软件与生产站点兼容。 在生产站点上发现软件与生产站点不兼容会导致停机。 接下来的事情就是在接受环境上对其进行测试。 为了完全得出任何结论，验收现场和生产现场必须或多或少相似。

That leaves the problem of keeping multiple environments alike. To do that, you’ll need a blueprint of the environment to compare the others with. What better way of doing that then coding your infrastructure? Use Cloud formation templates, Terraform, or ARM-templates, for example, to create a blueprint of an environment in code. They can generate the same environment over and over again in multiple places.

这留下了保持多个环境相同的问题。 为此，您需要一个环境蓝图以与其他环境进行比较。 还有什么比对基础架构进行编码更好的方法了？ 例如，使用Cloud形成模板，Terraform或ARM模板在代码中创建环境的蓝图。 他们可以在多个地方一遍又一遍地生成相同的环境。

These scripts are idempotent. So they too can be run in a pipeline.

这些脚本是幂等的。 因此它们也可以在管道中运行。

摘要 (Summary)

Build pipelines are more than deployment vehicles. They provide information about the fitness of the software. They provide functional information, and they’re a way to practice the installation to the production site.

构建管道不仅仅是部署工具。 它们提供有关软件适用性的信息。 它们提供功能信息，并且是练习在生产现场进行安装的方式。

Use a build to test the business rules of the software, in isolation. Use a separate environment to ensure the software integrates with the components in its environment. Use a test- and an acceptance-environment to do perform both technical and functional checks.

单独使用构建来测试软件的业务规则。 使用单独的环境，以确保软件与其环境中的组件集成在一起。 使用测试和验收环境来进行技术和功能检查。

Builds aren’t branches. Versioning code, developing new features, and releasing software is a different ball game. When releasing software, make sure to move a compiled version of the software from one environment to the next. Don’t pull any files from repositories during a deployment. Artifacts must be static to make OPS easy.

构建不是分支。 版本控制代码，开发新功能以及发布软件是另一回事。 发行软件时，请确保将软件的编译版本从一个环境移至另一个环境。 在部署期间，请勿从存储库中提取任何文件。 工件必须是静态的才能使OPS变得容易。

Make sure environments are alike. That’s hard. Especially when you’ve got a complex infrastructure. Or is it? Use Infrastructure as Code to replicate environments. It too can run in a pipeline.

确保环境相同。 辛苦了 尤其是当您拥有复杂的基础架构时。 还是？ 使用基础结构作为代码来复制环境。 它也可以在管道中运行。

Create meaningful packages. Separate build from release. Retain builds longer than your release cadence. That way you can run ’em through your deployment pipeline whenever you want.

创建有意义的包。 将版本与发布分开。 保留版本的时间长于发布节奏。 这样，您可以随时在部署管道中运行它们。

翻译自: https://medium.com/swlh/how-to-use-deployment-pipelines-in-agile-software-development-ec1be6592a63

敏捷看板工具 私有部署