[发明专利]一种应用发布方法、系统及计算机可读存储介质、设备

说明书

本申请涉及一种应用发布方法、系统及计算机可读存储介质、设备，涉及计算机软件开发应用的技术领域，其中，应用发布方法包括：获取应用发布请求；判断预设的第一数据库中是否存在与应用编号相匹配的发布模板；若存在，基于应用发布请求和与应用编号相匹配的发布模板发布应用；若不存在，基于应用发布请求从预设的第三数据库中获取相匹配的预设表单；获取研发端基于预设表单输入的依赖参数；基于应用发布请求从预设的第四数据库中获取相匹配的预设模板；基于预设模板和依赖参数生成部署模板；获取运维端基于对部署模板进行调整和修正而生成的发布模板；基于应用发布请求和发布模板发布应用。本申请具有降低研发端和运维端之间的协作成本的效果。

技术领域

本申请涉及计算机软件开发应用技术领域，尤其是涉及一种应用发布方法、系统及计算机可读存储介质、设备。

背景技术

随着云原生技术的发展和普及，越来越多的公司开始进行业务的全站上云，通过依托Kubernetes这个云原生操作系统，统一了IAAS层的基础资源管理，面对这场技术大变革，传统的面向物理机或者虚拟机的应用发布和交付手段已经不能满足现状，因为现在我们需要将应用跑在Kubernetes上，而研发端如果想在Kubernetes上做应用发布，首先要自行完成应用容器化的改造，之后再和运维端沟通发布部署要求，然后由运维端线下配置好各种yaml文件，最后登录上装有Kubernetes客户端命令的机器上进行黑屏应用发布，整个流程复杂繁琐且非常低效。

我们以最常见的普通Java web项目的发布到Kubernetes中为例：

（1）研发端先自行完成容器化改造；（2）研发端登陆jenkins将应用打包成镜像；（3）研发端将打包后的镜像信息和版本信息提供给运维端；（4）研发端将应用依赖配置信息如端口和环境变量等信息提供给运维端；（5）运维端创建并配置各种yaml文件；（6）运维端登录装有k8s客户端机器进行发布；（7）成功后将yaml文件提交到git，如果失败则需要回滚；（8）后续研发端每次功能迭代发布，都需要重2-7的步骤。

对于上述的操作方式，研发端和运维端的协作成本太高，每次应用发布，研发端和运维端都要沟通各种相关事项，导致部署效率低。

为了解决上面遇到的各种问题，申请人提供了一种应用发布方法及系统，以降低研发端和运维端的协作成本。

发明内容

本申请的目的是提供一种应用发布系统及方法，能够降低研发端和运维端协作成本，使发布和交付变得安全，快捷和可靠。

第一方面，本申请提供的一种应用发布方法采用如下的技术方案：

一种应用发布方法，所述方法包括：

获取应用发布请求，所述应用发布请求包括应用编号；

判断预设的第一数据库中是否存在与所述应用编号相匹配的发布模板，其中，所述第一数据库中存储有多个发布模板，每个发布模板对应一个应用编号；

若预设的第一数据库中存在与所述应用编号相匹配的发布模板，基于应用发布请求和与所述应用编号相匹配的发布模板发布应用；

若预设的第一数据库中不存在与所述应用编号相匹配的发布模板，基于应用发布请求从预设的第三数据库中获取相匹配的预设表单，其中，所述第三数据库中存储有预设表单；

向研发端展示从所述第三数据库中获取的预设表单；

获取研发端基于所述预设表单输入的依赖参数；

基于应用发布请求从预设的第四数据库中获取相匹配的预设模板，其中，所述第四数据库中存储有预设模板；

基于预设模板和与所述应用编号所匹配的依赖参数生成部署模板，所述部署模板存储于预设的第五数据库，所述部署模板和应用编号一一对应；

向运维端展示基于应用编号从所述第五数据库中获取的部署模板；

获取运维端基于对部署模板进行调整和修正而生成的发布模板，所述发布模板存储于预设的第一数据库；