为什么第一篇写开发流程标准呢？

我回想了下迈入这行，在学校里面我们努力编码，可能都是比较低级，完全没入门，直到出来工作后，无心插柳柳成荫，做成了运维，年纪逐渐变大，发现自己深入泥潭；更是给予不满现状的运维同志们，可能我们从实施运维一路走来，无数个加班，燃起些斗志，想想自己的初衷。

背景：在不熟悉一个研发团队不知道一个开发流程的标准，甚至没有一个标准的时候，镜像版本、服务名称如何定，这都是一门学门，当然每个公司的研发流程都有自己的标准，我则偏向运维方面。

在代码仓库中，我们时常会困扰因起什么名称：

 分支：不能在该分支进行开发，且永远是支持稳定版本。合并其他分支过来的时候，则说明新的一个稳定版本发布。

分支：该分支是永远是开发中的最新代码，该分支可延伸其他分支，不能直接在该开发，负责 

分支：该分支是从develop分支衍生出来的新分支，并且建议命名为：featrue/xxx-xxx ,最好这个分支是表面是什么功能，因为这个分支表示的是功能开发，开发完之后 

分支：该分支一般是预发布分支，同时也是提测的分支，所以该分支是从develop分支衍生的，并且建议命名为：release/v1.0.0 这样后面带着tag版本后，而且每一个编号也是有含义的（下文会讲到），测试中遇到问题也是在release分支上修复，直到 

合并到master和develop分支才会删掉分支，并打上Tag标签。

分支：字面意思紧急修复bug，一般是在master分支或者 Tag版本衍生出来，建议命名为： hotfix/xxx-xx，分支最好是说明是那个版本出现什么要修复，直到修复完成后 

合并到master分支并且重新打 Tag标签，最后并删掉该分支。

说了这么多，那我们作为运维要注意的就是怎么命名一个服务名称和镜像版本。下面我给个案例：

镜像版本控制案例：

v1.4.0-beta.m.n

m：第m次提测，前后端保持一致，如v1.4.0-beta.1.0

n：第n个临时补丁包，默认0，用于冒泡不通过等阻塞场景。如v1.4.0-beta.1.0

被打回则补发v1.4.0-beta.1.1

正式发布后遵循语义化版本号vx.y.z-<pre-release>

服务名称控制案例：

core-engine 建议在后面增加 service

core-engine-serivce

并且如果遇到什么需求，可以直接在core-engine-serivce_<angthing>

注：当然这都是我自己的个人经验，每个公司的标准不一样。

01：开发流程标准

运维开发工程师

运维

职业发展

后端

探索高效开发流程标准与运维实践：从代码分支管理到镜像版本控制，分享Git分支命名规范（master/develop/feature/release/hotfix）及服务命名技巧。针对运维人员提供实用案例，包括语义化版本号v1.4.0-beta.m.n格式解析，帮助团队建立标准化研发流程，提升协作效率。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

01：开发流程标准

01：开发流程标准

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐