本文探讨了持续部署的四个核心要求：准确、可靠的部署结果，部署过程不影响线上服务，可持续部署的软件增量，以及低成本、高效的部署发布。文章详细阐述了如何通过灰度发布和蓝绿部署等策略减少服务中断，并强调了部署可观测性、可干预性和回滚能力的重要性。此外，提出了减小批量、保持顺畅等实践建议，以实现持续部署的规模化落地。
编者按：2022，你的团队距离持续部署还有多远？持续部署这个词我们经常听到，可是到底怎样才是做到了持续部署？如何才能做到持续部署？本文将为你逐层拆解持续部署的内涵和实施路径。
策划&编辑｜雅纯
云研发时代，主流的发布形态变成了服务化的发布形态，这种发布形态让持续发布有了现实的基础。发布的前提是把待发布制品部署到生产环境，所以持续发布的前提是持续部署。
持续部署的4个要求
持续部署要求持续地提供一个稳定可预期的系统服务。有时候发布过程当中会停机，停机更新的这段时间系统不可用，这就是非持续的部署形态。
我们希望的持续部署:
首先应该是准确的——部署结果准确可预期的；
第二，应该是可靠的——整个持续部署过程中线上服务不受影响；
第三，应该是持续的——随着持续部署的发生，有可持续部署的软件增量；
第四，过程成本低——持续部署过程是低成本和高效的。
如何做到这4点呢？
1、准确、可预期的部署结果
准确地部署依赖三个前提：明确的待发布制品及配置、明确的运行环境、明确的发布过程及发布策略。
下面是一个简单的发布示例：
发布首先有明确的image，即上游过来的构建产物。同时包含很多配置，如启动配置、容器的配置等。另一个是环境，我们会在部署工具中配置k8s，这个配置最后会形成一个环境，而这个环境会在DevOps过程中被用到。最后我们把制品和配置发布到这个环境上，就完成了发布。
所以，发布的过程是把制品和配置的集合应用到环境的集合上的过程。首先要有明确的待发布制品和运行环境，其次通过相应的描述，把制品、配置和环境都描述清楚，形成发布的内容，才可以进入下一步。
最简单的发布就是kubectl apply，但这种发布方式存在着一些问题。
第一，结果不确定。kubectl之后pod可能并没有起来，deployment可能是不能用的，服务可能有失败，发布之后可能会遇到pod不够，资源没有，这些都是未知的。所以发布是否成功，发布成功了多少都不确定，这是不可预期的。
第二，状态不可见。发布不是一蹴而就的，是逐步的过程。发了多少，有多少问题，哪些流量已经切过来，这些情况都是未知的。
第三，过程不可控。在这个发布过程中，一条命令下去之后是无法撤回的。
如果版本有问题，有严重的Bug，全部的流量跌零，是无法反悔的，非常危险。所以在真正的发布过程中，我们要有干预手段，比如当我发现流量会导致可用性的大量下降，需要能够马上停止发布。
无论采用何种部署方式，我们都希望尽量减少对线上服务的影响，这种影响降到极致，即部署过程完全不影响线上服务。这是我们的第二个原则。
2、部署过程不影响线上的服务
要做到不影响线上服务，有4个要求：
最低0.47元/天 解锁文章
扫一扫
810
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
