笔者是公司是一个分前后端开发的公司。而笔者是一个普通的后端开发工程师。在和前端工程师协同开发时,为了给前端工程师提供接口,往往要将写好的代码交付并部署到测试环境。因而这导致笔者经常需要打包项目更新到测试环境。这种情况十分烦人,因而笔者想了这套简单的方案来解决这个问题。
方案思路
1、采用分支管理更完善的Git
进行代码管理,以不同分支版本作为不同环境的构建版本
举例:
master 分支作为生产环境的构建版本
test 分支作为测试环境的构建版本
dev 分支作为日常开发(包含未过debug)的代码存储管理
2、使用自动化构建工具,在不同环境下获取不同分支的代码进程构建运行
笔者实例
1、使用开源的Gitea作为代码仓库管理
由于大部分公司都不愿意将代码放至网上(即使是私有仓),因此这里使用开源的Gitea项目部署在测试环境上
2、编写一个极为简单的自动化构建工具部署到测试服务器上
由于测试环境都是些低配服务器,为了节省资源,存放更多的应用到服务器中。因此笔者弃用市面上的大型自动化构建工具,而去使用golang编写一个极其简单的自动化构建工具
笔者的工具开源连接http://github.com/lroyia/goauto
模拟实操
以上方案在window及linux下均可用,下文以CentOS服务器为例。请按照自己的服务器操作系统类型酌情修改
1、下载Gitea
前往Gitea官方下载Gitea,并根据官方文档安装。以下使用1.12.4版本为例
1 |
|
2、安装数据库以支撑Gitea
Gitea支持SQLite,MySQL,PostgreSQL和MSSQL,这里以PostgreSQL作为例。其他数据库请自行根据官方文档进行配置
修改postgresql.conf
,将加密方式改为sha
1 |
|
转至postgres用户,并用CLI登录PG
1 |
|
创建数据库用户
1 |
|
创建数据库
1 |
|
修改pg_hba.conf
,授权登录
本地登录:
1 |
|
远程登录:
1 |
|
做完以上配置后重启服务或重载配置
3、初始化Gitea并构建服务
命令行执行
1 |
|
打开浏览器,访问服务器3000的端口访问Gitea
页面
随意点击顶部bar上的任意按钮,即可进入初始化的install页面。按照自己的需要配置好后,在服务器上gitea的同意目录下就会多出一个custom目录。用于记录配置的app.ini文件就在该目录下的conf目录里。
接着构建服务。ctrl + c
取消刚刚运行的gitea
进程,然后服务器运行
1 |
|
拷贝示例代码gitea.service按照自己的需求取消注释及修改
示例:
1 |
|
激活gitea.service
并将它作为系统自启动服务:
1 |
|
启动服务后,浏览器访问Gitea
的页面,注册账号并登陆。
以下操作为项目示例:
点击界面右上角的+
号,创建一个demo仓库
进入http://start.spring.io/创建一个springboot的demo项目
在demo项目中加入一个controller,使其返回一个hello
在仓库首页点击按钮,复制克隆路径
命令行运行
1 |
|
拉取仓库后将demo项目中的.git去掉,并将其他文件全部拉到拉取的仓库目录下
命令行进入仓库目录,并执行命令推送所有代码
1 |
|
回到浏览器的gitea
页面,点击当前分支的下拉列表,输入新标签名,从当前分支的节点创建新分支(这里创建test分支和dev分支)
构建服务器上运行
1 |
|
保证git在输入一次帐号密码后不再需要输入帐号密码,然后拉取仓库并检出test分支
1 |
|
给服务器安装golang环境,拉取博主的自动化程序代码,并构建
1 |
|
修改里面的conf.ini,配置demo项目的部署信息:
1 |
|
最后启动运行./goauto
启动,linux下如果需要关系运行,可使用以下命令挂起运行
1 |
|
以上便是这个方案的全部示例搭建过程
改进方案
在这个方案中,其实我们在构建部分再独立一个程序出来做这一步骤。构建后通过Docker
存储Artifacts
,再通过程序调用Docker
获取对应Artifacts
重新部署。这样可以避免由编译构建时间引起的服务真空期。但公司大部分服务器都是Windows
服务器,Docker
在Windows
以及虚拟机
中部署坑多,就不考虑这个改进方案了,以后有机会在看着办。