3 回答
TA贡献1804条经验 获得超3个赞
在源代码中保留一个版本号是一种常见的做法,这没有错。
您需要将 CI 过程与常规构建、发布发布和发布部署分开。
定期构建:每天甚至在每次提交后运行,可以包括静态代码分析和自动测试,检查代码是否可以构建。常规构建不应更改版本号。
发布发布:只能由发布经理的显式手动操作触发。
触发操作可以是用新版本号标记提交,新合并到发布分支,或者只是更改保存在特殊文件(例如pom.xml
)中的版本号的提交。例如,请参考 git flow。
发布发布分配新版本号(自动或手动),必要时将其提交到源代码中,使用新版本构建二进制包并将其上传到二进制包存储库(例如 Nexus、devpi、本地 APT 存储库、Docker注册表等)。
发布部署:另一个手动触发的操作,从包存储库中获取准备好的二进制包并将其安装到目标环境(开发、QA/UAT/暂存、金丝雀部署的生产部分或整个生产环境)。
TA贡献1816条经验 获得超6个赞
前提:
我假设这些是讨论解决方案的前提。
当前版本号保存在 git-tracked 源文件中,但您可以摆脱它。
没有人手动管理版本号,也没有触发发布程序,其中包括:(a)增加版本号,(b)从源构建和(c)将构建结果存储在某处。这些由 CI 处理,并且应该保持这种状态。
解决方案:
CI 不是写入源文件并创建新提交,而是简单地标记通过 CI 检查的特定提交,然后将标记推送到远程仓库。
构建脚本应该读取当前 HEAD 提交的标签,并将其用作发布版本的版本号。
或者,您可能希望使用
git filter-branch
重写现有的 git repo 历史记录,标记以前的版本提交以保持一致性,删除并停止跟踪版本号源 cile,然后摆脱那些 CI 提交。
TA贡献1831条经验 获得超4个赞
我认为你应该使用 git flow。并创建一个master分支和一个develop分支。每次 CI 检查开发时,版本号保持不变。每次你创建一个版本,例如将开发合并到主,你可以通过 CI 增加版本号。
或者我遗漏了什么,但在我看来,没有理由每次 ci 运行时都会增加版本号。
因此,总而言之,您最好考虑何时“发布”对新版本的更改!!
添加回答
举报