持续交付的目的

以下问题有没有解决？
“快速将产品推向市场” 与 “提供稳定、安全并可靠的IT服务” 是否可以兼得？
用更少的资源完成更多的业绩，既要保持竞争力，又要削减成本；
如何解决任务交接出现的问题，例如业务与开发，开发与运维之间；
运维人员能否和其他人一样，正常上下班，而不用在夜里或者周末加班？

部署和发布的区别

要弄清楚部署和发布的区别，首先要弄清楚几个名词之间的关系CI(Continues Intergation)持续集成，CD(Continues Delivery)持续交付，持续集成的目的是对代码的快速反馈，在分布式开发的团队中你的更改不会破坏已有代码功能，持续交付的scope要大一些，指的是对用户交付最终价值，传统的交付最终价值即为产生可发布的版本，有的公司在持续交付的基础之上甚至提出了持续部署（Continous Deployment），即自动化讲可发布版本放入到产品环境，其中就涉及到蓝绿部署，滚动部署等部署方式。在部署和发布解耦之后，在将产品部署到产品环境之后我们可能还有些功能是不想对用户可见的，在对用户可见的的这个过程我们称之为发布（Release）（如图）。DevOps运动则是在发布之后有引入运维和运营的角色，和用户反馈一起形成一个闭环。恩，差不多是这个样子的。

ThoughtWorks在15年的技术雷达上已经建议解耦部署和发布:


# 零宕机发布（目标）
```零宕机发布指的一种将用户从一个版本几乎瞬间转移到另一个版本上的方法，更重要的是，如果出了什么问题，他还要能在瞬间把用户从这个版本转回到原先的版本上。

零宕机发布的关键在于将发布流程中不同的部分解耦，尽量使他们能独立发生。

凤凰式部署

将产品环境和应用打包发布，在容器产生之前是将系统和应用制作镜像的方式进行发布，避免产品环境和非生产环境不一致导致发布失败，但是这种发布方式因为笨重而被容器取代。

  • 便于回滚
  • 提高计算资源的利用率：相对以操作系统为计算单元的管理方式，容器不仅更轻量而且极大提高了计算资源的利用率，且容器本身不占用计算资源。而且相对image的方式，管理成本，备份的cost也极大降低
  • 更快的部署时间：image的方式需要一天，snapshot需要十分钟，Container则可以把这个时间缩短到秒级
  • 解决了环境不一致的问题
  • 跨平台
  • prodocut team over project team:每个team可以更方便的管理自己的platform资源，极大地降低了team之间的沟通成本。（相对application team和platfor team分离的情况）

风险：安全，容器必须是以root权限泡在宿主机上，不同容器共享一个宿主机，如果一个容器被贡献则会威胁到所有在改宿主机上的服务。
解决方案：

  • 及时更新宿主机系统版本，避免内核漏洞
  • 扫描bese image, 避免Container本身系统漏洞
  • base image可以加入主动防御（e.g.ossec）
  • 控制好容器操作权限

滚动发布(Rolling Release)

又称滚动更新(rolling update)
指的是在不切换负载均衡器或者DNS的前提下把负载均衡器下的机器一台台关掉，部署好之后再挂到负载均衡器下面，与蓝绿部署直观的差别是不需要切换负载均衡器或DNS，同时做到零宕机部署。（还要完善）

蓝绿部署（BuleGreen Deployment）

在发布之前就把应用程序放在产品环境上部署好，如果“发布”能像重新配置一下路由器那样简单，让他直接指向生产环境，那就更好了 ————《持续交付》
蓝绿部署主要解决的是宕机发布的问题。
它的主要原理是在保持旧版本环境（绿环境）正常运行的情况下，准备一套蓝环境，在产品环境里蓝环境通过充分冒烟测试后再将用户访问从绿环境切换到蓝环境，如果蓝环境在这个切换之后出现问题则立即切换回绿环境，如果没有问题则最后destroy掉绿环境，具体做法可以通过DNS或者ELB配合AutoScaling Group进行Infrastructure的切换，这种切换通常在一秒之内就可以搞定。application层的回话切换以及数据库链接切换的问题，可以使用中间件解决。

对于数据库，直接从绿环境切换到蓝环境是不可能的，因为如果数据库结构发生改变的话，数据迁移需要时间。解决这种情况最理想的方法是在一小段时间把数据库变成只读状态，完成迁移后再将用户切换到蓝环境，恢复读写。如果在切换过程中仍然有数据的写入，你可以采用添加中间件的方式保存读写数据，或者在在读写过程中持续将事物发向新旧两个数据库。

灰度发布（金丝雀发布）

在把应用程序发布给所有人之前，先试着把它发布给一小撮用户群，这种技术叫做金丝雀发布。
金丝雀发布要解决的问题主要是缩短反馈周期，以及弥补巨大产品环境下无法进行有效容量测试所可能导致的问题的一种手段。是一个能大大降低新版本发布风险的方法。
灰度发布是蓝绿部署的一个延伸，采用逐步切换的方式使新版本发布只影响到尽可能少的用户，从而为AB测试提供条件。灰度发布
灰度发布与金丝雀部署在操作上是等价的
金丝雀发有以下几个好处：

  • 非常容易回滚，这个其实是蓝绿部署就已经带来的好处，只要不把用户引向有问题的新版本，就可以有足够的时间用来分析错误日志，排查问题。
  • 可以将同一批用户引至不新旧版本以进行A/B测试，某些公司可以度量新特性的使用率，某些公司可以度量该版本带来的收益，你不必将大量用户引入A/B测试，只需要有代表性的样本就足够了。
  • 可以通过逐渐增加负载，记录并衡量应用程序响应时间，CPU使用率，I/O，内存使用率以及日志中是否有异常报告这种方式来检查应用程序是否满足容量需求，降低容量测试不理想带来的风险。

另外，需要注意的是，在生产环境中保留尽可能少的版本也是非常重要的，最好限制在两个版本之内。

其他

  • 紧急修复：一定不要破坏流程，不要直接对生产环境进行修改。
  • 持续部署：If it hurts, do it more often
  • 持续发布用户自行安装的软件？发布方式？
  • 执行部署的人应该参与部署过程的创建（Dev和Ops的紧密合作）
  • 记录部署活动（自动化更佳）
  • 不要删除旧文件，而是移动到别的位置。在Unix环境中，一个最佳实践是把每个版本部署到不同的文件夹中，创建一个符号链接文件指向最新版本，版本的部署和回滚就只是改一下符号链接这么简单。
  • 部署是整个团队的责任（DevOps）
  • 快速失败，部署脚本也应该纳入测试中，这些测试应该被作为部署的一部分来工作。
  • 数据库最好向前兼容