2.接收jira的发布任务操作通知，并通知到某一个Jenkins去执行，sonar进行静态代码检查等
3.接收jenkins构建部署反馈过来的进度
4.展示构建部署进度
5.一部分CMDB系统的功能，主机管理（ip，名称，用户名，密码）之类的。方便。
至于为什么不用世面上已有的CMDB系统，也实属无赖，要么要钱，要么好麻烦、要么没接口。索行自己简单做一个。能满足功能即可。
因为涉及到主机的账号密码之类的，所以密码都是公钥加密存储在系统上。
而密码的使用方有2个，一个是jenkins在部署的时候新机器在创建SSH免密登录的时候要用一次，还有就是远程管理工具要用，所以对密码的使用单独写了个小组件用私钥解密获得密码，然后把发布系统和小组件单独管理 jenkins
jenkins绝对可以说是这套工具里面的大佬了，可以说一切都是围着他在转。
接收发布系统发过来的构建请求，拉取代码，编译，拉取配置文件，打包成部署包，上传ftp，发布到私有docker仓库，部署等等。
还要区分系统环境，开发语言(windows、linux、nodejs、.net core)单独处理等。
1.参数化构建过程。比如要构建的分支名称之类的
2.源代码配置。git源代码地址，gitlab固定的代码只读账号，通过SSH进行代码的拉取。
3.调用构建脚本。jenkins内的执行命令大约如下面所示
重中之重了，所有的驱动都在这个脚本里面了。分环境、分开发语言单独编写的构建或部署脚本。
为什么每一个站点都有一个脚本的原因则是总有那么一些站点是那么的特殊和优秀，当然觉得多数系统都可以走一个公共的构建脚本。
脚本有不少要调用其他系统接口的，我则直接用.net core 写了一个控制台应用，专门负责这个事情，毕竟写shell不是专业的。
具体的构建脚本就不贴上来了。
脚本执行步骤（net core 测试环境脚本）：在每一个部署完成或者出错的时候都把进度反馈到发布系统上。
1.源代码在jenkins配置里面已经帮忙拉取好了。所以脚本不用拉代码了。
2.编译。比如dotnet publish -c Release -r linux-x64 -o “输出路径”
3.编译输出内容打包
4.上传到ftp。
5.拉取配置文件。
6.将输入内容和配置文件，等打成压缩包
6.拉取部署配置。要部署到那些机器，部署要并发还是要串行等
7.检查机器是否已经完成SSH免密配置了，没有配置则拉取密码配置好。
8.并行或者串行进行发布操作
9.SSH到目标机器，上传压缩包，部署脚本
10.执行部署脚本（解压，停掉原来的服务，启动新的服务，检查是否启动成功等）
在发布系统中接收到jira的发布请求后，拉取站点的配置，如果是需要进行sonar检查则把请求发送给sonar的jenkins。
目前我们配置的是发布到产线的时候才做sonar的静态代码检查，然后再sonar系统里面配置了。
后面看需要，是否要对sonar的结果进行邮件。打算这样做。每周出一份代码质量报告，统计一周内已上线的项目和上一周相比错误，漏洞，坏味道，覆盖了等数据的变化。弄个定时任务，sonar 2个接口获取一下数据，存储对比结果，发个邮件就完事了。
文章随便写写，很多东西交代的不清楚，还有很多东西压根就没有说。比如说堡垒机集成，日志、host监控集成等等等。我不会说实在是我太懒了，打字好累啊！
总之，欢迎交流！！虽然实现的不完成，但是还是毕竟适合目前自身的需求的。合适的才是最好的吗
感谢开源界大佬的贡献，虽然我还没钱捐款。让社区有那么多那么多好用的产品。
感谢前人已经种好的大树，很凉快！