教您如何构建自己的 DevOps 流水线（三）
本帖最后由 adminlily 于 2018-11-7 16:24 编辑[*]Part 1：关于持续交付
[*]Part 2：目标
[*]Part 3：预备步骤
[*]Part 4：实现持续交付流水线
[*]Part 5：持续交付最佳实践及其他
05持续交付最佳实践
一旦基础就绪并建立好交付流水线，你很可能已经从迭代时间以及快速发布中收益。
自动化会取代很多人工任务，环境和发布会变的一致，发布候选者将使用自动路由和自助服务工具在各个流水线阶段中流动。
你的软件应该近似于时刻处在生产就绪状态，伴随着发布候选人最后从流水线出来的频率远大于从传统途径的频率。每个发布候选者应该增加一批相对较小的改动。
一旦你处于这个阶段，那么你会有更多机会去提升和推进更快的发布周期，而这会使得系统的稳定性更强。
下面列举了一些最佳实践：
实施监控
尽管这份文档讨论的所有事情是描述一个严格的过程去帮助你避免在发布产品的时候出现 bug，但是一旦发布结果显示出系统出现了某种故障，那么收到告急同样显得非常重要。
举个例子，如果你的应用在部署结束之后开始抛出告警和异常，那么被直接告之就显得极其重要，这意味着你可以调查和结局。
理想情况下，这种警示将会以仪表盘或者监控终端的途径传递，比如邮件，文本消息，Slack，或者功能类似的其他途径。
你可能会需要更加深入而不仅仅是简单的检查错误日志，并且开始监视应用程序正在打印出的日志。
比如，如果你的 完成了在一个发布后下降了 20%，这预示着上一个发布中，可能存在着一个微妙但是非常严重的错误。诸如 StatsD 和 Graphite 之类的开源工具以及通信和浏览分析工具 Google Analytics 会在此帮助到你。
同样的，这些指标应该在可能的情况下加入到你的监视和警告的仪表盘当中。
有许多有价值的开源和商业工具可以帮助你智能的去监控你的应用。这些都是值得评估作为一个快速和符合成本效益的手段，支持你的持续交付项目。
目标:
为了实时监控你的应用，最理想的方法应该是通过可视化的仪表盘
追踪应用的关键度量，如果部署出现负面的影响就使其发出警报
实现回滚
使你的生产环境具备快速可靠的回滚是最后的安全网。
如果一个 bug 在你的所有手动和自动的测试中通过，那么回滚将使应用在许多用户受到影响之前快速回到之前可用版本。
伴随着一个优秀的回滚途径带来的益处，你将在自动交付流水线和打开各个阶段之间的大门变得更加有野心。
这种信心会带来更快速度的发布，在发布流程中加入自动化会让你变得更有信心。
如果发布流水线实现的非常好，你应该不用花费额外代价就能得到这种回滚能力。如果版本9发生了故障，部署版本8就好了，它应该同样可用，所有签署和准备重新部署在您的流水线末端。
目标:
为快速重复的回滚任何软件提供一种机制
将其构建在流水线流程中，以减少开发者显示的为回滚编码
定义的去测试你的回滚机制，作为测试流水线的一部分，以保持你对流程的信心
提取特异于环境的配置
在流水线中正确并且一致的去使用二进制包和产品是很重要的。如果 QA 和 UAT 在开展工作的过程中不同的二进制包，那么你的测试完全是无效的。
基于这个理由，你需要获得将同样的应用二进制包推进任意环境的能力，接着分开发布环境特异的配置。这种配置应该像其他任何代码一样进行版本控制，这使得你获得更多的复用和更好的审计。
确实，这样做最大的阻碍是拥有环境特异的配置会和实际的二进制包紧密的耦合在一起。
将这些环境特异的配置提取出来，放到额外的属性文件或者其它配置源会使你获得对待此类阻碍更大的敏捷性。
目标:
在你的交付流水线中使用同样的二进制包，避免重新构建源或者以任何方式处理二进制文件，即便你觉得这样做是安全的
将环境特异的信息提取到版本控制的配置，这会使其从主要的发布产品中分开
执行金丝雀发布
一个增加产品环境稳定性的有用的技术是金丝雀发布。这个概念涉及到将你的软件的下个版本发布到生产中，但是只将其 给你的用户的一小部分。这可以实现，例如，使用一个负载均衡器仅仅将一小部分比例的信号量定向到新的版本。
尽管我们的目的从来都不是将任何 bug 引入到生产环境中，很明显，你更愿意将大部分用户与任何问题隔离起来。
当你在发布过程中建立了信心，随后你可以增加新版本对用户的 的数量，知道完全取代旧版本。
金丝雀发布在持续交付的一个重大的胜利，但它需要更多额外的工作和应用架构上的变化。
目标:
进行金丝雀发布，同时不影响生产版本被用户正常使用
捕捉构建审计信息
理想情况下，你的持续发布流水线应该会给你带来一个清晰的途径，关于每个发布候选者的变更。手动测试可以特定的去关注改变过的区域，在你知道每个发布的实际范围后你会更有自信的前进。
通过在持续集成服务器上集成问题追踪软件诸如 Jira 和 Pivotal Tracker，你可以开发高度自动化的系统发，发布说明可以被构建和链接回到个别问题或缺陷。
你应该确保为了可追踪性和可调查性去捕捉被发布到某个环境的所有二进制文件，仓库管理工具诸如 Nexus 和 Artifactory 在此非常有用。也有很大一批工具，作为容器镜像作为专门的登记。
目标:
集成问题追踪软件或者变更管理软件将会为每个发布候选着定位到详细的问题审计信息
变更控制所有相关的代码以及归档所有发布过的二进制文件
实现功能开关
功能开关是一个开发者构建进软件的设施，以获得在一个较高水准的粒度上切换不同特性的能力。这项简单的技术可以通过加大控制如何使新的特性投入生产使用以增加系统的可靠性。
一个优秀的功能开关将会：
[*]在运行时被管理而不需要重启或者中断用户
[*]良好测试，这意味着你应该确保你的测试覆盖了所有你将要计划在生产使用的新特性的组合
[*]运行时识别，允许你识别哪个特性在什么场景下被激活，以及他们与系统用量之间的关系
简单的特性标志可能看上去会简单的构建自己。你可能会喜欢快速发现，然而，你的功能开关实现所需的功能数量迅速扩展：历史比较，审计跟踪和基于角色的访问控制的名称，但是不多。
目标:
实施功能开关，充分了解对质量检查和生产操作的影响
使用基于云和管理的基础设施
在这篇文章的多个地方，很多云和基础管理提供商被提及。这是因为他们代表了一种快速和成本效益的方式，加快您的持续交付成功。
云和管理基础设施即服务在支持在构建和发布基础设施时有诸多需求的团队时显得格外有用。比如你可能会发现在你进行发布时，你需要暂时提升你的容量。
云和自动化基础设施管理的结合是处理 CI 中的变化理想选择。基于这个理由，云托管业务诸如DaoCloud Services，DEV@cloud、Travis CI、CircleCi 是外包您的持续交付基础设施的理想候选人。
目标:
减少基础设施管理投入，并通过部署到云或基础设施服务使其支持变化的需求
06检查列表
基础原理 - 发布自动化：
自动化构建和打包
自动化持续集成
自动化测试
自动化部署
受管理的基础架构和云
基础架构即代码
容器框架
自动化生产部署
实现一个持续交付流水线
流水线建模
识别非自动化的活动和网关
实现流水线
最佳实践
实现监测
实现回滚
提取特定于环境的配置（配置与代码分离）
执行金丝雀发布
记录审计信息
实现功能开关
使用基于云的基础架构
原创： 云原生转型实验室
页:
[1]