软件交付的谜团需要清晰,这就是部署与发布辩论变得令人兴奋的地方!部署和发布可以互换使用,但它们是否相同,或者您需要知道它们之间的区别?以下是优化软件部署和发布管理所需的所有答案。
部署和发布是软件工程中经常互换使用的两个术语,甚至感觉是等价的。然而,它们是不同的!
在项目研发迭代的过程中,不可避免需要对“应用服务部署上线”。而对于应用程序升级面临最大挑战是新旧业务切换的同时还要保证系统不间断提供服务。特别是微服务盛行的今天,对服务发布的粒度、发布策略控制更佳尤为重要。
创建这个策略只是一个开始而已,随着项目的进行,它也会改变。发布策略的一个关键部分就是发布计划,它用来描述如何执行发布。
CODING 持续部署用于把控构建之后的项目发布与部署交付流程,能够无缝对接上游 Git 仓库、制品仓库以实现全自动化部署。同时还支持 Webhook 等外部对接能力,高效集成各种开发、运维工具。在稳定的技术架构、运维工具等基础上,具备蓝绿发布,灰度发布(金丝雀发布),滚动发布,快速回滚等能力。
在有关微服务、DevOps、Cloud-native、系统部署等的讨论中,蓝绿部署、A/B 测试、灰度发布、滚动发布、红黑部署等概念经常被提到,它们有什么区别呢?通过搜索相关资料,做一个简单的辨析,如下: 一、蓝绿部署(Blue/Green Deployment) 过去的 10 年里,很多公司都在使用蓝绿部署(发布)来实现热部署,这种部署方式具有安全、可靠的特点。蓝绿部署虽然算不上“ Sliver Bullet”,但确实很实用。 蓝绿部署是最常见的一种0 downtime部署的方式,是一种以可预测的方式发布应用的技术,目的是减少发布过程中服务停止的时间。蓝绿部署原理上很简单,就是通过冗余来解决问题。通常生产环境需要两组配置(蓝绿配置),一组是active的生产环境的配置(绿配置),一组是inactive的配置(蓝绿配置)。用户访问的时候,只会让用户访问active的服务器集群。在绿色环境(active)运行当前生产环境中的应用,也就是旧版本应用version1。当你想要升级到version2 ,在蓝色环境(inactive)中进行操作,即部署新版本应用,并进行测试。如果测试没问题,就可以把负载均衡器/反向代理/路由指向蓝色环境了。随后需要监测新版本应用,也就是version2 是否有故障和异常。如果运行良好,就可以删除version1 使用的资源。如果运行出现了问题,可以通过负载均衡器指向快速回滚到绿色环境。 蓝绿部署的优点: 这种方式的好处在你可以始终很放心的去部署inactive环境,如果出错并不影响生产环境的服务,如果切换后出现问题,也可以在非常短的时间内把再做一次切换,就完成了回滚。而且同时在线的只有一个版本。蓝绿部署无需停机,并且风险较小。 (1) 部署版本1的应用(一开始的状态),所有外部请求的流量都打到这个版本上。 (2) 部署版本2的应用,版本2的代码与版本1不同(新功能、Bug修复等)。 (3) 将流量从版本1切换到版本2。 (4) 如版本2测试正常,就删除版本1正在使用的资源(例如实例),从此正式用版本2。 从过程不难发现,在部署的过程中,应用始终在线。并且,新版本上线的过程中,并没有修改老版本的任何内容,在部署期间,老版本的状态不受影响。这样风险很小,并且,只要老版本的资源不被删除,理论上,可以在任何时间回滚到老版本。 蓝绿部署的弱点: 使用蓝绿部署需要注意的一些细节包括: 1、当切换到蓝色环境时,需要妥当处理未完成的业务和新的业务。如果数据库后端无法处理,会是一个比较麻烦的问题。 2、有可能会出现需要同时处理“微服务架构应用”和“传统架构应用”的情况,如果在蓝绿部署中协调不好这两者,还是有可能导致服务停止; 3、需要提前考虑数据库与应用部署同步迁移/回滚的问题。 4、蓝绿部署需要有基础设施支持。 5、在非隔离基础架构( VM 、 Docker 等)上执行蓝绿部署,蓝色环境和绿色环境有被摧毁的风险。 6、另外,这种方式不好的地方还在于冗余产生的额外维护、配置的成本,以及服务器本身运行的开销。 蓝绿部署适用的场景: 1、不停止老版本,额外搞一套新版本,等测试发现新版本OK后,删除老版本。 2、蓝绿发布是一种用于升级与更新的发布策略,部署的最小维度是容器,而发布的最小维度是应用。 3、蓝绿发布对于增量升级有比较好的支持,但是对于涉及数据表结构变更等等不可逆转的升级,并不完全合适用蓝绿发布来实现,需要结合一些业务的逻辑以及数据迁移与回滚的策略才可以完全满足需求。
软件应用一般由开发人员进行程序源代码的编写,调试,集成构建,打包提交给测试人员。测试通过后程序包发布,最后由运维人员进行软件应用的部署。简单的说,软件部署就是把开发好的软件应用给到用户正常使用的过程。
在项目迭代的过程中,不可避免需要进行项目上线。上线对应着部署或者重新部署,部署对应着修改,修改则意味着风险。
目前有很多用于部署的技术,有的简单,有的复杂,有的得停机,有的不需要停机即可完成部署。本文将对目前常用的部署方案做一个简单的总结。
在项目迭代的过程中,不可避免需要”上线“。上线对应着部署,或者重新部署;部署对应着修改;修改则意味着风险。目前有很多部署发布的技术, 这儿将常见的做一个总结。
根据2018年的DevOps发展报告来看,目前的DevOps发展速度非常之快,已经逐渐成为企业运维的标准方案.DevOps的核心就是敏捷和高效,敏捷和Scrum开发技术曾被认为是最好的技术. 既然公司用到了CI/CD肯定就肯定避免不了持续部署,所以我们就需要考虑一套适合我们的发布方式,这个时候我们就需要了解一下这几个发布方式到底是什么意思,有很么好处,他们之间的差别在哪个地方.
在项目迭代的过程中,不可避免需要”上线“。上线对应着部署,或者重新部署;部署对应着修改;修改则意味着风险。 目前有很多用于部署的技术,有的简单,有的复杂;有的得停机,有的不需要停机即可完成部署。本文笔者简单讨论一下目前比较流行的几种部署方案,或者说策略。如有不足之处请指出,如有谬误,请指正^_^。 Blue/Green Deployment(蓝绿部署) 蓝绿部署无需停机,并且风险较小。 (1) 部署版本1的应用(一开始的状态) 所有外部请求的流量都打到这个版本上。 (2) 部署版本2的应用 版本2的代码与版
最近由于需要开发测试环境管理工具,研究了下k8s的设计概念,过程中接触到了蓝绿部署、金丝雀部署、滚动部署等名词。
目前有很多用于部署的技术,有的简单,有的复杂;有的得停机,有的不需要停机即可完成部署。本文的目的就是将目前常用的布署方案做一个总结。
如果你经历体验过传统的应用发布,你可能就会觉得CICD有足够吸引你的地方,反之亦然。一般一个研发体系中都会存在多个角色:开发、测试、运维。当时我们的应用发布模式可以能是这样的:
(1) 蓝绿部署:不停止老版本,额外搞一套新版本,等测试发现新版本OK后,删除老版本。
由于没有建立标准的持续部署流程,导致了版本管理混乱,制品管理混乱,上线持续时间长,上线测试覆盖不全面,业务流量上升后故障较多,排查复杂。运维、测试、开发人员每次版本迭代的时候,都要可能需要经历一次通宵的历练,并且这种在上线的第二天依然会出现很多线上故障。
印记中文一直致力于为国内前端开发者提供技术文档的翻译服务,比如 React, Webpack, Node.js 等技术文档,都能有看到印记中文参与的影子。为了让文档的加载速度更好,我们都把文档全数部署在腾讯云国内的 CDN 服务上。不过这也带来了比较大的成本压力,做部署服务买的机器、每几个月要买 TB 级别的 CDN 流量包。
只有配置了 TKE 集群的认证信息,Coding 才有部署的权限,因而使用 Coding CD 功能的第一步是配置云账号。如下图所示,在 Coding 部署控制台导航栏菜单中选择【云账号】,在云账号管理页面选择【绑定云账号】,云账号类型选择腾讯云 TKE,按照指引完成与云账号名下的集群绑定。
部署是将服务的某个版本投入生产环境的过程。部署的总体目标是:对系统用户产生最小影响的情况下,把服务的升级版本投放到生产环境中。
过去的10年里,很多大公司都在使用蓝绿部署,安全、可靠是这种部署方式的特点。蓝绿部署虽然算不上”Sliver Bullet“,但确实很实用。在有关于“微服务”、“DevOps”、“Cloud-native”的讨论中,蓝绿部署、A/B测试、灰度发布,这三种部署方式往往同时出镜。 那么问题来了,蓝绿部署、A/B测试、灰度发布,这三者之间究竟有何不同? 蓝绿部署 Martin Flower曾在文章中阐述了蓝绿部署的整体要点,建议大家看看。 基本上,蓝绿部署是一种以可预测的方式发布应用的技术,目的是减少发布过程中服
在接触的很多的企业中,持续部署实践依然还有很多不足,基本上部署靠人,更别谈自动化了。我一直强调持续部署是IT交付的核心能力,直接关联到研发/测试和运维多个团队,可以成为一个运维的核心平台。自动化部署能力的高与低,能映射出IT能力的诸多方面的问题,比如说流程上/环境管理上/服务耦合上/平台能力上等等。
第1章 软件交付的问题 介绍 从“决定做某种修改”到“该修改结果正式上线”的这段时间称为周期时间(cycle time)。对任何项目而言,它都是一个极为重要的度量标准。1Implementing Lean Software Development 第59页 真正缺少的是一本讨论如何把各方面(包括配置管理、自动化测试、持续集成和部署、数据管理、环境管理以及发布管理)融合在一起的书 我们的目标是提供一个整体方案,并给出这个方案涉及的各种原则。我们会告诉你如何在自己的项目中使用这些实践 支持部署流水线的生态系统,
排查分布式系统问题用的最多的手段就是查看系统日志,但是目前分布式系统都是部署在多台机器上且多数调用链路比较长,因此日常工作过程中经常出现研发人员同时登录多台机器切换各个终端查询日志的场景。我们希望搭建一个日志收集及查询系统,方便定位问题。
今天我们很高兴公开 [HashiCorp Waypoint](https://www.waypointproject.io/) 项目,它为开发者提供了一个跨平台的构建、部署和发布应用的工作流,而且在所有平台中都可以获得一致的使用体验!借助 Waypoint 你的应用从开发到上线将只需一个配置文件和一个命令 `waypoint up`。
持续交付是一种可以快速,安全和自动化地将软件更改部署到生产中的实践。在持续交付中,发布新功能并不是一件令人痛苦的事件。在没有采用持续交付之前,公司的每个人都在代码完成之后的数周内停止工作,并在开始部署的时候紧张地等待着仪表板。相反向用户发布新软件应该是例行,无聊且容易的,以至于一天可能发生多次。
显然,无论怎样,我们都无法 100% 消除发布风险。我们要做的是不断寻找降低发布风险的方法。
停机部署其实是最简单粗暴的方式,就是简单地把现有版本的服务停机,然后部署新的版本。在一些时候,我们必须使用这样的方式来部署或升级多个服务。比如,新版本中的服务使用到了和老版本完全不兼容的数据表的设计。这个时候,我们对生产有两个变更,一个是数据库,另一个是服务,而且新老版本互不兼容,所以只能使用停机部署的方式。 这种方式的优势是,在部署过程中不会出现新老版本同时在线的情况,所有状态完全一致。停机部署主要是为了新版本的一致性问题。
在 Kubernetes 上的应用实现灰度发布,最简单的方案是引入官方的 Nginx-ingress 来实现。
蓝绿部署、A/B测试、金丝雀发布,以及灰度发布、流量切分等,经常被混为一谈,影响沟通效率。 根本原因是这些名词经常出现,人们耳熟能详能够熟练地谈起,对这些术语的理解却没有达成一致。
持续交付是一组能够帮助软件开发团队极大的提高其软件交付的速度和质量的模式和最佳实践组成。
.NET 6 是最新的 .NET 版本,它最终将.NET Core,Framework,Xamarin和Mono的精华带入以 .NET 5 开始的统一平台。该版本目前为预览版,用于尝试激动人心的新功能,计划于2021年11月正式发布。.NET6 的最终版本将是长期支持(LTS)版,支持3年。在此处查看有关发行版的更多信息。
CI, CD AND CD 当我们在谈论现代的软件编译和发布流程的时候,经常会听到CI 和CD这样的缩写短语。CI很容易理解,就是持续集成。但是CD既可以指代码持续交付,也可理解为代码持续部署。CI和CD之间有很多相似的部分,但是也有很大的区别。这里我们将给大家介绍它们之间的区别和联系。 持续集成(CONTINUOUS INTEGRATION) 在持续集成环境中,开发人员将会频繁的提交代码到主干。这些新提交在最终合并到主线之前,都需要通过编译和自动化测试流进行验证。这样做是基于之前 持续集成过程中很重视自动
Facebook 高速发展的 2007 年到 2016 年,他们一天部署 3 次代码,cherry-pick 集齐成千上万个 commit;现在使用类似持续交付的方法,每个 commit 能自动部署到 production。公司里有很多员工、很多用户的好处:新代码让公司所有员工先用上,因为员工数足够多,能很快发现问题;然后让 2% 的访问量用上新代码,最后慢慢增加到 100% 的访问量。
本文作者:陈钧桐 腾讯云 CODING DevOps 高级解决方案架构师,从事多年技术布道工作,对于云原生时代下企业数字化转型、IT 与 DevOps 建设、价值流体系搭建等有丰富的经验,曾为多家大型企业提供咨询、解决方案以及内训服务。既关注工程师视角的云原生开发建设与最佳实践落地,也关注管理者视角的过程管理与研发效能提升。
如果只看一个服务节点的部署,貌似是一项非常简单的工作,但如果同时发布成百上千个服务节点,尤其是需要在不影响线上业务的前提下完成发布工作,就会变得比较复杂。
对于中小型企业而言,进行主机和应用的管理是比较麻烦的,应用部署往往需要直接连接服务器,再进行手动的环境配置、代码拉取、应用构建和部署发布等工作,容易出错,且耗时费力。一个好的自动化运维平台,往往能大大节省人力物力,提高开发部署效率。Spug,正是一个面向中小型企业设计的轻量级自动化运维平台。
持续部署(Continuous Deploy)的收益是全面的,体现在运维规范、自动化和团队合作等方面。
因为最近踩了太多坑了,所以准备开一个新的系列,分享一些最近新学(cai)到(keng)的东西,更新不定期~
第5章 部署流水线 5.1 引言 持续集成的主要关注对象是开发团队。持续集成系统的输出通常作为手工测试流程和后续发布流程的输入。在软件的发布过程中,很多浪费来自于测试和运维环节。我们常常看到: 构建和运维团队的人员一直在等待说明文档或缺陷修 测试人员等待“好的”版本构建出来 在新功能开发完成几周之后,开发团队才能收到缺陷报告 开发快完成时,才发现当前的软件架构无法满足该系统的一些非功能需求。 解决方案就是采取一种更完整的端到端的方法来交付软件。我们已经解决了配置管理以及自动化大量构建、部署、测试和发布流程的
12.2 DevOps理念 DevOps(Development和Operations的组合)是一组过程、方法与系统的统称,用于促进开发(应用程序/软件工程)、技术运营和质量保障(QA)部门之间的沟通、协作与整合。它的出现是由于软件行业日益清晰地认识到,为了按时交付软件产品和服务,开发和运营工作必须紧密合作。 12.2.1 Development和Operations的组合 可以把DevOps看作开发(软件工程)、技术运营和质量保障(QA)三者的交集。 传统的软件组织将开发、IT运营和质量保障设为各
如今的互联网软件越来越碎片化(micro services),Queue无处不在,服务依赖越来越多,使得软件功能的开发,到软件功能的部署,中间有很长的一段路。这段路,是持续集成(Continuous Integration)和持续发布(Continous Delivery)的基石,一般由devOps包圆了,对从不涉身其中的dev而言,看上去就像ops们用了黑魔法,设了道传送门一样,让写好的代码biu的一下就变成了运行在浏览器,或者手机上的鲜活页面。本着不懂点devOps的dev不是好pm的态度,本文简单讲讲
当单块架构被划分成微服务之后,随着微服务数量的增多,毫无疑问,将会面临比单块架构更复杂的问题。
在 2018 年,Etsy 将它的服务基础设施从自我管理的数据中心迁移到云端配置(我们当时在博客上写了这件事)。这种改变提供了改善整个公司技术流程的机会。对于 Search 团队而言,云环境所带来的灵活扩展让我们可以完全重新评估一个有些繁琐的部署流程。在已有的金丝雀发布架构模式的启发下,我们编写了一个新的自定义工具来补充现有的部署基础设施。
领取专属 10元无门槛券
手把手带您无忧上云