问题背景

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

如何优化

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

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

部署模式思考🤔

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

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

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

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

jenkins 安装 Generic Webhook Trigger 插件

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

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

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

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

gitlab 推送配置

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

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

测试自动编译过程

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

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

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

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

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

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

10-25 03:48