CMS同步控制
一、需求引入
这是我刚入职公司没多久的需求，都两年多的东西了，周五时候无意中看到，发现还是有点意思的。昨晚特意理了下思路。
需求是这样的：公司内网服务器搭了个CMS的发布后台，其中有a、b、c、d 的目录需要上传到线上服务器上，但是有不同需求，a、b目录需要每5分钟传到线上，而所有目录a、b、c、d则要人为意志控制才能发布。为什么要这么搞？因为美工时不时、有需要的时候才会动c、d目录的东西，意味着c、d目录里文件有更改，需要同步到线上看，貌似是样式、动态资源的东西。a、b目录主要是静态资源比如文章。
二、问题解决
当时领导给我说了好几次需求，怕我理解错意思。。。估计怕我做不出来，那时候试用期都没过。。。这个解决思路是公司一个懂运维的开发给我参考的。他叫我用脚本结合传参进行控制。
解决流程图如下：
说明：
CMS目录：tomcat跑的项目目录，浏览器能访问CMS后台发布地址，美工运营用来发文章就是改动CMS这个目录下的文件。
Website目录：实际传到gitlab的项目目录，用于同步到线上，nginx代理该目录，让用户访问。
Website和CMS的目录不相同
1、公司内网有个同步到gitlab的脚本：主要是把CMS目录a、b、c、d拷贝到Website相应的目录：a、b、c、d， 每3分钟定时推送到gitlab仓库，这样做的原因是防止美工不定时利用CMS后台发布东西，干脆有杀错无放过~~~
2、内网jenkins发布平台，主要做的任务是进行CMS发布。git项目实际对应Website。
（1）maven构建Webiste项目，形成war包；
（2）调用1 的同步脚本，将CMS的a、b、c、d目录拷贝到Website，并push到gitlab上；
（3）停掉tomcat跑的CMS，，并进行a、b、c、d目录备份
（4）把（1）构建后的war包，解压进行Website包发布，并将第（3）步备份过的a、b、c、d目录还原
（5）起tomcat跑的CMS
上面流程图说了，我是通过参数来控制不同目录发布的。
线上也有个jenkins发布，给美工他们开了发布权限。事先线上服务器编写有脚本：pull_CMS.sh
（1）放到计划任务里：
*/5 * * * * /bin/bash pull_CMS.sh 1
（2）美工实际发布的jenkins任务，实际运行脚本
/bin/bash pull_CMS.sh 2
pull_CMS.sh 判断参数来发布不同的目录
（ps：这个脚本其实就是把gitlab上Website的目录a、b、c、d根据参数：1、2，去判断是发布所有目录到CMS，还是只是只发布a、b目录。实际上就是复制）
1 #!/bin/bash 2 3 。。。。。从gitlab上同步Website项目到线上服务器 4 5 ### judge para to transfer 6 transfer_choice=$1 7 8 if [ ${transfer_choice} -eq 1 ]; then 9 # echo "only the dir(a、b) to deploy" 10 cp -rp ${Website}/u ${CMS}/ 11 cp -rp ${Website}/html ${CMS}/ 12 13 elif [ ${transfer_choice} -eq 2 ]; then 14 # echo "all the dir(a、b、c、d）" 15 cp -rp ${Website}/* ${CMS}/ 16 fi