一、概要设计
发布单的生命周期:
发布单状态
新建 构建成功 构建失败 待发布 发布中 发布成功 发布失败
权限分配:
二、详细设计
2.1 应用管理
应用模型的ER图
应用创建
- 通过继承django的通用创建视图CreateView来新增app,需要先创建一个表单form。
- 表单数据和app模型基本一样且有利效率提升,创建表单时,使用模型ModelForm来创建。
- 为了实现创建app的同时能创建app的jenkins job,需要重写通用类视图的form_valid函数。
应用列表
- 通过继承django的通用显示视图ListView来展示app列表
- ListView类视图默认将指定模型的所有object进行展示,为了支持搜索关键字的功能,可以重写类视图的get_queryset函数
- 在应用列表中,只有app的管理员和系统管理员才能对app进行编辑和授权,前段模板做判断是否允许点击,后端接口也做身份验证。
在应用列表中点击应用名称可以展示应用的详情
- 通过继承django的通用显示详情类视图DetailView来展示app详情,展示的字段由template文件决定
在应用列表中点击编辑可以修改应用的信息
- 通过继承django的通用更新类视图UpdateView来修改app详情
- 为了保证应用的jenkins模板被修改时,其在jenkins中对应的job也能发生变更,需要重写通用类视图的form_valid函数。
2.2权限管理
因为权限管理和环境有关,所以先创建各类环境
环境的实例作为系统基础数据,在初始化时就要创建它。三个环境实例如下:
在发布系统中权限主要是围绕应用app,初步设计分为以下几类:
- 为应用创建发布单和编译发布单
- 为应用的发布单申请部署
- 依据发布单对应用进行部署
将权限进行拆解,执行的动作action如下
action的目标对象为app应用,而部署的动作又和环境有关,所以权限设计也和环境有关。
权限ER图
- 当action动作不是部署到时候,环境字段可以为空
- app的管理员和系统管理员默认拥有app的所有权限
- main_user 多对多大关系将用户和权限进行关联,最终记录user用户对app应用具有什么权限
- 应用的权限最初是不存在的,当app管理员或者系统管理员在app列表点击授权时,先检查permission是否存在该应用的权限。如果不存在则为这个应用创建权限。
权限管理的入口是在app列表的授权按钮
指定app的权限列表
权限管理采取的左右两块,右侧部分使用前段的iframe标签,点击左侧的权限名称,右侧会访问响应的url并跳转对应的权限分配页面
2.3 服务器管理
server服务模型的ER图
服务器并不是单纯的服务器,因为可能在单个服务器上部署多个应用,这儿服务器的名称用IP_port的形式标识服务器
服务器创建
- 也是像app一样利用django的通用识图CreateView来创建
- 服务器创建只有系统管理员才可以进行,类视图中的函数对用户进行身份验证
服务器列表
说明参见app应用列表
服务器详情页
说明参见app
服务器编辑
说明参见app
2.4 发布单管理
发布单ER图
- 发布单的名称name,创建时候无需手动填写,由时间加两个随机字母构成。
- deploy_type发布类型,指全量还是增量发布,如果是全量则部署前会有删除原文件的操作
- deploy_content发布内容,可以只发布配置文件或者软件包,也可以发布所有
- nginx_url软件压缩包的存储路径,发布单构建成功后自动生成
新建发布单
说明参见app和源码
发布单列表
在发布单的模板文件中,根据发布单的状态,有相应的操作可以点击。每个操作背后都是一个url请求。
构建和申请部署相对简单,看源码即可。介绍下部署发布单的操作。
点击部署操作,会访问到一个新的页面(会进行一次权限校验)。在该页面可以选择app专属的服务器进行批量部署,可以选多个也可以选单个,也算是灰度发布吧。
点击立即部署将post访问真正部署的url,传递参数(所选主机id,发布单名字,所属环境,应用名称,发布类型,发布内容)
真正部署的url是由视图deploy处理,其大概的流程如下图所示
新建发布单
也是利用通用视图,相见源码
2.5 批量任务
应用列表
批量任务主要是app在某个特定环境下的服务器执行,所以第一个页面为选择app和环境,第二个页面才出现选择服务器
在选择服务器的页面进行服务器选择和操作的选择。如果没有选择服务器而直接点击立即执行会弹窗提示选择服务器
选择服务器后点击立即执行,会进行信息确认
如果是回滚操作,在确认的页面会出现发布单选择,这些发布单是部署成功过的。
启停历史
没什么别的,具体看源码。
数据统计
系统管理
jenkins设置
gitlab设置
软件仓库设置