1.部署行为是系统生命的重要组成部分
1.1.只编写代码是不够的，只要没有在生产环境中运行，一切都不算完成
1.2.要想取得成功，需要早早地频繁部署软件
1.3.设计易于部署的软件非常有必要
1.4.零停机部署就是目标
2.机器与服务
2.1.机器是可配置的操作系统实例
2.1.1.如果系统在真正的机器上运行，那么这就意味着物理主机
2.1.2.如果系统在虚拟机、容器或unikrnl上运行，那么这些就是单元
2.2.服务是供其他系统使用的可调用接口
2.2.1.由在多台机器上运行的软件的冗余副本组成
2.3.我们的环境拥有比以往更多的机器，而且大部分都是虚拟的
2.4.有些机器是其他机器创建的，所以运维人员从未接触
3.计划停机时间的谬误
3.1.不能计划一次或几次就完成部署，而应该每次一点逐步叠加地进行多次部署
3.2.更新系统的过程需要花费时间
3.3.要将部署视为软件的一个特性
3.3.1.不能只为了最终状态而编写代码，然后将代码交给运维部门，让他们搞清如何在生产环境中运行这些程序
4.自动化部署
4.1.构建流水线
4.1.1.将代码变更提交到版本控制系统后，构建流水线就会启动
4.1.2.产品
4.1.2.1.Jnkins可能是如今最常用的工具
4.1.2.2.ThoughtWorks的GoCD
4.1.2.3.Ntflix公司的Spinnakr
4.1.2.4.亚马逊的AWSCodPiplin
4.2.不要试图去找最好的工具，而应该选择一个足够满足需要的，然后好好加以利用
4.3.由于服务可以在具有不同IP地址的任意数量的不同机器上运行，因此平台还必须配置网络，实现负载均衡和流量路由
4.4.如果使用不可变的基础设施，那么一般从基本的操作系统镜像开始部署
4.4.1.此时并不是试图从未知状态收敛到预期状态
4.4.2.始终从已知状态——主操作系统镜像——开始
4.5.不可变的基础设施与IaaS、PaaS以及自动化映射是高度一致的
4.6.状态收敛在物理机器部署、长寿命虚拟机器和手动映射中则更为常见
5.持续部署
5.1.未部署的代码
5.1.1.未完成的库存
5.1.2.有着未知的缺陷
5.1.3.会令容量扩展失效
5.1.4.会导致生产环境出问题
5.1.5.也可能很好地实现一个没人想要的功能
5.2.从开发人员向代码库提交代码到代码最终在生产环境中运行，这段时间的代码最为棘手
5.2.1.持续部署就是尽可能地缩短上述时间段，尽可能地减少未部署代码引发的问题
5.3.持续不间断地部署所有代码
5.3.1.意味着每次提交代码，都要运行完整的构建流水线
5.4.如果放慢软件发布进度耗费的成本，超过部署软件中弥补错误需要的成本，那么通过流水线自动将代码部署到生产环境更合适
5.5.由代码错误造成的成本，可能会远远大于在竞争中较慢地发布软件的成本，此时在部署到生产环境之前进行人工检查更为合理
5.5.1.要确保掌管授权按钮的人能随时待命
6.部署中的各个阶段
6.1.部署PHP应用程序，就是简单地把文件复制到生产主机上，然后下一个访问该主机的请求就会访问这些新文件
6.1.1.当请求访问尚未完成复制的文件时，该如何处理
6.2.相比复制软件包文件并重新启动应用程序容器，复制没有运行时进程的单个文件速度更快
6.3.粒度越大，安装和激活软件所需的时间就越长
6.4.微观时间尺度适用于单个实例（主机、虚拟机或容器）
6.5.宏观时间尺度适用于这个版本的整体推送
6.6.对于可变的基础设施，这意味着将文件复制到位，从而能够快速更新符号链接或目录引用
6.7.对于不可变的基础设施，这就是部署新镜像所需的时间
6.8.会话可以保持活动的时间长度可以没有上限，特别是当你无法区分访问者是人类还是机器人或网络爬虫的时候，尤其如此
6.9.一旦将部署视为一段时间内的工作，就可以让应用程序协助完成自身的部署
7.关系数据库模式
7.1.完全安全的数据库模式的变更是
7.1.1.添加一个表格
7.1.2.添加视图
7.1.3.在表中添加一个可空列
7.1.4.添加别名或同义词
7.1.5.添加新的存储过程
7.1.6.添加触发器
7.1.7.将现有数据复制到新的表格或列中
7.1.8.数据库模式变更的扩充阶段
7.1.8.1.当前应用程序不会使用这些变更中的任何内容
7.2.垫片
7.2.1.一些有助于连接应用程序旧版本和新版本的代码
7.3.对测试来说，除了支持前滚，最好也要支持回滚
7.4.不要忘记在真实的数据样本上测试数据库的模式变更
7.5.测试时绝对不要依赖应用程序当前所谓的合法数据库模式
7.5.1.会有用户最近10年从未登录过，所以现在必填的一些字段对他们来说就是一堆空值
7.6.总会存在一些当前的应用程序绝对无法生成的数据，这就是必须要针对真实生产数据的副本进行测试的原因
8.无模式数据库
8.1.对数据库引擎而言，无模式数据库仅仅无模式而已，但对应用程序来说，就完全是另一回事了
8.2.随着时间的推移，应用程序很有可能也在不断演化，原来旧版本的数据文档现在可能都不可读了
8.2.1.编写应用程序，使其能够读取任何时间创建的版本
8.2.1.1.所有版本之间的转换都必须经过测试，这意味着需要保留旧文档作为测试的种子数据
8.2.1.2.随着流水线越来越深，翻译时间会线性增加
8.2.2.编写部署期间在整个数据库运行的迁移例程
8.2.2.1.旧实例读取旧文档，没问题
8.2.2.2.新实例读取旧文档，没问题
8.2.2.3.新实例读取新文档，没问题
8.2.2.4.旧实例读取新文档，会出大问题
8.2.3.先滴流再批量
8.2.3.1.这个策略不会对所有文档进行一次大规模的迁移
8.2.3.2.通过在应用程序新版本中添加一些条件码，迁移运行过程中涉及的那些文档
8.2.3.3.在生产环境实行了一段时间的“先滴流再批量”之后，就会发现最活跃的文档都已更新
8.2.3.4.此时就可以对其余文档执行批量迁移，这可以与生产环境同时运行，不会产生危险，因为此时没有旧实例参与
8.2.3.5.优点
8.2.3.5.1.能实现快速部署新的应用程序版本，无须停机进行数据迁移
8.2.3.5.2.能在不中断服务的情况下部署代码，因此当不再需要迁移测试时，能够将其删除
8.2.3.6.缺点
8.2.3.6.1.不能对相同的文档类型执行不同的重复滴流迁移操作
8.2.3.6.2.当面对一些较大的设计变更时，需要将其分散到多个版本中来实现
8.2.3.7.对于任何大型迁移——通常在部署过程中执行时间很长——都可以采用这种方法
9.让人类定义规则，让机器贯彻规则
9.1.实现自动化操作和质量检查
9.2.运维工作与开发工作已经变得难解难分，这就要求必须按照可部署的原则设计软件，就像设计用于生产环境的软件一样
10.Wb资源
10.1.缓存破坏（cach-busting）
10.1.1.能够帮助浏览器、所有中间代理和缓存服务器获取最新的静态资源
10.2.版本控制
10.2.1.Git生成的SHA值作为版本标识符
10.3.会话黏性
11.推出新代码
11.1.“收敛”式基础设施
11.1.1.这种基础设施使用长寿命的机器，并由这些机器接受变更
11.1.2.决定每次要更新的机器数量
11.1.3.“金丝雀”组
11.1.4.要阻止流量发往机器，一种简单的方法就是将其从负载均衡器池中移除
11.1.5.通过健康状况检查，应用程序中一个简单的状态变更，就可以通知负载均衡器不再向该机器发送任何新请求，该机器正在处理的请求会继续完成
11.2."不可变”的基础设施
11.2.1.要针对新版本的代码启用新机器
11.2.2.随着新机器不断出现且通过了健康状况检查，它们将开始承担流量负载，这意味着需要实现会话黏性，否则某个调用方后续发来的请求，就可能不得不交给新版本机器（而不是旧版本机器）来处理
11.3.如果部署非常频繁，那么最好是在现有集群中启用新机器，这样做可以避免打断正在处理的连接
11.4.在所有的模式下，机器上的内存会话数据都会发生丢失，必须让用户了解到这一点
12.清理
12.1.如果工具用完后没有归位，那么工作不能算完成
12.2.去除垫片
12.2.1.一旦每个实例都部署了新代码，就不再需要那些触发器了，那时就可以删除它们
12.2.2.对于新的数据库迁移，务必最后要执行这样的删除操作
12.3.收缩（contraction），或“收紧”数据库模式
12.3.1.撤销旧表
12.3.2.撤销旧视图
12.3.3.撤销旧列
12.3.4.撤销不再使用的别名和近义词
12.3.5.撤销不再被调用的存储过程
12.3.6.在新列上应用非空约束
12.3.7.应用外键约束
12.4.清理阶段也是审查特征切换的好时机
12.4.1.任何新的特征切换都应默认设置为“关闭”
转载请注明：http://www.0431gb208.com/sjszlfa/7232.html
