中国核工业华兴建设公司网站,如何制作多网页网站,网站解析查询,新的房地产网站怎么做SEO想了很久#xff0c;还是写这么一篇文章来总结一下有关分支策略和DevOps的一些内容吧。其实#xff0c;DevOps相关的内容并不是我的工作范围#xff0c;不过对于敏捷开发、DevOps、项目管理等等这一系列的与开发过程相关的内容#xff0c;我还是有些经验的#xff0c;也就… 想了很久还是写这么一篇文章来总结一下有关分支策略和DevOps的一些内容吧。其实DevOps相关的内容并不是我的工作范围不过对于敏捷开发、DevOps、项目管理等等这一系列的与开发过程相关的内容我还是有些经验的也就抽时间跟大家分享一下吧。Git Flow应该是很多基于Git分布式版本控制系统的项目所实践的一种开发流程当然很多人对于Github非常熟悉甚至平时工作就是基于Github的。在此我也就不多介绍Git以及Github的概念了只需要知道Github是基于Git的一个服务供应商目前已被微软收购。Git Flow就是由Vincent Driessen基于Git这一版本控制系统所总结出来的一套可行的、能够满足很多项目开发需求注意不是大多数项目的敏捷开发流程英语水平好的朋友可以参考阅读Vincent的原文《A successful Git branching model》。Git Flow通常会用在有具体的release发布的概念的项目上简言之就是类似于以前能够给客户提供安装包的项目对于SaaS项目Git Flow还是太重了而且不同环境、多租户的部署策略也与Git Flow有一些差别。因此团队还是应该根据自己的实际情况来选择合理的开发流程这里所介绍的内容也是仅供参考。下图来自《A successful Git branching model》一文展示了Git Flow的整个流程在这里我会对这个流程做一个详细的介绍。master分支master分支始终保持了最近一次发布release的代码通常情况下通过tag的方式来标记每一次release。在Github中每创建一次release就可以基于某个分支branch创建一个tag。在tag被创建后分支是可以删除的。因此我觉得在上面的模型中维护一个master分支并不是必需的。所以有些团队为了直观会将develop分支作为默认分支甚至删除master分支。但我觉得删不删除也都无所谓直接将master分支作为开发分支也就是合并develop和master的职责也是可以的。develop分支与feature分支develop分支或者master分支是项目开发的主要分支它包含了项目的最新代码开发和测试团队都会基于develop分支进行工作。每当有新的功能需要开发时都会从develop分支分出一个feature分支。从实践的角度上图中分主体功能的feature分支Major feature for next release以及后续版本的feature分支Feature for future release实际上出现后续版本的feature分支的可能性不会太大由于采用敏捷开发团队通常不会做三个月以上的项目计划因为没有意义没有人能够确保三个月之内不会有功能需求的变更、backlog的调整以及市场对于项目本身的影响因此相对而言近期的版本发布目标应该是比较明确的长远的计划反倒显得意义不大。不过也有可能会让团队的部分成员提前进入下一版本的研发但由于敏捷开发和微服务理念的引入一般敏捷团队也不会特别庞大所以这样的活动也不太会频繁发生。当然还是应该依据项目实际情况而定如果真有部分成员提前进入下一版本开发的需要那就按上图中所描述的流程进行即可不会有什么大问题多个feature并存的可能性还是很大的团队的不同成员会工作在不同的feature分支上当每个feature完成之后都会合并到develop分支。合并过程可能会出现代码冲突每个成员是直接将代码提交到feature分支还是自己再基于feature分支创建自己的工作分支这取决于团队的代码审核Code Review流程如果团队有严格的代码审核流程开发人员应该在进行开发工作之前基于feature分支创建自己的工作分支。开发完成后将代码push到远程然后提交Pull RequestPR并邀请团队进行Code ReviewReview通过再将代码合并到feature分支代码合并之后将自己的工作分支删掉即可。如果代码审核流程不严格那么直接将代码push到feature分支也是可以的这需要团队成员建立起互信机制并且有高度自治Self-organize的能力。这里有两点可以多写几句首先不要觉得重复创建、删除分支会带来很大压力Git的分支是非常轻量的需要的时候就创建不需要就删除非常方便其次很多持续集成系统对于多分支的开发流程以及Pull Request/Code Review流程都有完美的支持Azure DevOps的这部分功能使用起来也是非常方便之后我会详细介绍持续集成系统会从各feature分支上拉取代码进行编译然后自动化部署到开发环境进行冒烟测试Smoke Test便于开发人员尽早验证已开发的功能。如果验证通过开发团队可以将feature分支合并到develop分支并删除feature分支然后进行下一个feature的开发持续集成系统会从develop分支上拉取代码进行编译然后自动化部署到测试环境供测试团队QA进行测试最后给Product Owner或者其他Stakeholders做演示的环境也是从develop分支出来的release分支当所有计划好的feature都完成之后团队会基于develop分支创建release分支此时持续集成系统会基于release分支产生新的构建构建结果称为Beta构建Beta Builds测试团队QA基于Beta构建进行回归测试Regression Testingrelease分支不接受任何新的功能增加开发团队在release分支上进行Bug修复同样修复Bug时是否需要创建自己的代码分支取决于团队自己的决定当质量达标团队验收之后进入release流程此时基于release分支创建release tag同时将release分支合并回develop分支以将release分支中的bug修复带入develop分支。在建完release tag并将代码合并回develop分支后可将release分支删除。上图中没有体现这一步上图中展示的是将release分支合并到master分支然后在master分支上建release tag这样做是不妥的因为合并到master分支的代码并没有经过测试所以release tag不能建立在master分支上hotfix分支在某个版本发布之后有可能会得到用户的反馈有些是功能性的有些则是影响用户使用的问题。对于功能性的反馈可以与用户商量或者团队自己决定是准备在下一个版本中加入还是基于用户现在的版本为用户专门定制。如果是后续版本再支持则遵照上述feature分支的策略即可但如果是基于用户现在使用的版本进行定制则需要走Hotfix的流程Hotfix分支从已经release的tag创建找到已有的tag然后基于tag新建Hotfix分支即可Hotfix分支的工作流程可以参考develop分支Hotfix开发完成并检验通过之后基于Hotfix分支创建tag标记为某一个Hotfix根据当前所修复的问题是针对该特定用户的比如在界面上增加用户公司的名称与logo还是针对所有用户的比如某个bug的修复以此决定是否需要将改动合并到develop分支删除Hotfix分支从上面的流程可以看出除了develop分支或者master分支为长期存在的分支之外其它的分支都为辅助分支在工作完成之后可以立即删除。为了满足代码评审Code Review而创建的开发人员自己的分支一般都是即用即删。以上就是Git Flow的整个流程应该是已经介绍的比较细致了。在平时的工作和自学中我都是以Github作为代码托管平台的因此本文的内容仍然是以Github为基础包括接下来有关Azure DevOps Pipeline的介绍也是与Github进行集成的。在上面的介绍中不止一次提到持续集成系统比如当有代码签入feature分支或者develop分支时持续集成Continuous IntegrationCI系统会自动进行编译然后触发持续发布Continuous DeliveryCD系统完成自动化部署。这些CI/CD系统所执行的自动化任务需要人为地反复定义并触发吗其实并不需要。现在流行的持续集成系统基本都已成熟比如Jenkins它的Pipeline功能直接支持Multi-Branch每当有新的分支创建或者代码签入都会触发Jenkins创建新的Job并触发相应的CI任务。Azure DevOps在这部分也做得非常好而且它是云端服务简单易用对于开源项目是完全免费的。首先当你在Github中新建了一个repo并且在Azure DevOps中配置了一个Project使其从Github拉取代码时你会发现Github repo的Webhook里已经自动为你加上Azure DevOps所需的Webhooks不用管它我们设想两个场景当开发人员准备向feature分支合并代码时当feature分支出现代码签入时下面看看如何在Azure DevOps中进行配置以实现上述两个场景。在这个实验中我的Github Repo有三个分支master暂时没用到dev开发主线保持了最新代码features/a1功能代号为a1的开发分支目前团队都在集中开发features/a1功能由于团队选择较为严格的Code Review流程因此开发人员在进行自己工作之前都是从features/a1创建自己的工作分支比如就叫features/a1-daxnet吧以便在代码签入features/a1分支的时候能够产生Pull Request并申请代码审查。工作分支的名称可以自己决定但团队需要达成共识因为这个名称之后会被Azure DevOps用到。现在进入Github Repo的Settings页在Branches设置页面中在Branch protection rules设置下新建一个规则Rule在Branch name pattern中输入features/a1也可以使用规则来定义一组分支然后勾选Require status check to pass before merging注如需Code Review则还需要勾选Require pull request reviews before merging在这里就不演示了。然后回到Azure DevOps针对Github Repo创建CI在CI的Trigger选项中启用Continuous integration以保证每当有代码签入指定的分支就会触发持续集成。在Branch filters中添加features/*分支表示以features作为开头字符的所有分支都需要进行持续集成确保编译通过启用Pull request validation在Branch filters中添加features/a1表示当有Pull Request需要合并到features/a1分支时也需要进行持续集成以确保编译通过。注意目前我们不涉及Repo被Fork的情况所以我们不勾选Forks选项OK基本设置就是这样非常简单。接下来我们开始开发新的功能。首先在Github页面基于features/a1创建分支features/a1-daxnet刚刚创建完新的分支Azure DevOps就已经开始工作了可以看到Build Pipeline已经完成了新分支的编译下面我要开始修改代码了在代码修改完成本地编译通过之后我将代码提交到features/a1-daxnet分支再次查看Azure DevOps的Build Pipeline可以看到CI已经开始帮我们编译新的代码提交了OK再次不管它现在我希望将代码合并到features/a1分支于是我到Github上创建Pull Request此时Github会提示代码校验还在进行中并等待Azure DevOps的编译结果回到Azure DevOps可以看到Build Pipeline正在进行Pull Request编译等待编译成功后开发者就可以将代码合并到features/a1分支了。当然这里我没有强制要求必须要等代码编译成功才能合并分支因此即使是编译没有完成上图中的Merge pull request的按钮也是可用的。本文首先介绍了Git Flow分支策略并结合了实际应用介绍了Git Flow的详细步骤然后基于Azure DevOps介绍了在实际应用中Azure DevOps Build Pipeline对Git Flow的支持。本文所介绍的内容并不能完全适用于所有的软件项目尤其是SaaS项目所以在开发过程中团队还是应该根据自己的实际需求来定制自己的开发流程在保证软件质量的前提下提高开发体验和团队生产力探索寻求适合自己的实践流程。原文地址http://sunnycoding.cn/2019/03/23/git-flow-and-azure-devops/.NET社区新闻深度好文欢迎访问公众号文章汇总 http://www.csharpkit.com
