探索持续部署的过程 | 译文

解释持续部署（CDP）很容易。实施它非常困难，因为其中的挑战往往是隐蔽的和不可预期的。根据您的流程、体系结构和代码的成熟度，您可能会发现真正的问题不在于持续部署管道的代码，而在于其他任何地方。事实上，开发一个持续部署管道是最容易的部分。

我们不会讨论您的其他流程中的变化。我们不会探讨您如何为CDP管道提供的良好架构。我们不会深入研究如何将您的应用程序编码为管道友好型的。

我假设您已经知道了这一切。我希望您了解敏捷开发和运维操作背后的基本概念，并且您已经开始研究公司中的技术框架。

我假设您确实知道您的软件架构原生云是什么意思是的，您确实实现了一些（如果不是全部）12个因素。我想您已经在从事测试驱动开发，行为驱动开发，验收驱动开发或任何其他可以帮助您设计应用程序的技术。

我可能错了。更确切地说，我确信我错了。大多数人还没到这种程度。如果您是其中之一，请您仔细阅读下面的内容。您需要阅读更多的书籍，做一些课程，并说服您的项目经理为您提供实现应用程序现代化所需的时间、空间和资源。这项工作需要完成。

所有这些和其他许多东西都是顶级公司（例如谷歌，亚马逊，Netflix）和其余我们的不同之处。尽管如此，它们之间也都不一样。每个高绩效公司都是不同的，然而，他们都有一些共同点。他们都需要快速发布功能。

他们都需要具有高水平的质量。他们都承认，高可用性、容错性和分布式系统需要一种与我们大多数人习惯的方法截然不同的方法。

我们已经在本博客和我发布的书中讨论过持续部署管道的结构。如果您有些遗忘（我知道我是），这里有一些短版本的规则。

规则一：如果通过了完全自动化管道的所有步骤，则每个对主分支的提交都会部署到生产中。如果您需要在提交后涉及人为操作，则不是持续部署，也不是持续交付。充其量，您正在进行持续集成。

规则二：您要直接提交到主分支，或者您正在使用短期特征分支。主分支是唯一重要的分支。生产版本是由它制作的。如果您确实要使用分支，它们将从主分支中获取，因为这是唯一真正重要的分支。

当您创建一个功能分支时，您将再把它合并回主分支。您不是要等几个星期才能这样做。如果您是，那么您不会“持续”验证您的代码是否与其他代码集成。

如果是这样的话，您甚至都没有进行持续集成。除非，您有一个精心设计的分支策略，在这种情况下，您只会让每个人的生活变得比他们原先的状态更复杂。

规则三：您要相信自动化。当测试失败时，就会出现一个错误，您需要并在其他出现任何问题之前修复它。

我希望您不属于那些大公司，这些公司的零星测试有时候工作，有时会因为随机的原因而失败。

如果您确实这样做，请先修复您的测试或删除那些零星的测试。运行您不信任的测试将毫无意义。对于构建，部署以及该过程的任何其他步骤，也可以这样说。

如果您认为自己属于那些不信任其代码的人，那么您必须先修复它。测试是代码，就像构建，部署和其他一切一样。

当代码产生不一致的结果时，我们修复它，而不是我们重新启动它。

不幸的是，我确实看到很多公司宁愿重新运行一个由于测试而导致测试失败的构建，而不是修复这个测试失败的缺陷。

通过重新启动应用程序，解决了一半生产问题的数量惊人。无论如何，如果您不信任自己的自动化，那么您不能自动部署到生产环境。您甚至不能说它已经准备就绪了。

现在我们已经建立了一套简单的基本规则，我们可以继续并描述我们应该开发的管道。我们要建立一些东西。

由于没有运行单元和其他类型的静态测试的建设，应该被宣布为正式非法并且受到“公众羞辱的惩罚”，我们将其包括在我们的构建阶段。

然后，我们将执行功能测试阶段的步骤，该阶段将运行需要实时应用程序的各种测试。因此，我们需要在此阶段部署测试版本。

一旦我们确信我们的应用程序按预期运行，我们将进行生产发布，然后是部署阶段。这不仅会升级生产版本，还会运行另一轮测试来验证一切是否按预期工作。

您可能不同意阶段的名称。没关系。您如何命名，以及如何分组步骤并不重要。重要的是，管道拥有我们需要的一切，以确保将发布安全地部署到生产中。步骤很重要，阶段只是标签。

DevOps 2.4工具包：持续部署到Kubernetes

---

您刚刚阅读的文章摘自 DevOps 2.4 工具包：持续部署到 Kubernetes。

本书探讨了对Kubernetes集群的持续部署。它使用各种Kubernetes平台，并提供了如何在少数最常用的 CI / CD工具上开发管道的说明。

这本书不是您与 Kubernetes 的第一次接触。我假设您已经熟练使用Deployments，ReplicaSets，Pods，Ingress，Services，PersistentVolumes，PersistentVolumeClaims，Namespaces和其他一些工具。本书假设我们不需要学习最基本的东西。至少，不是重新所有。

本书假设了读者具备一定程度的Kubernetes知识和实践经验。如果情况并非如此，那么下面的内容可能会让人感到困惑和进步。

请首先阅读 DevOps 2.3 工具包：Kubernetes，或参考Kubernetes文档。一旦您完成后再回来，一旦您认为您可以声称您至少理解基本的Kubernetes概念和资源类型。

试一试，让我知道您的想法。

翻译：致Great

原文链接：https://technologyconversations.com/2018/07/24/exploring-the-continuous-deployment-process/

研发运营一体化（DevOps）能力成熟度模型 第3部分：持续交付评估现在可以报名了！

欢迎各大企业来电咨询评估报名

评估请咨询：牛晓玲

联系方式：010-62300559
邮箱：niuxiaoling@caict.ac.cn

培训请咨询：杨文惠
联系方式：13021086339
邮箱：yangwenhui@greatops.net

研发运营一体化能力成熟度模型视频介绍▽
点我看视频

标签：探索,Kubernetes,部署,持续,测试,分支,我们,译文
来源： https://blog.51cto.com/15127503/2657781