持续集成持续部署持续交付_持续交付：部署软件的正确方法

持续集成持续部署持续交付

This article was sponsored by Codeship. Thank you for supporting the sponsors who make SitePoint possible!

本文由Codeship赞助。 感谢您支持使SitePoint成为可能的赞助商！

How do you deploy your web site or application to your live server? Does this process sound familiar?

您如何将网站或应用程序部署到实时服务器？ 这个过程听起来很熟悉吗？

1. Get a copy of the latest codebase
   获取最新代码库的副本
2. Add, edit and remove code as necessary
   根据需要添加，编辑和删除代码
3. Test the update
   测试更新
4. Copy all/changed files to the server using FTP
   使用FTP将所有/更改的文件复制到服务器
5. Rinse and repeat
   冲洗并重复

It’s a simple workflow used by many developers. A proportion of developers will also manage updates without source control such as Git or SVN.

这是许多开发人员使用的简单工作流程。 一部分开发人员还将在没有源控制(例如Git或SVN)的情况下管理更新。

The process may be good enough for small projects with infrequent updates. Unfortunately, it breaks down the moment your site or application reaches any level of complexity.

对于不经常更新的小型项目，该过程可能已经足够好。 不幸的是，一旦您的站点或应用程序达到任何复杂程度，它就会崩溃。

传统工作流程的问题 (Problems With a Traditional Workflow)

1.测试不可靠 (1. Testing is not robust)

Is your local system an exact match for your server environment?

您的本地系统是否完全适合您的服务器环境？

2.容易出错 (2. It’s error prone)

A missed file or failure to update a database record could bring down the whole application.

丢失文件或更新数据库记录失败可能会导致整个应用程序崩溃。

3.您正在部署到实时系统 (3. You’re deploying to a live system)

Users could encounter access issues even when the process is successfully completed within a few minutes. Would Amazon, Gmail, Facebook or Twitter users put up with frequent unreliability?

即使过程在几分钟内成功完成，用户也可能会遇到访问问题。 亚马逊，Gmail，Facebook或Twitter用户会忍受频繁的不可靠性吗？

4.很难还原 (4. It’s difficult to revert back)

Your mistakes are live; undoing the changes is not always easy, even if you’re using source control.

你的错误是存在的； 即使使用源代码管理，撤消更改也不总是那么容易。

5.源代码控制可能无法涵盖所有​​可能的情况 (5. Source control may not cover every eventuality)

You could lose database data or other assets which aren’t stored as files.

您可能会丢失未存储为文件的数据库数据或其他资产。

6.这不是未来的证明 (6. It’s not future proof)

The workflow will become increasingly difficult as more developers join the project or additional servers are added.

随着更多开发人员加入项目或添加其他服务器，工作流程将变得越来越困难。

7.运输速度较慢 (7. Shipping is slower)

Manual deployment is painful, so releasing bug fixes and updates is done less often.

手动部署很痛苦，因此发布错误修复和更新的频率降低了。

8.发展是不可预测的，失败可能不是您(直接)的错误 (8. Development is unpredictable and failure may not be your (direct) fault)

A new version of Ruby, Node.js update, framework upgrade or database change on your live server could bring your application to a halt. We rarely consider other software on our stack but even an operating system or infrastructure update could be risky. Do you avoid updates to minimize the hazards despite the speed, stability and security benefits they bring?

实时服务器上的新版本Ruby，Node.js更新，框架升级或数据库更改可能会使您的应用程序暂停。 我们很少考虑我们堆栈上的其他软件，但即使是操作系统或基础架构更新也可能有风险。 尽管它们带来了速度，稳定性和安全性好处，但您是否避免进行更新以将危害最小化？

主要问题： 过程繁琐 (The main problem: the process is laborious)

You could be doing far more productive work. Why should you endure manual updates when software and services can complete the tedious tasks for you? You may already be using build tools such as Grunt, Gulp, make or Rake — so why not complete your workflow process with automated continuous delivery?

您可能会做更多富有成效的工作。 当软件和服务可以为您完成繁琐的任务时，为什么还要忍受手动更新？ 您可能已经在使用诸如Grunt ， Gulp ， make或Rake之类的构建工具-那么为什么不通过自动连续交付来完成工作流程呢？

简而言之，持续交付 (Continuous Delivery in a Nutshell)

Continuous Delivery allows you and your team members to rapidly, reliably and repeatedly deploy fixes, enhancements and new features to your live server. The aim is to reduce risk and manual intervention. You’ll also encounter the term Continuous Integration which refers to the test-driven development part of this process. That said, the two terms are often used interchangeably.

通过持续交付，您和您的团队成员可以快速，可靠和重复地向实时服务器部署修补程序，增强功能和新功能。 目的是减少风险和手动干预。 您还将遇到术语“ 持续集成” ，它表示此过程中测试驱动的开发部分。 也就是说，这两个术语通常可以互换使用。

Continuous Delivery can be imagined as a deployment pipeline through which software flows from developers to the live server. The flow can be stemmed if any person or system notices a critical error. The process generally follows these steps although policies will differ from team to team:

连续交付可以想象成一个部署管道，通过该管道软件可以从开发人员流向实时服务器。 如果任何人或系统发现严重错误，则可以阻止该流程。 尽管团队之间的政策会有所不同，但是该过程通常遵循以下步骤：

1. A developer writes automated software tests and code before testing and validating their updates locally. Any number of developers could be working on different updates, each having created their own branch of the current application.
   开发人员在本地测试和验证其更新之前，会编写自动化的软件测试和代码。 任何数量的开发人员都可以从事不同的更新，每个开发人员都创建了自己的当前应用程序分支。
2. The branch is pushed to a central version control repository such as GitHub or BitBucket. Typically, this results in a pull request which can be reviewed by another developer before being merged into the main software branch.
   分支被推送到中央版本控制存储库，例如GitHub或BitBucket。 通常，这会导致请求请求，在合并到主软件分支之前，其他开发人员可以对其进行审查。
3. The Continuous Delivery system automatically pulls the updated software, runs build processes and executes automated tests again. This happens on a staging server which has an identical environment to the live server. Developers are notified if any failures occur.
   持续交付系统会自动提取更新的软件，运行构建过程并再次执行自动化测试。 这在具有与实时服务器相同环境的登台服务器上发生。 如果发生任何故障，将通知开发人员。
4. Additional user acceptance testing and evaluation can now be performed on the staging server by the product owners and/or clients.
   产品所有者和/或客户现在可以在登台服务器上执行其他用户接受测试和评估。
5. On final approval, all changes are deployed to the live server quickly and painlessly, without any effort from the developer.
   经过最终批准，所有更改都可以快速，轻松地部署到实时服务器，而无需开发人员的任何努力。

Continuous Delivery is often used in agile development environments but you can adopt it regardless of the processes you use. The process comes with a host of benefits:

连续交付通常用于敏捷开发环境中，但是无论您使用什么过程，都可以采用它。 该过程具有许多好处：

• The deployment process is robust. You’ll have confidence that an update will work before it’s installed on the live server.
  部署过程很健壮。 您将有信心在将更新安装到实时服务器上之前，该更新将可以工作。
• There are fewer risks. The process is less prone to human error and, in the event of catastrophic failure, you can roll back the application to a working state.
  风险更少。 该过程不太容易发生人为错误，并且在发生灾难性故障时，您可以将应用程序回滚到工作状态。
• Quality control is maintained. Only approved code should be put live.
  保持质量控制。 只有批准的代码才能生效。
• Your team becomes more productive and development costs are reduced. The initial set-up time investment will be repaid within a matter of days now that developers do not need to be involved in manual deployment processes.
  您的团队将变得更有生产力，并且降低了开发成本。 由于开发人员无需参与手动部署过程，因此可以在几天之内收回最初的设置时间投资。

But the benefits of Continuous Delivery are significantly greater when you don’t need to manage the software yourself.

但是，当您不需要自己管理软件时，连续交付的好处就更大了。

自动化连续交付服务 (Automated Continuous Delivery Services)

Installing, configuring and managing a suite of Continuous Delivery software products can be daunting, time-consuming and expensive, with some products being difficult to work with. While apps and services like Slack, Crashlytics and Pusher make other developer tasks simpler, others are doing the same for Continuous Delivery.

安装，配置和管理一系列持续交付软件产品可能会令人生畏，耗时且昂贵，并且某些产品难以使用。 尽管Slack，Crashlytics和Pusher之类的应用程序和服务使其他开发人员的任务变得更简单，但其他人对于持续交付也是如此。

One such example is Codeship, a UX-focused product that can take care of the Continuous Delivery process for you. Their systems are designed to be user-friendly, but you can get assistance and advice from a real person should you require it. The average set-up time? Four minutes. That’s quicker than a single FTP session and you need only do it once! They also have a free plan, offering up to five private projects and 100 builds per month.

这样的例子就是Codeship ，它是一种专注于UX的产品，可以为您处理持续交付过程。 他们的系统设计为易于使用，但是如果需要，您可以从真实的人那里获得帮助和建议。 平均设置时间？ 四分钟 。 这比单个FTP会话快，您只需要执行一次！ 他们还有免费计划 ，每月最多提供五个私人项目和100个构建版本。

To learn a bit more about Continuous Delivery, Codeship offers a five-day email “crash course” on the subject — there’s a link to sign up at the bottom-left of their homepage.

要了解有关持续交付的更多信息，Codeship提供了一个为期五天的电子邮件“速成课程”，该课程的主题是在网站左下角的链接 。

Continuous Delivery is a great way to leave the drudgery of FTP deployment behind, hopefully forever, and worth investigating.

持续交付是一种摆脱FTP部署繁琐工作的好方法，希望永远进行下去，值得研究。

Have you given Continuous Delivery a try? What are your tips for managing deployment?

您是否尝试过“持续交付”？ 您管理部署的提示是什么？

翻译自: https://www.sitepoint.com/continuous-delivery-right-way-deploy-software/

持续集成持续部署持续交付