如何使用思特奇自动化平台

本篇文章是实际操作流程的角度来进行讲解如何在devops中实现自动化部署，有别于官方操作手册孤立功能点的介绍方式，代入感更强也包含了一些自己炒作过程中遇到的问题解决办法。希望能给大家提供一些帮助，自动化部署本身不难；如果你脑海里又有个清楚的认识和清晰的思路那就跟容易上手。

一、自动化平台的作用

回想我们平时开发和上线的过程你会发现有些动作是每次都要重复的，大体如下：编码、提交更新版本、编译打包、上传、启动、验证系统是否可正常访问。这些开发部署的过程如果是单台机器部署而且频率不高，总的来说也能忍受。但是在互联网行业大规模集群，一次性需要部署成百上千套的程序，这对于程序员来说简直就是噩梦！于是持续集成和自动化部署便应运而生。

持续集成或自动化部署与devops是什么关系？

Devops的概念

DevOps（Development和Operations的组合词）是一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合。通俗一点来讲，DevOps要求开发、测试、运维一体化，实现敏捷开发；DevOps从计划、编码、构建，测试、发布、部署，以及运营、监控打通，就是把敏捷开发部门和运维部门之间的围墙打通，形成闭环。

从上述的介绍可以看到持续集成或自动化部署只是Devops中的一个环节。

二、自动化平台的配置

1、如何打开自动化平台

2、配置步骤

2.1、打开自动化平台

打开自动化平台后可以看到一个项目列表；如果你发现想要配置的项目不再这个列表中就需要找人帮你去处理；然后就能在这里看到了。通常情况下你参与的已经研发立项的项目这里面都会展示。

2.2进入项目配置界面

2.3 代码托管

根据你开发项目使用的版本管理工具来选择。前期公司统一要求用Git来替换Svn，所以我们来配置Git。

2.3.1 打开的主界面

2.3.2 关联Gitlab仓库

你会看到两个选项关联Gitlab仓库和普通新建。

关联Gitlab仓库：适用于你已经创建好了Gitlab，并且已经将代码进行了托管；
普通新建：全新创建一个Git仓库；最终也是调用公司的Gitlab私有库的接口创建一个git版本管理远程仓库；

具体界面如下图所示：

点击关联Gitlab项目，弹出如下对话框：

这里git的远程仓库地址，但是右下角提醒你“==需先关联git秘钥==”。Git秘钥需要登录你的Github进行配置。这个地方系统说的个人认为不太准确；应该叫个人令牌。说白了就是第三方使用你的git账户去操作Gitlab需要的一些授权配置。

2.3.3 创建Gitlab个人访问令牌

访问并登录 http://git.si-tech.com.cn:9002/
点击右上角的头像，选择设置

再点击左侧菜单选择访问令牌

创建访问令牌

傻瓜点的方式就全部勾上吧，然后点击 ==创建个人访问令牌==，创建成功后如下提示：

2.3.4 设置秘钥

我们关闭刚才的关联Gitlab仓库对话框，点击主界面上的设置秘钥，如下图所示：

打开Git仓库界面并点击设置秘钥

打开秘钥管理界面，点击配置秘钥

填写配置信息，点击确定。

2.3.5 关联Gitlab仓库（同2.3.2）

到这一步我真心感觉系统界面流程有点反人类，易用性有点点差，跳来跳去逻辑混乱。好吧，填充上你代码的git版本管理地址，代码托管算是配置完成了！

2.4 代码检查

按照道理我们在程序上线之前是需要给代码做个检查的；公司的自动化平台代码检查用的是Sonar，感兴趣的自行百度学习。但是这不是必须的配置步骤，你如果真心不想做代码检查也没有问题，可以跳过2.4节的内容继续往下看。

点击左侧菜单==代码检查==、点击==新建==按钮。

2.4.1 填写基本信息

**任务名称：**自己随便个性化填写就好了；

**检测语言：**选你想要检查的语言，选的越多后面的检查报告越红！这种代码检查一言难尽；更多的是纠正你的编码习惯减少隐患，有一定的作用但是也有犯神经的时候。

2.4.2 选择源代码

2.4.3 高级设置

这里就是把检查报告的地址用邮件发给谁；不配置默认发给代码检查任务的创建人。

2.5 构建任务

就是调用jenkins帮你打包上传到指定位置（制品库）。公司的系统到了这里又有点逻辑混乱了；我们需要先创建一个应用。

2.5.1 应用创建

点击左侧菜单持续集成、应用管理，点击新建按钮、填写基本信息然后保存。

2.5.2 填写基本信息

点击左侧菜单 ==构建任务== 、点击 ==新建==按钮。

2.5.3 选择源代码

老套路，你既然让工具给你打包；你首先得告诉工具从哪里取代码；数据来源还是你在2.3 代码托管里面配置的信息。

2.5.4 构建配置

构建命令：clean install -Dmaven.test.skip=true -X （方便懒汉，具体命令怎么用；百度maven进行学习吧）我的构建命令是单模块的构建；你如果是多模块的可以指定模块名称、按照顺序再增加几个构建步骤。

2.5.5 发布配置

这一步也是我反复出错的地方；个人感觉又有点反人类了；提示不清楚；我估计开发人员当时的心态是：别管那么多了先搞上去上线再说吧；好不好用以后再讲，以后……以后……。这一步为什么不对用户透明免去配置痛苦？！

**==构建包路径：==**填写你项目构建时生成的jar包或者war包的相对路径；

例如你项目名称是abc，那么你在idea或者eclipse中通过maven命令构建程序后会在项目的target目录生成一个abc.jar 或者 abc.war (如果你没有特别配置打包文件名称的情况下)；具体路径：D:\workspace\abc\target\abc.jar 。按照界面的提示你应该填写 ./abc/target/abc.jar 我按照要求这样填写每次运行构建的时候日志都报错上传制品库出错，找不到制品。我找部门其他同事让条目把当初的部署配置截图给我；确认是要带 ./abc 的；还是报错；在后来找到CSD的同事协助排查；被告知只需要填写 ./target/abc.jar 。我就纳闷了；为什么其他项目填写 ./abc/target/abc.jar是正确的；我填写 ./target/abc.jar 也是正确的。反正你们都试试吧；这里是个坑绊了我很久。

**==构建包版本：==**填写一个版本v0.3.0 或者 0.3.0 这个乱写也行；好像不会用到（个人猜测）。

**==构建包名称：==**这个就更玄乎了，提示填写一个目录其实填写 abc.jar 就好了；或者你的是abc-0.0.1.jar 带版本的名称

这个环节是我感觉最懵逼的。

2.5.6 高级配置

这一步可以忽略；不配置。本意可能是多个节点（机器）集群化来提供多并发；但是目前就一个节点。点击完成便完成了构建任务。

2.5.7 测试检查

配置完成后返回管理页；运行一下构建任务；点击标题看看日志；日志里面会提示成功或者失败。失败了你就看看哪里失败了；回来重新改自己的配置。界面中还有其他的制品库列表、权限、删除、停止什么的自己探索吧；不难。

2.6 部署任务

点击左侧菜单选择部署任务、点击新建。

2.6.1 填写基本信息

红框的反人类设计退出按钮不要点，点击部署任务步骤继续配置。

2.6.2 部署任务步骤

系统为您提供了多种原子操作，具体如下：

你可以通过这些原子操作来模拟你的部署过程；每个项目这里差异比较大；配置不尽相同；我来给你说说我的思路。我们上线通常如下步骤：

把现在启动的应用给停掉；
把最新刚刚热乎乎的jar包或者war给上传到服务；
执行shell命令启动springboot项目；
等待3分钟；

测试一下系统界面如何访问；

上面的步骤都可以在这里进行配置。具体配置如下：

Springboot代码可以在启动的时候创建一个app.id用于执行来停掉应用，具体代码如下：

    public static void main(String[] args) {

        SpringApplication application = new SpringApplication(PortalApplication.class);
        ApplicationHome applicationHome = new ApplicationHome(PortalApplication.class);
        String pidPath = applicationHome.getSource().getParentFile().toString() + "/app.id";
        application.addListeners(new ApplicationPidFileWriter(pidPath)); // 使用PidFileWriter生成一个app.id 然后监听
        ConfigurableApplicationContext ca = application.run(args);
        WebSocketServer.setApplicationContext(ca);

    }

当然停应用的方法好几种；但是我最喜欢这种；不用写shell脚本放服务器上；少了一个步骤；尽可能的简单。可靠。

注意：失败后是否继续执行，请选择执行；因为第一次部署的时候是没有应用在启动的；所以必定会失败。这个设置的意思是失败了后面的步骤继续！

下图所示是第二个步骤，里面涉及到主机组；就是一个分组和一个主机配置；大家进去填写主机的账号密码什么的；没有什么难度，我就不说了。但是这里的构建包名称填写的就非常不灵活了。如果下次版本升级；还需要过来改下。这很不方便！！！

2.7 流水线

流水线这玩意其实就是把上面2.4 ~ 2.6 里面配置的功能进行一个串联。一个流水线包含多个操作。试想一个场景：

我们每次上线前，肯定是先代码检查一下（可省略）、编译打包上传制品（构建任务）、上传服务器启动检查是否可以访问（部署任务）；我们可以用一个流水线把构建任务和部署任务串联起来；如果是集群化部署可以一个流水线部署多台机器。下面我们开始实操：

点击左侧 ==流水线==、==新建流水线==。界面如下：

流水线名称：自己随便填写一个有意义的就好；

执行方式：

手动：这个好理解；你自己在界面上点击启动；
定时：这个也要理解；你自己定个时间比如每周四的晚上19.00
自动：根据你每次提交自动触发流水线动作。这个如果你了解jenkins应该很好理解；利用git的钩子功能来实现的。大家感兴趣可以理解。具体实践我的理解是：有个生产发布分支、开发分支；我们开发的时候都在开发分支做；确认没有问题往生产发布分支合；代码合完一提交；自动触发流水线进行上线动作。

后面的步骤一、步骤二等等是可以扩展你的；我只配置了两个步骤；第一个是构建任务即立刻拉取最新版本的代码进行打包；第二是部署任务上传测试环境进行部署。

本文由 huzd 创作，采用知识共享署名4.0 国际许可协议进行许可本站文章除注明转载/出处外，均为本站原创或翻译，转载前请务必署名最后编辑时间
为: 2021/01/29 14:45