首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

DevOps: 项目多环境配置和健康检查

git分支管理 根据每个环境打不同的包,发布一个新的feature到生产需要类似下面这样的流程: 首先用 develop 分支 打包,发布sit环境,测试通过合并到 release 分支; 然后用 release...分支 打包,发布到uat环境,测试通过合并到 master 分支(打 tag); 最后用 master 分支 打包,发布到生产环境。...打一个包发布所有环境以后,分支管理模式将改为: 功能在feature分支自测成功以后,将代码合并到release分支,测试人员在release分支测试并最终发布生产。...当代码成功发布生产以后,将release分支代码合并到master 分支。 ? 上图演示了多环境多包发布和多环境单包发布的简要流程,下面做一下补充说明。...使用release分支打的包发布成功以后,会将release分支的代码merge到master分支备份,方便日后hotfix等。

2.1K30

DevOps: 项目多环境配置和健康检查

git分支管理 根据每个环境打不同的包,发布一个新的feature到生产需要类似下面这样的流程: 首先用 develop 分支 打包,发布sit环境,测试通过合并到 release 分支; 然后用 release...分支 打包,发布到uat环境,测试通过合并到 master 分支(打 tag); 最后用 master 分支 打包,发布到生产环境。...打一个包发布所有环境以后,分支管理模式将改为: 功能在feature分支自测成功以后,将代码合并到release分支,测试人员在release分支测试并最终发布生产。...当代码成功发布生产以后,将release分支代码合并到master 分支。 ? 上图演示了多环境多包发布和多环境单包发布的简要流程,下面做一下补充说明。...使用release分支打的包发布成功以后,会将release分支的代码merge到master分支备份,方便日后hotfix等。

97840
  • 您找到你想要的搜索结果了吗?
    是的
    没有找到

    Git Flow 的正确使用姿势

    发布完毕之后删除对应功能的feature branches分支。 release branches核实无误,将代码合并到master分支中,并打上对应的tag,最后将tag发布到线上。...得到允许发布到线上的命令之后,将release branches代码合并到master分支,并打上tag记录。 将上线版本对应的feature branches删除。...测试人员在dev环境中,将feature_v1_test3版本功能测试完毕后,开发人员将feature_v1_test3分支合并发布到release分支。...release分支最后检测发现有bug,在release分支进行bug修复,修复完毕后合并到dev中 release分支最后验收完毕,将release分支合并发布到master上线。...release预发布测试bug是否正确被修复,测试通过则将release分支发布到master分支上线。 发布成功之后,则将bug分支删除,一般情况下,bug分支不需要发布到远程仓库中。

    1.4K20

    Git 分支管理策略汇总

    原文链接: Git 分支管理策略 最近,团队新入职了一些小伙伴,在开发过程中,他们问我 Git 分支是如何管理的,以及应该怎么提交代码?...master 分支的代码永远是稳定的,可以随时发布到生产环境。 develop develop 分支用于日常开发,保存了开发过程中最新的代码。...如何进行线上 bug fix 在发布时打上 release tag,一旦发现这个版本有问题,如果这个时候 master 分支上没有其他提交,可以直接在 master 分支上 hot fix,如果 master...分支已经有了提交就要做以下四件事: 从 release tag 创建发布分支。...在 master 上做 bug fix 提交。 将 bug fix 提交 cherry-pick 到 release 分支。 在 release 分支再做一次发布。 线上 fix 通常都比较紧急。

    1.2K10

    开发流程与版本管理规范(下)

    紧急修复分支 起源分支: master 合并对象分支: develop 和 master 命名规则: hotfix-* 紧急修复分支跟 release 分支类似,都是为发布版本准备的。...当线上生成环境有重大的 bug 需要紧急修复,而此时 develop 分支还不稳定,无法发布,我们在 master 分支基础上创建一个 hotfix 分支, 修复 bug 后合并到 master ,再发布到生成环境...三.如何保障代码质量 开发过程中我们采用自动化的单元测试与人工代码审查相结合的方式来保障代码质量 目前这两项工作刚开始实施,需要一段时间磨合团队。...代码审查 往代码库的 develop, release, master 分支合并分支前,必须对修改进行审查。...请求通过先发布到预生产环境,在预生产环境中再次测试,确认没有影响版本发布的问题,产品发布到生产环境。如果存在影响发布的问题,立即终止本次发布,修改存在的问题,再次测试,提起发布流程。

    1.8K20

    Git分支使用规范

    主分支 master分支 master分支存放的是随时可供在生产环境中部署的稳定版本代码 master分支保存官方发布版本历史,release tag标识不同的发布版本 一个项目只能有一个master分支...仅在发布新的可供部署的代码时才更新master分支上的代码 每次更新master,都需对master添加指定格式的tag,用于发布或回滚 master分支是保护分支,不可直接push到远程仓master...分支 release分支可以从develop分支上指定commit派生出 release分支测试通过后,合并到master分支并且给master标记一个版本号 release分支一旦建立就将独立,不可再从其他分支...通过在release分支上进行这些工作可以让develop分支空闲出来以接受新的feature分支上的代码提交,进入新的软件开发迭代周期。...(遵循GitHub语义化版本命名规范) 版本号仅标记于master分支,用于标识某个可发布/回滚的版本代码 对master标记tag意味着该tag能发布到生产环境 对master分支代码的每一次更新(合并

    56631

    git分支管理和工作流规范:具体规范

    前一篇介绍了 git相关的概念,我们可以查看文件的状态,在各个状态之间进行切换,可以创建和合并分支,通过rebase还可以整理自己的提交历史。通过这些命令和操作,就可完成工作流规范规定的操作流程了。...一个版本的release分支、hotfix分支开发完成后,会合并代码到master分支,也就是说master分支主要来源于release分支和hotfix分支。...以release分支代码为基准提测,测试过程中若存在bug需要修复,则直接由开发者在release分支修复并提交。...测试完成之后,合并release分支到master和develop分支,此时master为最新代码,用作上线。...git flow release finish r1 完成release分支,会合并release分支到master分支,用release分支名打Tag,合并release分支到 develop分支,最后移除

    2.5K60

    基于 git flow + gitlab 协作开发:02 解决问题

    本文主要对上一篇文章中提到的问题解决方案做细化,让大家可以清楚的知道如何通过合理的 git 工作流来解决这些问题,让原来发布时的手忙脚乱不再出现。...通过 git flow 我们可以对项目做一个分支模型管理: master 固定,一致保持当前最新稳定的发布版本代码,在 CI/CD 建设时,你可以只在该分支做签名、公证等一系列自动化流程 develop...到 master 分支 创建 8.0.0 tag 合并 8.0.0 tag 到 develop 分支 整个 release 版本发布的阶段,转化为 git 的原生指令他是这样一个步骤: # 当前工作与...另外我更建议在 release/* 分支做版本发布,而不是 master 分支,master 分支仅作为一个备份分支,他在一些开源项目中显得比较重要,因为他代表着最新稳定分支。...在团队协作过程中,hotfix/* 分支开启后,需要在该分支中提测和测试,在确保无误后再合并到 support/* 分支确保。

    1.1K10

    Git设置分支保护实现CodeReview卡点

    GitFlow模式的各分支说明 1) master 主分支 , 产品的功能全部实现后 , 最终在master分支对外发布 该分支为只读唯一分支 , 只能从其他分支(release/hotfix)合并 ,.../master分支并推送 , 打Tag 属于临时分支 , 补丁修复上线后可选删除 所有hotfix分支的修改会进入到下一个release GitFlow 主要的工作流程 代码仓库的Owner设置master...4) 从dev拉取release分支进行提测 , 提测过程中在release分支上修改BUG,release分支名字是release。...9) 当进行一个release分支时 , 若dev分支有变动 , 如其他开发人员完成功能并上线 , 则需要将完成的功能合并到自己分支上即合并dev到当前release分支 (因为当前release分支通过测试后会发布到线上...在Git的分支合并过程中支持方式,一种是在本地将source branch 合并到 target branch,然后再切换到target branch后将target branch push到远端target

    1.7K30

    Git flow 规范

    1.3 Develop分支不直接合并到Master分支,其通过Release分支合并到Master分支。 1.4 Master分支与线上版本保持一致。...1.5 Develop分支是自动构建分支,它总是保有当前即将发布或是已经发布的代码,是确定的下一次将要通过Release分支合并到master上的代码。...到Master和Develop, 同时在Master分支上打个Tag记住Release版本号,删除Release分支。...4 临时分支hotfix hotfix分支基于Master分支创建,开发完后需要合并回Master和Develop分支,同时在Master上打一个tag Git Flow 抽象模型 在使用的过程中一定要注意到数据流的流动方向...4 在Release上完成次要bug修复、发版配置等之后,便可合并到Develop与Master(Master上的合并需要加上tag)。

    3K30

    Git Flow 工作原理

    不能直接在master 分支上进行commit文件。因为是稳定的版本,所以每次版本发布都要在这个分支上添加标签(tag)。...所以从master分支上切出一个分支,修复完成之后合并到master分支,并且合并到develop上。 release 分支 release 分支可以称之为预发布的版本。...当我们认为develop版本的代码已经趋于成熟,我们可以打一个release分支。在release 分支上测试完成之后,要将代码合并到master分支和develop上。...master 分支是线上版本,而合并到develop版本是因为,在测试过程中,一些细节的东西可能会修改,因此这些优化的内容也应该合并到最终版本以及开发版本中。...分支名打 Tag 归并 release 分支到 'develop' 移除 release 分支 git flow release finish RELEASE 4、bugfix 分支操作 紧急修复的需求

    606132

    团队项目的 Git 分支管理规范

    如何有效地协同开发人员在开发、测试、上线各个环节的工作,可能都有各自的流程与规范。...release:发布分支,用于代码上线准备,该分支从 develop 分支创建,创建之后由测试人员发布到测试环境进行测试,测试过程中发现 bug 需要开发人员在该 release 分支上进行 bug 修复...,修复完成自测没问题后,在上线之前,需要合并该 release 分支到 master 分支,同时需要再合并该分支到 develop 分支。...测试完成后,从 release 分支合并到 master 分支,基于 master 分支构建生产环境完成上线,并对 master 分支打 tag, tag 名可为 v1.0.0_2019032115(即...,验证通过后再合并到 master 分支上线),合并时参考“正常开发流程”。

    4.3K12

    版本分支管理标准 - Trunk Based Development 主干开发模型

    大量的团队在实践过程中也遇到了颇多问题,其中大部分来自长期存在的分支。...开发新功能时从 master 分支上拉取 feature 分支,开发完成后发起 Pull-Request ,小组内进行评审和反馈,此时也进行 Code Review 。测试通过后合并回主分支。 ?...如何进行线上 Bug Fix,答案是在发布时打上 Release Tag,一旦发现这个版本有问题,如果此时 master 分支还没有其他提交,那可以直接在 master 分支上 Hot Fix 然后合并至...release 分支;如果 master 分支已经有了提交就需要做以下三件事: 从 Release Tag 创建发布分支。...在 master 上做 Fix Bug 提交。 将 Fix Bug 提交 Cherry Pick 到 release 分支。 为 release 分支打上新的 Tag 并做一次发布。

    6.1K31

    团队如何选择合适的Git分支策略?

    由于很容易创建新分支,分支多了如何管理,时间久了,如何知道每个分支是干什么的? 哪些分支已经合并回了主干? 如何进行Release的管理?...,一切就绪后将Release分支合并回master主分支并打上相应的版本号标签(Tag),同时也合并回develop分支。...为了共用主分支上的最新代码以及避免合并代码时解决代码冲突引起的额外开销,在功能开发过程中Feature分支需要始终与master保持同步。...在每个Release分支正式发布前可能还需要将主分支上的一部分关键问题的修复选择性地同步(Cherry-pick)到Release分支,这个操作也是由SCM完成。...Release分支上的工作一切就绪并通过系统集成测试后,SCM在Release分支上打上相应的版本号标签(Tag)进行发布,这点和Git flow在主分支上进行发布不同。

    83460

    团队如何选择合适的Git分支策略?

    ,一切就绪后将Release分支合并回master主分支并打上相应的版本号标签(Tag),同时也合并回develop分支。...为了共用主分支上的最新代码以及避免合并代码时解决代码冲突引起的额外开销,在功能开发过程中Feature分支需要始终与master保持同步。...在每个Release分支正式发布前可能还需要将主分支上的一部分关键问题的修复选择性地同步(Cherry-pick)到Release分支,这个操作也是由SCM完成。...Release分支上的工作一切就绪并通过系统集成测试后,SCM在Release分支上打上相应的版本号标签(Tag)进行发布,这点和Git flow在主分支上进行发布不同。...分支,并打上新的版本号标签(Tag)用于发布,同时代码也需要合并回master以确保主分支的健壮性。

    78700

    如何构建基于Git的开发工作流规范?Git版本管理工具应该这样用

    场景: 前端应用会跟随工作宝版本迭代, 在dev分支测试稳定后, 会合并到master分支, 并使用tag标记应用版本和对应的工作宝版本 tag规范: v{APP_version}@{GZB_version...开发者如果在该分支进行了提交,在push到远程之前应该先pull一下, 并尽量使用rebase模式,保证分支的简洁 命名规范: dev tag规范: 在dev分支中也可能会经历发布过程, 例如bug修复版本...flow 风格的release分支 当前前端应用的稳定版本和GZB版本绑定. release分支不一定存在, 一般情况下, 只会在前端版本稳定后, 将其合并到master, 并创建tag标记....版本 如何修复 如果对应bug可以在dev分支直接被修复, 可以先提交到dev分支(或者已经修复了), 然后再cherrypick到release分支 如果bug在新版本无法复现....表示实际部署到生产环境的版本. 如果test版本测试通过, 就会成为生产版本. 这个过程是通过将dev分支合并到master分支时实现的.

    1.3K30

    gitflow 开发流程学习(第二部分)

    标签不一定是打在 master 分支上,也可以在其他分支,但是 master 分支的 tag 有特殊意义,代表的是这个项目的代码的发布版本,因为发布代码会使用 master 分支进行发布。...例如回到前文的真实应用案例(tag 都是在 master 分支上): 第一个标签是在项目开始的时候初始化之后,作为版本 v0.1,可以加速备注,说明这是项目初始化。...回到之前的项目开发例子,在引入 release 分支之后是这样,在开发完文章和登录功能后,代码都合并到 develop 分支之后,会从当前的 develop 分支新建一条 release 分支: //...(qa 或者开发者 leader)和将其 release-0.2 分支合并到 develop 分支和 master 分支,保证该版本在开发分支和主发布分支(master)上是一致的。...合并结束后,开发者 leader 会对当前的 master 分支打一个 tag,例如 v0.2,就可以代表可以发布的版本了,部署人员就可以使用这个 tag 的代码进行发布了。

    47160

    2020-09_Git 使用规范流程

    Git 使用规范流程 在开发过程中,遵循一个合理、清晰的GIT使用流程,是至关重要的。否则,每个人都提交一堆杂乱无章的commit,会增加后期协调和维护的复杂度。 分支提交流程图示 ?...合并到 master 分支的代码,必须保证充分的测试 tag tag 为master 分支部署到生产环境后,在master分支节点上标注的一个标签。...第二章 版本管理 一 发布流程 develop 分支切出 release 分支 release 分支更改版本号并提交 release 分支合并至master 分支 master 分支推送至远程仓库 在...若由一人修复缺陷,则直接在hotfix/1.1.1 分支上提交代码,待所有问题修复完毕且测试通过,将hotfix/1.1.1 合并至master 分支并打上tag推送至远程仓库。...若由多人修复缺陷,则每人分别从 hotfix/1.1.1 分支上切出分支提交代码,再合并至hotfix/1.1.1 分支,待所有问题修复完毕且测试通过,将hotfix/1.1.1 合并至master 分支并打上

    1.1K30

    架构师分享 高效团队的gitlab flow最佳实践

    对话过程中,你还可以不断提交代码。 第四步:你的Pull Request被接受,合并进master,重新部署后,原来你拉出来的那个分支就被删除。(先部署再合并也可。)...对于”持续发布”的项目,它建议在master分支以外,再建立不同的环境分支。...开发完成后,在迭代结束前,合入master分支 master分支合并后,自动cicd到dev环境 开发自测通过后,从master拉取要发布的分支,release-$version,将这个分支部署到测试环境进行测试...测试发布 master分支,自动部署到开发环境(dev) 功能开发完成,并自测通过后,代码合并到待发布版本, 分支规则: release-version 版本规则 主版本号.次版本号 构建时,自动增加修订号...bug修复 需要修改bug时,从release-version新拉分支,修改完成后再合并到release-version分支. Q: 从release-$version拉的分支,如何测试?

    4.3K10
    领券