许多组织都在努力发布他们的应用程序，而这场斗争催生了一个旨在简化流程的工具行业。发布管理工具允许将发布过程定义为管道中的阶段，并且阶段本身包含在下一个开始之前要执行的顺序步骤。使用审批门对阶段进行分段，以确保 QA 和发布经理对工件是否已准备好进入发布管道的下一阶段拥有最终决定权，并且跟踪整个过程以进行报告。
此类流程的目标是确保只有高质量的版本才能部署到生产环境中并按时发布，而发布经理对这一切负责。
顺利发布的障碍是维护相同测试和生产环境的结构性挑战。当这些环境不同时，它允许意外的回归有机会通过测试和拙劣的发布。理想情况下，所有环境都是相同的，并且包含相同的依赖库和应用程序工具，以及相同的网络配置。
什么是码头工人？
Docker 是一个开源项目，它提供了一个使用容器构建和传输应用程序的平台。该平台使开发人员能够轻松创建标准化环境，确保测试环境与生产环境相同，并为虚拟化应用程序提供轻量级解决方案。
Docker 容器是由应用程序及其依赖项组成的轻量级运行时环境。这些容器在机器的“金属”上运行，从而避免了与传统虚拟化技术相关的 1-5% 的 CPU 开销和 5-10% 的内存开销。它们也可以从称为 Docker 映像的只读模板创建。
Docker 映像可以从称为 Dockerfile 的环境定义或已作为映像提交的正在运行的 Docker 容器创建。一旦 Docker 镜像存在，它就可以被推送到像 Docker Hub 这样的注册表，并且可以从该镜像创建一个容器，创建一个运行时环境，其中安装了一组有保证的工具和应用程序。同样，容器可以提交到镜像，然后再提交到 Docker Hub。
千篇一律的环境和应用程序打包 Docker 的多功能性和可用性使其成为 DevOps 驱动型组织的热门选择。它还使 Docker 成为创建标准化和可重复环境的理想选择，组织需要这些环境来创建相同的测试和生产环境以及打包可移植应用程序。
如果应用程序打包在 Docker 镜像中，测试和部署就是从该镜像创建容器并针对内部应用程序运行测试。如果应用程序通过了测试，那么它们应该存储在注册表中并最终部署到生产环境中。
自动化发布 根据 Forrester Research 的说法，发布管理的最大痛点是缺乏对发布管理流程的可见性以及他们的流程缺乏自动化。
但是，这些管道的测试、部署和发布阶段可以由 Jenkins 使用
CloudBees Docker 构建和发布插件
进行编排。这个插件创建了一个新的构建步骤，用于将应用程序构建和打包到 Docker 容器中，并将它们发布到私有和公共 Docker 注册表（如 Docker Hub）中。
测试和 QA 打包在 Docker 镜像中的应用程序可以通过将它们作为容器运行来进行测试。 Docker 允许链接容器，授予链接的容器 shell 访问权限并允许它针对应用程序的容器运行脚本。此链接也可以在 Docker 应用程序容器和另一个容器之间建立，该容器正在打包应用程序需要运行以进行真正的集成测试的服务，例如测试数据库。
提升和发布 Jenkins 支持提升的概念，其中经过测试和批准的工件被提升到管道中的下一阶段。促销与传统的 Jenkins 工作和新的 Jenkins Workflow 兼容，促销可以设置为仅在特定用户或团队成员手动批准时触发。
在这种情况下，工件是一个包含我们应用程序的 Docker 映像，一旦它被提升，它就可以手动或自动移动到其管道的下一阶段。下一阶段的范围可以从预生产暂存区到 Docker Hub 等注册表，其中提升的映像被称为准备部署的“黄金”映像。
促销还可以触发任何其他数量的预发布操作，例如通知和将有关工件的数据发送到公司仪表板。
我从哪说起呢？
- CloudBees Docker 构建和发布插件 是一个开源插件，因此可以从开源更新中心下载或打包为 CloudBees Jenkins 平台的一部分。
- 更多信息可以在新发布的 Jenkins Cookbook 中找到
- 其他插件补充和增强了 Docker 与 Jenkins 一起使用的方式。在这些博客中详细了解他们的用例：
- Docker Slaves 与 CloudBees Jenkins 平台
- Jenkins Docker 工作流 DSL
- Docker 可追溯性
- Docker Hub 触发器插件
- Docker 自定义构建环境插件