应用发布规范¶

发布包规范¶

应用发布包¶

应用发布包必须是一个全量包，包名中带版本号。

名称格式：子系统英文名_版本号_构建次数XXX..tar.gz。名称内以“-”间隔，名称与版本号之间以“_”连接，以.tar.gz结尾。

WeCube获取版本号规则：两个下划线之间&三位数字&这三位数字之间用 ’.’ 分隔。应用发布包名称示例：wecube-core_1.0.0_20191101001.tar.gz

脚本、配置文件按分类放在不同的目录下。

配置文件中的差异化变量支持以下格式：[@var_name]、[&var_name] 、[!var_name] 、[%var_name]，其中[!var_name] 、[%var_name]会触发wecube公私钥加密。

应用发布包中建议部署、启动、停止脚步各有1个。如果有多个脚本，按数字前缀标明执行顺序，例如1_deploy.sh，2_deploy.sh。

按打包时的目录和结构不同，可以分为以下三种情况：

应用包中使用通用目录

应用发布包中只有一些通用目录，没有版本目录，目录结构示例如下：
```
|- bin
|- conf
|- lib
|- logs
```
应用包中包含软连接及版本目录（建议）

应用发布包中包含：一个包含发布包内容的版本目录和一个指向版本目录的软连接，目录结构示例如下：
```
|- current（注：软连接， 指向wecube-core_1.0.0）
|- wecube-core_1.0.0
    |- bin
    |- conf
    |- lib
    |- logs
```

数据库发布包¶

数据库发布包，包名称中带版本号，名称以“-”间隔，名称的最后一段以”-db”结尾，名称与版本号之间以“_”连接，以.tar.gz结尾。

名称格式：子系统英文名-db_版本号_构建次数XXX..tar.gz。

WeCube获取版本号规则：两个下划线之间&三位数字&这三位数字之间用 ’.’ 分隔。

数据库发布包名称示例：wecube-core-db_1.0.1_20191101001.tar.gz

数据库发布包应包含全部脚本，脚本所在目录名称对应的应用版本（可以跳过没有SQL部署的应用版本），每个应用版本目录应该包含increment和rollback两个目录。如应用从版本A升级到版本B，应该执行A到B之间的差额部分。

压缩包解压后参考如下：

|- app_v1.0
|   |- increment
|   |   |- 1_create_db_tables.sql
|   |   |- 2_insert_init_data.sql
|   |
|   |- rollback
|       |- 1_delete_db_data.sql
|       |- 2_drop_db_tables.sql
|
|- app_v1.1
    |- increment
    |   |- 1_create_db_tables.sql
    |   |- 2_insert_init_data.sql
    |
    |- rollback
        |- 1_delete_db_data.sql
        |- 2_drop_db_tables.sql

建议DDL脚本支持幂等（可多次调用，结果一致）。

发布规范¶

应用发布¶

使用通用目录

发布时，每个版本没有独立的版本目录，使用通用目录。

示例：

wecube-core子系统的发布目录为：/data/wecube-core 发布目录中的目录结构示例如下：
```
|- bin
|- conf
|- lib
|- logs
```
发布时，直接用新的发布包里的内容覆盖发布目录中的内容。
使用软连接版本目录（建议）

发布时，每个版本有独立的版本目录。

在发布目录中有一个软连接，每次发布时，修改软连接的指向到相应的版本目录。

示例：

wecube-core子系统的发布目录为：/data/wecube-core 发布目录中的目录结构示例如下：
```
|- current（注：这是软连接）
|- wecube-core_1.0.0
|- wecube-core_1.0.1
|- wecube-core_1.0.2
```
其中第一个“current”是软链接，指向到最新版本。

发布时，发布包解压生成新的版本目录和软连接，软连接会覆盖原有的软连接，更新指向到新的版本目录。

注：也可以在发布包中不包含软连接目录，而是在发布时，通过部署脚本创建软连接或者修改软连接的指向。

定期清理发布目录中的旧版本目录。

数据库发布¶

数据库脚本发布时，应指定执行用户。

数据库脚本只支持SQL脚本。

数据库脚本只写跟系统业务功能相关语句，如建表、增加、减少字段、初始化数据等；不应包含管理语句，如建库、建用户、授权等数据库运维相关语句。

应用标准化注意事项¶

差异化变量Key应该由属主方定义。如配置文件中有um_vip=[@um_vip]，后面[]内的um_vip（即差异化变量的key）应该由UM系统定义，其他访问UM的系统，都应该使用这个Key。参考以前直接写IP的情况，UM地址是10.1.1.1，任何访问UM的系统，配置文件应该是um_vip=10.1.1.1，现在的[@um_vip]就等于与以前的10.1.1.1
通用差异化变量应该统一，比如连接子系统私有数据库，IP变量都应该命名[@db_ip]，如有A子系统命名为[@a_db_ip]，那么差异化变量表达式只能自己配置，无法使用常规变量KEY。如某子系统连接不止一个数据库，比如A和B两个数据库，数据库IP变量的命名不能使用通用[@db_ip]，必须分别定义为[@a_db_ip]和[@b_db_ip]
应用必须有启动脚本，停止脚本，部署/安装脚本，脚本中避免使用绝对路径，如/data/apps/xxx，导致路径变化时无法替换。
建议脚步不依赖当前执行目录。在任何目录执行/data/PRD_DEME_APP/bin/start.sh和在/data/PRD_DEME_APP/bin/目录执行./start.sh结果一致。
应用需要公私钥加解密时，运维工具的公钥（如行内aomp的公钥）避免写死至代码，应该做成配置文件+变量，部署时可以替换为wecube的公钥。

最后更新: 2020年7月28日