领先一步
VMware 提供培训和认证,助您加速进步。
了解更多Spring Cloud Pipelines是一个GitHub项目,旨在解决以下问题:
创建通用的部署流水线
推广良好的测试和部署实践
减少将功能部署到生产环境所需的时间。
第一次提交发生在2016年8月31日。从那时起,我们收到了社区对建议的部署流水线及其具体可视化的许多反馈。在这两年中,我们成功构建的最重要的功能包括:
主观的部署流水线设置
用于流水线的脚本,以验证项目的向后兼容性并允许零停机部署
支持PHP、.NET、NodeJS和JVM(Maven & Gradle)项目
Cloud Foundry的部署选项
Kubernetes的部署选项
通过Ansible的部署选项
使用Jenkins Job DSL在Jenkins中进行流水线可视化
使用Jenkinsfile在Jenkins中进行流水线可视化
在Concourse中进行流水线可视化
我们很高兴地宣布 Spring Cloud Pipelines 的下一个版本 1.0.0.M9 将发布,这也是其当前形式的最后一个版本。
作为 Spring Cloud 团队的成员,我们决定将其纳入 Spring Cloud 旗下。除此之外,该项目与 Spring Cloud 没有任何关系,更不用说一般的 Spring 了。
因此,我们决定将项目拆分成多个部分,并对其进行重命名,并将其放入一个单独的 GitHub 组织中。
Spring Cloud Pipelines 有了一个新家和新名字。该项目现在位于 GitHub 的 Cloud Pipelines 组织下。因此,该项目被拆分成以下几个部分:
Scripts:包含部署管道的核心逻辑。你可以将此仓库称为 recipes。每个 recipe 包含部署管道的一个步骤。文档在此。
Project Crawler:对从仓库管理服务中获取数据的抽象。
Pipeline Base:CI 服务器使用的 Docker 基础镜像。
在将项目迁移到新组织后,我们决定将其标记为功能完备。我们已经使用 Spinnaker 一段时间了,并计划投入资源,使 Cloud Pipelines 的回滚测试和契约测试 recipe 能够在 Spinnaker 上运行。对于部署策略等其他重叠领域,我们希望依赖 Spinnaker 的抽象。当然,我们将促进围绕项目的任何讨论以及与问题、拉取请求和发布相关的任务,但我们可以肯定地说,该项目将完全由社区驱动和维护。
如果您有兴趣将您的项目从 Spring Cloud Pipelines 迁移到 Cloud Pipelines,您应该查看迁移指南:
Spinnaker 是一个开源多云持续交付平台,最初由 Netflix 启动,但现在涉及来自 Google、Amazon、Pivotal 和许多其他公司的更广泛的贡献者社区。Spring 团队和 Pivotal Cloud R&D 的共同努力,使得 Spinnaker 支持 Cloud Foundry。
Spinnaker 让我们能够访问更广泛的受支持云提供商,而无需重新发明这些交互。
Cloud Pipelines 在零停机部署和回滚测试方面的工作揭示了 Spinnaker 这样持续交付平台的关键价值,即独立维护已部署环境中资产的清单。
在 Cloud Pipelines 中,当前生产系统状态未被存储。为了缓解这个问题,我们使用 Git 标签来存储状态。然而,当进行手动部署或回滚时,这很容易被破坏。此外,生产系统状态可能跨越多个版本(跨云提供商或区域),并且通常无法简化为可以存储在标签中的单个值。例如,执行回滚测试的 Spinnaker 管道可以自由地利用 Spinnaker 对系统状态的了解,将回滚测试情境化到目标区域的生产版本,而相互独立。
Cloud Pipelines 中提供的部署选项是有限的。Spinnaker 将蓝绿部署、滚动推送、零停机和自动化金丝雀分析部署功能推广到一系列受支持的云提供商。
更具体地说,考虑蓝绿部署。Spinnaker 支持蓝绿部署,同时维护任意数量的先前版本服务器组。从下面示例中的应用程序当前版本,您只需一个操作即可回滚到多个版本之前的应用程序版本。在任何时候,我们都可以选择销毁 V022,

从而使其无法回滚。这样的事情可能发生在部署活动之外(例如释放容量),使得无状态系统更难应对变化。
我们欢迎您以各种形式提供意见。如果您对 Spinnaker 有疑问,请在 Stack Overflow 上提问并使用 #spinnaker 标签。对于 Cloud Pipelines,请在 GitHub 上提问。如果您想参与代码工作,我们非常欢迎拉取请求。如果您发现问题,请在 Github 上提交问题。