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

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

您好。

在DevOps整体方案中会有一块是建设制品库。制品库是专门用来存放编译后的制品的。可以解决您所说的问题。

稍微具体点说的话，大致有几个方面。
1、搭建制品库。用于存放各种制品。
2、制品库规划。企业的二方库、三方库、团队研发产生Release制品、非Release制品如何管理。
3、流水线与制品的关系与连接点。流水线如何使用、什么情况下是拉取代码生成制品、什么情况下是用制品库已生成制品去完成后续工作等等。

另外对于您提到的配置项如何管理，我们一般是通过引入配置中心来解决这个问题。如您所说，架构不同、组织要求不同，相应的解决方案也会不同。

个人感觉， 开发 / 测试 / 生产不是不应该同时用一个介质吗 ？  介质可以在image命名时，按照固定的命名方式命名，包含必要的信息，例如  
develop/nginx:#debug_#版本号_#cpu架构_#创建日期_#创建时间_#创建人_#用途
还可以再自动记录到某个配置管理数据库中，数据库中可以记录更多更详细信息，对外提供查询接口。