[心得]基于jenkins+git+Artifactory的CICD方案

CICD全称是持续集成持续交付，比较适合小步快跑快速迭代的互联网风格，因而在互联网圈广泛流行。

本文所叙述的方案在某二线互联网公司已经得到部门级应用。这篇博文不谈具体的jenkins＋git＋artifactory怎么安装配置，具体配置当你需要实干时谷歌查找就行。

CICD的方案有什么好处呢？以下是其中一部分：
1. 统一编译机制compile
2. 统一打包机制package
3. 统一包管理仓库repository
4. 统一包部署方案deployment
4. 便于回归regression
5. 便于扩容extension
6. 便于配置configuration

软件工程的一个核心是控制复杂度，尽可能避免引入人为风险因素。既能避免重复造轮子，又能提高业务上线的支持速度，从而保障高质量快速的产品迭代！

所有的代码，包括测试代码和开发代码，均维护在git或者svn下，目前git是主流，svn的代码在逐步往git迁移。

利用jenkins的SCM插件，可以侦测到代码库的变更，从而自动触发编译模块。

编译部分，考虑到不同代码库的编译需求差异，我们使用了Docker技术，从而c++/java等编译需求都能满足:

export success=1docker run -idtP --name $JOB_NAME$BUILD_NUMBER -v $(readlink -m $scm_path1):$scm_mount1 $DOCKER_IMG /usr/sbin/sshd -D &&    ssh_port=$(docker port $JOB_NAME$BUILD_NUMBER |grep 22/ |awk -F : '{ print $2 }') && sleep 3 &&    ssh -p $ssh_port -i ~/.ssh/id_rsa -o StrictHostKeyChecking=no localhost \    "pwd && cat ~/.bashrc && source ~/.bashrc && cd $scm_mount1 && $MAKE_CMD" && export success=0

这其中，大写的变量是jenkins job传递进来的，小写的变量则在前面需要定义好。$MAKE_CMD也是在jenkins job里面事先填好的。

编译好之后需要打包，具体打包哪些文件，这个需要用一个配置文件mypackage.json来定义：

{  "default_parameters":  {    "dest_base_path": "/data/app/mypackage/"  },  "package_conf":  {    "package_name": "mypackage",    "scm": "git",    "include_paths": ["common"]  },  "install_conf": {    "link": [      {        "src": "common",        "dest": "$(dest_base_path)/common"      }    ]  },  "start": "cd $(dest_base_path) && ./op.sh start",  "stop": "cd $(dest_base_path) && ./op.sh stop"}

这个格式对于各种包通用。上述包中将common文件夹打包到软件包里。

package_create.py -c mypackage.json -b master -r -s "test"

这条语句的意思是，用该json配置文件对master进行打包，打包之后保留原始目录，包添加后缀test字符串。

打包之后下一步是把包upload到仓库：

package_upload.py -g mygroup -target /data/mypackage_test.tgz -m artifactory

这一条是把包上传到artifactory仓库

至此，编译、打包、传仓库搞定。

下一步是部署和配置。

先说部署：

部署细分为下包和安装：

package_download.py -g mygroup -p mypackage_test -v 1.0.1 -b master -d . -r artifactory

这一部署是从仓库把包下载到当前目录。

然后是安装：

package_install.py -p mypackage_test -v 1.0.1 -b master --same

这条语句是把包安装到原来同一个位置。

这里采用了一个类似加锁一样的操作：touch一个LOCK文件，然后执行相应的操作，解压包，链接文件路径，显示安装信息。

最后是配置：
打包的conf里面支持一个字段：additional_ops，可以把替换配置文件这些额外动作放到这个参数里面，比如测试环境和线上环境是两套，那么替换操作在这一步做一下区分。

切换包的任务，我们是放到一个ansible的playbook里面去操作，那个另外专门写一个博文阐述。这里简单点一下：

po.py start

里面封装了切换服务的操作。

下一篇博文讲讲怎么用jenkins做QA保障。