jenkins实践篇(1)——基于分支的自动发布

问题背景

想起初来公司时，我们还是在发布机上直接执行发布脚本来运行和部署服务，并且正式环境和测试环境的脚本都在一起，直接手动操作脚本时存在比较大的风险就是将环境部署错误，并且当时脚本部署逻辑还没有检测机制，服务部署起来后，还必须登录到对应机器查看服务是否正确启动，整个部署过程可以说是很折磨人了。于是，我开始着手改善这块。

如何优化

第一，整个编译部署过程将不再允许登录到发布机手动执行发布脚本了，这样的风险性比较大，决定采用jenkins来完成编译和发布的工作，这样能让开发者通过界面操作来进行编译部署。

第二，之前脚本缺少检测机制，决定改善脚本，首先在部署前，脚本需要检测对应的服务的配置文件是否符合标准，我们的配置文件是json格式，其次在部署完成后，检测服务是否正常启动，如果没有启动，则尝试再次部署，直到失败3次后将不再重试。

部署模式思考

在决定朝着这两个优化点进行优化后，我开始思考最终的部署模式，测试环境肯定是经常要部署和发布的，而正式环境则不需要经常发布，并且要谨慎发布。

所以我考虑在测试环境做个自动发布的功能，到代码合并到测试环境的分支(测试环境永远用固定的分支名)时，会触发jenkins的webhook机制来自动编译和发布到测试环境。

而对于正式环境而言，则不采用这种机制，为了保证正式环境的安全，还需要保证代码的快速回滚，基于此，正式环境我将采用打tag的方式进行发布，每次发布后会生成一个tag，回滚时则可以基于tag快速回滚。关于tag的发布模式将在下一篇文章再展开，现在我们先来看看如何基于分支做自动发布。

配置webhook实现自动编译与发布

jenkins 安装 Generic Webhook Trigger  插件

在Jenkins的Manage JenkinsPluginsAvailable Plugins 中安装Generic Webhook Trigger 插件，再去到项目中查看Build Triggers ，就能看到Generic Webhook Trigger选项了。

Pasted image 20231020155700.png

在Generic Webhook Trigger 配置页下方有个token的配置，这个我一般配置成服务名，当配置了token后，到时候gitlab就可以通过url  ”http://JENKINS_URL/generic-webhook-trigger/invoke?token=TOKEN_HERE“ 来触发编译工作。

Pasted image 20231020160117.pnggitlab 推送配置

在gitlab中配置特定分支产生push事件时触发jenkins的回调任务,这里假设我的测试分支名是test，以后所有测试环境的功能都需要合并到test分支进行测试，所以我在push event下面配置了test，你也可以配置成其他分支。

Pasted image 20231020163855.png测试自动编译过程

这样，当我在test分支去进行push操作时，将会触发jenkins 特定项目执行其pipeline，完成编译和发布工作。

在gitlab下方可以点击Test选定特定的事件来测试下整个自动编译过程。

Pasted image 20231020164227.png

关于jenkins的发布和编译脚本由于涉及到公司隐私，我这里就不展开了，最终jenkins的pipeline 也是执行的shell脚本去发布机上去进行编译和发布。关于哪个服务需要发布到哪台机器上，我们是配置到了数据库里，然后脚本会根据要部署的服务从数据库中读取要部署的机器，然后将编译好的可执行程序通过scp发送到对应机器，然后远程执行ssh命令完成服务的启动。

整个项目的发布部署拓扑图如下，其实也完全可以将gitlab和jenkins放到一台机器上。

image.png