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

解释持续部署(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时代(DevOpsTimes)

原文发表时间:2018-07-31

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏WeTest质量开放平台团队的专栏

一分钟读懂兼容测试报告(一):概况篇

原文链接:https://wetest.qq.com/lab/view/425.html

1171
来自专栏BestSDK

产品经理与测试工程师的5点根本区别

相对设计和开发来说,测试工程师是产品经理接触较少的一类人群,因为测试人员往往也是躲在项目幕后,默默地奉献着自己,确保产品能够正常运行。产品测试是很重要的一个环节...

3214
来自专栏重庆的技术分享区

微服务介绍

原文地址:https://medium.freecodecamp.org/an-introduction-to-microservices-2705e7758f...

1832
来自专栏云计算D1net

如何成功地实现混合云应用集成

在混合云环境中,很难确保所有应用程序都能很好地组合在一起。行业专家将帮助人们思考这一过程。 ? 越来越明显的是,很多采用云计算的企业采用的是混合云。如果应用程...

33111
来自专栏杨建荣的学习笔记

运维开发流程梳理和思考

记得之前梳理过一个运维开发流程,也做了一些实践,从我的认识和理解来看,其实这更适合一个团队内的协作。

2193
来自专栏CSDN技术头条

2017年度盘点丨基础架构演化:从“以资源为中心”到“以应用为中心”的迁移

作者:刘建,搜狗架构师,商业平台基础平台负责人,十多年Java相关研发经验,在互联网软件体系结构、分布式计算、面向服务体系结构、用户身份安全等方面有浓厚的兴趣及...

2249
来自专栏ThoughtWorks

「微前端」- 将微服务理念扩展到前端开发 | 洞见

前言 在 ThoughtWorks 正式发布的最新一期技术雷达当中,「微前端(Micro Fontends)」已经进入到试验阶段,而试验环所列出的技术是我们认为...

4707
来自专栏Rainbond开源「容器云平台」

干货下载:谷歌、亚马逊等十大公司微服务案例精选

2814
来自专栏互联网数据官iCDO

在微信小程序里,我们要怎样做数据分析

近期本来打算系统的写一下App数据分析的套路,但忽然“微信小程序”发布了。作为一名信仰互联网和做数据分析多年的“老司机”,看到新事物我也是很兴奋的。不过我还没看...

9745
来自专栏北京马哥教育

基础拾遗--【转】性能测试的主要概念和计算公式

PS:下面是性能测试的主要概念和计算公式,记录下: 一.系统吞度量要素: 一个系统的吞度量(承压能力)与request对CPU的消耗、外部接口、IO等等紧...

3328

扫码关注云+社区

领取腾讯云代金券