gitlab分支管理
gitlab上我们建立的多个项目，每个项目都有master,dev两个分支，feature分支可以根据任务需要进行建立和删除
master分支：代码对应着我们的线上环境的；
dev分支：代码对应着我们的测试环境；
feature分支：对应着具体的开发和产品任务，根据实际需要进行灵魂调整；
Jenkins配置
每个项目都建立了两个构建任务分别为：<projectname>-master和<projectname>-test，可以根据任务需要建立其他构建任务和删除；
<projectname>-master ：我们对应着正式环境的构建，构建环境和配置使用正式环境的参数和配置，并上传到正式的镜像仓库中；这个构建请不要使用自动化构建，请使用手动触发构建
<projectname>-test：我们对应着测试环境的构建，构建环境和配置使用测试环境的参数和配置，并上传到测试的镜像仓库中；这个构建可以实现自动化构建
容器服务
容器服务中我们分别建立对应正式环境的仓库，测试环境的仓库，正式环境的集群和测试环境的集群，以及下面的服务
镜像仓库：我们共同使用一个大仓库在linshang命名空间下，每个项目分别拥有两个镜像仓库分别为：<projectname>-master和<projectname>-test
集群：我们创建了两个集群环境，分别为正式环境和测试环境，正式环境给用户用，确保稳定性和安全性，测试环境各开发和测试用拥有开发和测试；
服务：每个集群都有多个服务，两个集群的服务名称相同，但是配置不同，正式集群的服务使用人工维护，且使用对应的master的镜像，测试集群的服务使用自动化维护，且使用对应test的镜像；
钉钉robot通知
代码上传，打包镜像，服务的启动和停止的钉钉信息通知，是为了方便进行通知测试，暂时现有开发按自己的理解进行提供，后期会和测试沟通约定好后进行规范
最佳流程实践(征集)
和产品经理充分沟通业务需求后，开发团队根据实际需要从dev/master新建一个分支feature分支开始实现业务逻辑；
feature分支可以多次commit和push，任务开发完毕自测通过后，meger request到dev分支，团队内部进行代码review，并进行合并到dev分支，并由Jenkins自动构建发布到测试环境，开发人员跟进并通知测试和产品进行验收
测试和产品验收通过后，团队负责人将feature分支，meger request到master，通知UEA和技术负责人代码review和合并，合并后，技术负责人手动进行Jenkins打包发布，手动发布到正式的容器中，并验证线上程序应用，并通知UEA，测试，产品经理进行线上验证
网友评论