• 需求背景

  • 之前没有过多的考虑增量sql以什么样的形式去整理，所以直接吧增量sql丢到项目代码根目录下面去了，如下
  • 
  • 后来跟老大交流了一下觉得这样的处理方式不是很可行，因为后续版本需要一直迭代，每次的增量sql也都不可能做到完全相同，所以只用一个sql脚本来去统筹是不现实的。

    改进方案

• 起一个专门存放sql脚本的目录，制定规范的命名规则来对sql脚本进行统筹规划。

• 这部分向开发学习之后，摘录如下

• 应用涉及的增量sql 只允许新增而不允许修改和删除，存放的位置限制 在 sql/increament 目录之中，文件命名规则如下

  • 迭代（时间戳 + 大版本号） ： YYYYMMDDHHmmss_{release_version}.sql
    • 例如：202006241400_v4.0.x.sql
  • 线上问题（时间戳 + 大版本号 + hotfix）：YYYYMMDDHHmmss_{release_version}_hotfix.sql
    • 目前禅道还有线上问题，有的话以这个规则来进行处理
    • 例如：202006241400_v4.0.x_hotfix.sql

      改进之后的Jenkins集成修改

• 按照上面的操作去执行的话，在构建时选择对应的increamentsql会额外的产生一些麻烦，

• 折衷方案是，之后的 增量sql 以 branch name来进行统筹。
  • 里程碑 的增量按照 tag 命名
  • 线上问题 的增量按照 hotfix分支命名 ```sql

    !/bin/bash

    set -x

Publish_IP=${server}

PASSWD_HOME=${JENKINS_HOME}/secret.txt

当前工作目录

/home/jenkins/workspace/Zentaopms_test

替换禅道源码文件

scp 命令

执行增量sql

【Mysql的bin目录】\mysql –u用户名 –p密码 –D数据库<【sql脚本文件路径全名】，示例：

C:\MySQL\bin\mysql –uroot –p123456 -Dtest<C:\test.sql

preparation(){ echo “输出JenkinsHome:${JENKINS_HOME}” echo “当前路径:${WORKSPACE}” cd ${WORKSPACE}

}

update_model(){

更新拓展 model scp命令 复制替换 文件

echo '扩展model'
scp -r module root@$Publish_IP:/opt/zbox/app/zentao
scp -r sql root@$Publish_IP:/opt/zbox/app/zentao
#scp -r incremental_sql.sql root@$Publish_IP:/opt/zbox/bin

}

update_sql(){

执行拓展 增量sql 取得执行返回进行判断是否成功

res =`ssh root@$Publish_IP "/opt/zbox/bin/mysql -uroot -pxxxxx -Dzentao</opt/zbox/app/zentao/sql/increament/$git_branch.sql"`
echo $res
#ssh root@$Publish_IP   << remotessh  
#/opt/zbox/bin/mysql -uroot -pxxxxx -Dzentao</opt/zbox/bin/incremental_sql.sql 
#exit  

remotessh

}

echo “构建执行开始” echo “当前发布IP地址 $Publish_IP” preparation update_model echo “构建执行结束”

```

• jenkins 集成脚本尚未进行测试，暂时留作思路记述

  续 方案存在的问题

• 刚开始的设想是像通过一个jenkins构建来完成 禅道源码的扩展和数据库的扩展，与老大交流之后发现忽视了一个问题。

  • 增量出来的sql并不是每次构建都能执行成功的。
  • 每次构建也不一定都需要执行增量sql脚本，
  • 每次迭代 生成的增量sql文件名称都不同，

后续向开发人员取经，采取 禅道扩展使用jenkins构建，数据库构建采取人工登陆服务器进行手动执行。