1. 软件私有化交付的场景

1.1. 测试环境与生产环境隔离

一些企业由于内部的流程或安全规范的要求，测试环境与生产环境是隔离的状态。例如运行节点间隔离或网络策略的隔离，甚至是物理上的隔离需要更换设备才能访问生产环境，这时在测试环境测试验证的服务如何上线到生产环境？

1.2. 生产环境禁止访问 Git 执行流水线

代码是企业的核心资产之一，保障源代码的安全是企业重点保障的资产；生产环境一般有自己的机房，或者一些第三方的公有云环境，企业一般不会允许将核心源代码暴露到公网上的，这些情况下生产环境是禁止访问内网的 Git 代码托管平台的。

而且，在生产环境重新执行CI流水线构建的镜像，并不是 QA 团队在测试环境测试回归验证过的镜像，即使他们的源码相同，但本质上是两个镜像。

1.3. 在 Kubernetes 中部署应用时涉及较多类型资源管理问题

在 Kubernetes 集群中部署服务并不是简单的将 Image 镜像运行起来就可以了，实际上还会涉及一些其他相关的 Kubernetes 的资源，例如常见的资源有 Deployment、Service、Ingress、Secret、ConfigMap、PV/PVC、ServiceAccount、RBAC等等以及其他扩展服务的相关资源，如 Prometheus-operator 的 ServiceMonitor。这么多类型的文件该如何维护管理才能高效且不出错呢？

1.4. 应用上线需要符合公司规范

为了保障上线的顺利，符合上线的质量、安全等要求，企业都会对业务上线制定一些流程或者规范。同时，在多人协作的团队中，如果没有一定的规范参考指导，会因为信息不一致导致应用管理混乱。

比如最常见的就是镜像的命名规范，同一个服务可能会出现 myapp:v20211129、myapp:v1.3.11、myapp:1.3.11、myapp:v1.3.11-20211129、my_app:v1.3.11 、my-app:v1.3.11 甚至是 yourapp:v1.3.11 。这些镜像 tag 实际上是指同一个 Git Release v1.13.11 的代码版本，但由于没有规范约束导致管理难，而且容易出错。

1.5. 多部门或子公司开发的产品复用

在企业内部一个部门开发了好的一款优秀的应用，其他部门也希望能够使用这个应用，特别是大型企业有多个子公司时尤为明显。

这类应用例如：日报周报系统、设备日志系统、发票管理系统、ERP系统等等。这时如何将这些应用分享给其他部门会成为一个挑战，如果交付过程太过复杂就会导致推广受限，进而在集团层面产生资源的浪费。

1.6. 软件私有化交付到客户环境

如前文提到的 ERP 系统、网易数帆轻舟平台等，这些 toB 私有化产品在交付时会有很多的困难，如何高效高质量的将交付软件到客户环境成为这类企业核心关注的重点之一。