持续交付管道实现全面自动化
时间：2022-04-19 13:18:01 | 来源：行业动态
时间：2022-04-19 13:18:01 来源：行业动态
为了达成这些目标，我们需要为部署在OpenShift中的应用程序定义所有权与支持模式。实际上，如果开发团队希望以自助方式管理基础设施，那又该由谁来提供技术支持？在观察谷歌、Netflix以及Spotify的业务体系后，我们发布了一套模型，其中由交付团队负责管理所需的基础设施（即在容器中添加的内容），而运营团队则负责保持OpenShift稳定可用很明显，一切业务服务的可用性，都将直接由底层OpenShift的可用性所决定。此外，为了保证所有权明确清晰，我们决定将特定项目的OpenShift配置文件同项目的其余源代码统一起来。
我们采用以下逻辑在Jenkins中建立了一个流程：
每十分钟，源代码repo会接受一次轮询；一旦出现任何变更，则触发新的build。
此build将运行单元测试以及创建项目Docker镜像所需要的其他一系列操作步骤。完成之后，此Docker镜像永远不会进行后续变更。这也是我们实现不变基础设施的核心要点之一。
在解决方案的每个层上单独进行一系列集成测试。通过隔离，我们可以模拟出依赖项。以此为基础，我们即可脱离下游依赖项的可用性与测试数据质量，单独运行一系列测试。这些测试将在临时环境中运行，这一点在OpenShift中并不难做到。
在IT环境中运行一系列集成测试。
我们每天在QA环境上部署一次之前成功完成测试的build。QA环境用于手动探索性测试以及手动（后续计划改为自动）负载测试。
最后一步则是每周在生产预览环境中进行一次部署。这一步需要人工核准。
在生产环境中部署需要KeyBank的多次批准。这些批准以会议形式完成，即人们展示将部署的内容，而高级领导者签署发布命令。这个过程不适合我们，因为我们没有足够的时间每周举行三次会议（的确，这需要三个不同部门确信发布版本的合理性）。我们可以改变这样的流程，并且同意：
在线咨询
