前言
在较短的时间内完成从开发人员的机器到生产的功能的代码, 是高效的技术 / 工程团队的质量. 使用 http://capistranorb.com/ 或 fabric http://fabfile.org/ 等工具进行自动部署使得部署成为一项简单的任务, 而不是可怕的操作, 在这种情况下, 您错过了一步, 然后搞砸了生产.
这些天 Docker https://docker.com/ 和 Kubernetes https://kubernetes.io/ 使部署变得轻而易举. 本文将重点介绍在部署涉及一些重要代码和数据库更改的新主要功能时要考虑的事项.
什么是主要特征
如何区分常规和主要功能部署? 例如, 如果您在电子商务网站中部署客户钱包子系统, 或者将多租户功能部署到单个租户应用程序, 则应将其视为正在推出的主要功能.
常规功能不需要事先推出计划或大量思考, 可以通过运行常规部署例程进行部署, 也可以. 主要特征是在常规功能和错误中的一种子项目. 部署重要功能是开发, sys admin / devops 和产品团队的共同责任.
TLDR;
在使用新的主要功能上线 / 制作之前, 始终严格按照分段进行测试. 进行数据库备份并通过向后兼容性进行小型部署. 始终具有回滚计划并将功能保留在功能标记下.
要考虑的事情
那么, 当您想要部署团队已完成开发并希望继续使用它的新主要功能时, 您需要考虑哪些事项?
在进行主要部署之前, 您应该制作一份清单, 其中包括大代码更改和迁移时的一些数据库架构更改:
1. 严格的分期测试
这是一个明智的选择, 您必须在暂存环境中严格测试新功能, 并确保涵盖不同的用例. 我甚至建议有一个表格, 列出可能的情况并测试它.
如果您有质量保证 (QA) 部门, 您肯定可以就此事采取帮助.
开发人员级别的测试也非常重要, 找到一个关于暂存和修复它的错误要比上线并进行回滚要少得多.
您可能需要回滚, 因为在生产中发现了重大错误. 这是你不想遇见的情况. 问题是如果它是发布就绪, 或者如果测试时间太长, 它可能会延迟发布.
2. 始终进行数据库备份
在对生产数据库进行任何更改之前, 进行备份是您需要做的最重要的事情. 如果你忘了, 将是一场灾难, 虽然这只是一件小事.
当你没有得到正确的基础时, 问题会变成更大的问题.
因此, 请注意并始终在运行这些迁移 / 更改查询之前进行数据库备份. 另请注意, 部署脚本不会自动运行迁移. 这可能使主要功能部署过程变得痛苦, 从而始终为困难情况做好准备.
3. 小型多重部署, 保持向后兼容性
当您必须将一个主要功能部署到生产中时, 最好在生产中进行所需的数据库更改, 这是完全向后兼容的.
您可以在生产数据库上完成 alter table 和 new columns. 这有助于您将主要功能拆分为较小的部分并逐步部署它们.
这为团队提供了灵活性和信心, 可以使用新功能继续进行生产. 如果您可以正确地玩牌, 这可以是零停机部署的推动者.
4. 不要忘记回滚计划
如果您计划执行一个主要部署以发布主要功能, 请制定推出计划. 它详细说明了如何使用适当的步骤执行部署, 详细说明了部署策略.
即使您认为推出 / 部署将会成功, 也总会有回滚计划.
列出您需要回滚到应用程序的当前工作版本所需的内容, 以防万一事情没有按计划进行, 您需要还原. 如果您有可以快速修复的小问题, 则无需回滚, 但如果存在重大问题, 那么回滚将是唯一的出路.
5. 基于条件的特征
最后但也很重要的一点是, 如果您要部署一个主要功能, 尽早访问您的公司员工 (或公司内部的一个团队) 是一个好的选择.
就像该功能可以由产品团队在生产中进行测试.
现在的情况? 当用户使用 @ yourcompnay.com 电子邮件地址登录时, 只需限制要执行的功能代码即可. 一次我记得我们就推出了一种只有在您使用一个特定电子邮件地址时才会显示的付款方式. 因此, 主要功能可以部署到生产中, 并且仍然具有过滤访问权限. 在相关团队发出绿灯后, 您只需删除访问该功能的条件, 并将其提供给所有客户 / 用户.
结论
至于适用的目标是零停机时间部署, 并在流量最低时在生产中运行数据库迁移脚本. 即使您必须有停机时间, 也要确保事先尽量减少停机时间, 以便系统可以在最短的时间内进行定期维护. 快速部署.
来源: http://www.jianshu.com/p/727535eee905