CI/CD 结合容器或者虚机进行编译部署时，怎么能很好得支持介质传递的部署形式？

题主的问题主要在于：流水线如何做到“一次构建，多次使用”的原则哈。
      按照持续交付理念，软件只需打包一次就可以供后续环节多次使用，这对于代码编译是没有问题的，但是对于一些跟环境相关的配置就无法满足。比如，不同的环境会涉及到不同的配置，如 DB、缓存。而且，其他公共基础服务在不同环境中也会有不同的地址、域名或其他参数配置。所以，我们就需要建立环境与配置之间的对应关系，并保存在配置管理平台中。
这里我们回到打包过程上来。
      在做构建时，我们是可以确认这个软件包是要发布到哪个环境的。比如，按照流程，当前处于线下集成测试环境这个流程环节上，这时只要根据集成测试环境对应的配置项，生成配置文件，然后构建进软件包即可。如果是处于预发环境，那就生成预发环境对应的配置文件。
      在我们的实际场景中，多个环境需要多次打包，这与我们持续交付中只构建一次的理念相悖。这并不是有意违背，而是对于 Java 构建出的交付件，最终无论生成的是 war 包，还是 jar 包，上述提到的跟环境相关的配置文件，是要在构建时就打入软件包中的。而且在后续启动和运行阶段，我们是无法修改已经构建进软件包里的文件及其内容的。这样一来，配置文件无法独立发布，那么就必须跟软件包一起发布。所以，在实际场景下，我们要针对不同环境多次打包。
      那么，我们如何确保多次打包的效果能够和“只构建一次”理念的效果相一致呢？
这就还是要依赖各个环节的建设过程，主要有以下 3 个方面：
      1.代码提交，通过分支提交管理模式，每次构建都以 master 为基线，确保合入的代码是以线上运行代码为基础的。且前面的发布分支代码未上线之前，后续分支不允许进入线上发布环节，确保发布分支在多环境下是同一套代码。
    2.编译环境统一。编译环境通过全新的 Docker 容器环境来保证。
    3.配置管理。通过模板和 auto-config 的配置管理能力，确保多环境配置项和配置值统一管理。
至此，一个完整的软件构建过程就完成了。可以看到，如果充分完善前期的准备工作，在做后期的方案时就会顺畅很多。