jenkins构建方案

一、打包方式

打包方式采用jenkins + gitlab 手动构建方式：

1. 同个gitlab项目组下的服务打包采用同一个jenkins任务进行打包，不做硬性规定。
2. jenkins构建采用参数化构建，进行构建项目选择，项目版本选择。

二、构建包下载方式

打包后代码存放位置：

1. 打包后代码上传到nginx服务器上，对外提供构建包下载服务，对nginx访问进行权限限制(nginx服务配置本地也可以)

三、构建方式

构建环境：

1. 构建采用saltstack方式，构建之前需要准备saltstack环境
2. 标准saltstack agent端ID命名：
3. salt-minion的id命名指明服务环境 qa/dev/prod，用于区分环境。
   构建细节：
4. 构建使用jenkins远程执行salt-master上的更新脚本进行更新。
5. 脚本运行方式如下： python update.py qa server_name http://nginx/url/connector_path.tar.gz
6. update.py为脚本名称， qa来区分部署的环境信息， im来区分项目以及统一项目命名规范
7. http://nginx/url/connector_path.tar.gz为部署包下载url，格式统一。
8. 脚本通过url，im， qa 等参数，可以拼接得到服务的项目名称，服务所属分组。
9. 脚本通过salt-api获取该服务分组下的服务器列表后，继续通过salt-api进行远程命令执行，执行后进行服务状态检测，继续滚动更新，状态返回。

注意事项：

1. 根据项目进行构建方法配置，建议不同任务负责不同构建。
2. 使用一个构建包的下载服务器，方便其他有需求的项目进行部署包的下载。
3. 构建采用saltstack、ansible等，进行批量构建事半功倍。
4. 注意构建过程中的规范问题，如命名规范，分组规范。
5. 如果采用salt-api进行信息的获取，需要注意salt-api获取服务信息时的问题。(salt-master分组信息修改后需要对salt-api服务进行重启操作)
6. 根据服务定制启动方式，更新流程，回滚策略。
7. 服务启动完成后，需要对服务状态进行检测。指定相应的通知策略。(显示、报警或回滚)