2同行回答
CI/CD工具主要是进行代码的扫描、打包、QA部署、QA（自动）测试、（准）生产部署等。有一定并发性能要求及状态可视化要。
一般开源方案以jenkins为主，通过Pipeline调用各自插件或shell脚本进行对应工作。商业方案也主要涉及以上思路。
接口和插件层面，docker/K8S/OCP之类平台，对于jenkins都有开源插件实现，支持应用的部署等行为。
由于这类平台本身基于restful API，同时可以通过shell直接调用restful API或原生client（如k8s的kubectl，OCP的oc）实现。
当然通过上述API，也可根据需要开放自定义简化API。
持续交付之所以困难，不仅仅是在技术上，更主要在制度上。特别是我们这种金融企业，对变更非常谨慎，审核非常严格。并且我们的开发测试环境跟生产环境在网络上是隔离的，这就进一步增加了版本从开发测试环境交付到生产环境的难度。因为这些原因，我们必须设计一套完整、成熟、经得住推敲的持续交付流程，才能够说服质量监督和生产安全部门在企业内部推行持续交付。
基于PaaS的持续交付，其实就是两样东西在三套环境之间的同步。三套环境很好理解，就是开发环境、测试环境、生产环境。有些公司可能还有预投产环境。两样东西指的是镜像仓库里的镜像，策略仓库里的容器编排策略。我们企业内部的镜像仓库使用的是VMware提供的开源企业级镜像仓库Harbor。Harbor提供了镜像的同步策略配置，可以很好地帮助我们实现镜像仓库之间的同步。对于容器编排策略的同步，我们使用自研的PaaS云管理控制台来完成不同环境之间的策略同步。当开发环境发起策略同步申请到测试环境时，开发环境的管理控制台会将编排策略导出一个zip包，以FTP的形式上传到测试环境管理控制台，并给相应的测试人员发送通知邮件。测试人员登录测试环境管理控制台后，首先将策略包导入，之后进行审核以及修改参数等等，审核通过后，就可以一键在测试环境部署这个容器编排策略。如果这个策略之前在测试环境已经存在，本次只是对原有策略的更新，那么管理控制台会比较本次提交的策略和已有策略的不同，并将不同之处提示给测试人员。并且在这种情况下，运行这个策略的时候，在K8S集群里面就不是创建一个Deployment，而是基于原有的Deployment进行Rolling Update。
对于生产环境，根据制度的需要，我们采用了双人复核的机制。当策略包由测试环境提交到生产环境的管理控制台以后，首先由QA人员审核，QA审核通过后，就意味着发布版本，之后再由运维人员复核，并修改相应的生产参数，审核通过后，就可以部署运行。同样如果提交部署的策略已经存在，为了保证生产上运行的应用服务不间断，在K8S集群里面就不是创建一个Deployment，而是基于原有的Deployment进行Rolling Update。