由于银行行业的特殊性，无法直接通过公司的saas营销系统进行营销的推广，想让公司在其服务器上，部署一套属于银行自己的saas营销系统，并提供定制化需求，经过2021年一整年的实践，部署的过程出现了很多问题，总结了部分如下
问题
- 部署是基于代码部署的，每次都从最新的分支上打基线tag，然后做代码交付，导致每次部署都需要重新拉取代码，构建，打镜像，在部署到甲方的k8s集群
- 自动化安装脚本缺失，每次部署，都需要根据甲方的特殊环境进行调整，尤其是网络方面，安装基础的中间件时间耗费过长
- 部署脚本（数据库初始化sql，es的索引mapping等），都需要从标准化的环境上，手动导出一份新的，进行部署，容易存在漏刷脚本的问题
- 配置杂乱且过多，由于之前配置管理不规范，导致存在大量的配置，而这些配置都是针对标准化的系统，移植到私有化系统后，虽然有专门的脚本进行配置替换，但是比较简陋，容易存在漏替换，替换错误等问题，导致系统存在隐藏bug
- 系统升级繁琐，标准化迭代的功能由于和私有化定制的迭代功能并行开发，而各方拉取的起始分支不同，不管是哪方的功能想给另一方复用，只能进行代码的拷贝，容易存在不兼容的风险，同时会对已经上线的逻辑造成不可控的影响
devops1.0
到2021年底，由于交付的项目，大部分不达标，存在交付质量差，时间长的问题，架构大佬开始考虑使用devops来进行管理 正常大家理解的devops，主要是通过CICD的过程，减少运维和开发的边界，市面上大部分的devops平台，也基本上是提供CICD为主，同时提供一些项目的管理，代码的托管和部分安全扫描的功能 由于这些devops暂时无法解决当前部署的痛点，所以决定先自己开发一个适合自己公司的devops平台
解决问题一：交付方式改变
公司决定用制品交付的方式，替代传统的代码交付的方式 后端使用dubbo进行微服务的调用，部署过程使用docker镜像部署，所以暂定为使用标准化迭代过程中的镜像作为交付的制品
解决问题二：标准化上线清单维护
每次标准化的迭代，都录入devops的上线清单，并递增版本号，上线清单关联本次迭代的需求清单，对于的脚本和服务列表及对应的制品（制品定时从harbor仓库定时拉取），发布生产环境时，根据填入devops生成的版本号对镜像打tag，每次上线完成后，开发人员手动关联对应的tag的制品到服务列表中，由此通过上线清单，将迭代的需求，脚本和服务列表及服务对应的制品，进行关联
解决问题三：基线管理
每次私有化全量发布时，根据通过devops，创建新的基线（基线tag）和对应的甲方信息进行关联，拉取所有服务制品和拉取mysql初始化脚本，es索引脚本等，生成对应的基线tag.zip包，同时对当前所有的服务，打上对应的基线tag，方便后续定制化开发和代码问题追溯
解决问题三：配置替换管理
项目中的配置放在apollo中进行管理，针对项目中的配置，梳理出具体的配置模板，并抽取出对应的占位符，提供给私有化部署人员进行配置的初始化，devops根据配置的结果更新apollo的配置表
解决问题四：增量升级
对应甲方需要进行版本升级的，根据设置的基线对应的上线清单版本号，选择当前要升级的上线清单的版本，将中间涉及的所有清单的脚本，配置和当前要升级的最新版本的制品，打成对应的升级包提供给私有化项目组团队进行升级部署
总结
以上是对私有化部署的部分难题进行针对性的处理，在新的项目部署上，由之前的至少两人月周期，缩短到半人月周期，部署的成功率也提高了70%，不过其中还存在不少的问题，针对标准化的迭代，也存在很多不规范的情况，导致交付制品质量普遍偏低，接下来进行devops2.0的改造
