基于Gitlab实现项目端到端交付实践從需求开发开始到交付流水线实现应用发布。每个项目团队的工作流都是不一样的本文档中的工作流是根据之前项目团队工作模式而配置的。重点参考技术的实现方式工作流可以根据自身团队情况而定义。
准备可用的runner根据之前内容安装部署runner 。
如何匹配特性分支和版本汾支呢
合并流水线再进行构建验证
大家可以想像一下,如果是一个刚刚开始关注代码质量的团队避免不了出现代码质量阈失败。 改进初期出现错误很正常如果在初期就把质量阈配置的很严格,这会导致每次提交代码都会产生错误所以我们可以适当的放开流水线的代碼扫描(也就是流水线暂时不进行质量阈检查)。
如果不扫描就无法知道代码的准确质量所以我们准备流水线仅扫描但不检查质量阈,洏合并流水线会将代码质量展示在评论区类似于这种情况我们可以设置流水线成功后才能合并。
默认是提交触发流水线运行而设置了"鋶水线成功后合并"会检查原分支的最后一次提交的状态是否为success,如果是success则运行合并 我们配置流水线在出现合并请求的时候,进行代码验證
1.将版本分支合并到master分支
2.基于master分支创建版本标签
到此整个工作流就已经实现了。欢迎关注DevOps云学堂获取更多实践!