标签：时间 ide domain oop 开启 自己 技术 条件 代码
各位ABAP公民们、特别是使用abapGit的各位，你们好。
我的团队和我将向大家分享我公司内引入abapGit后产生的某些开发问题。我所在的公司是一家创作SAP第三方软件的公司，目前主要使用ABAP和UI5。
本文专门针对ABAP方面。
首先，我们爱abapGit，相信你们中的很多也是一样...
我们的git仓库使用GitLab托管在本地，有着各种用户友好的特性。
我们至少每天push一次我们的commit，生成版本（可以说是一个额外的备份层）。
通过使用GitLabs的代码审查功能，也使代码审查变得容易了许多。
我们最近评估了使用分支的可能性，得出的结论是：我们不能在现有的基础设施之上使用它。
本文的剩余部分将探究如何使用abapGit实现分支。
本文链接：http://www.cnblogs.com/hhelibeb/p/7754487.html
英文原文：abapGit Branching Strategy Discussion
这就是我们现在的工作方式。所有开发者在相同的SAP系统和代码基础（code base）上工作，所有人都push代码到主“分支”上。
无法马上使用分支的根本原因，在于，所有开发者使用同样的代码基础。开发者没有隔离他们同事的代码修改行为。
所以，实现真正分支的第一步就是，分割每个开发者的开发环境。这意味着，每个开发者要有他自己的SAP系统来进行开发。
这带给我们第一个整体的不利条件：
我们的第一个想法是，为什么不在开发者的机器上虚拟化运行SAP系统呢？
开发者在进行一项任务时，可以push到他们的分支当中，直到它们创建一个merge request。
主开发系统（DEV）只从主分支拉取，主分支只包含被批准的merge request。
某些总体问题也打击了我们：
你还需要一个策略来应对以下问题：
并且，更新的频率是？
升级看起来是个大问题，也许不用一个本地虚拟机、而是托管虚拟机会好点。
这样的话，无论采取何种策略来更新，都可以更轻松地执行。
所以，进行这一切的优点是什么？
我们的看法是：
值得为此做出很多的努力吗？
我们的团队并不知道答案。系统同步带来的成本，看起来是巨大的。
在这点上我们感到不舒服，因此转向社区，希望听到你们在这个话题上的的意见和经验。
非常感谢，
André
标签：时间 ide domain oop 开启 自己 技术 条件 代码
原文地址：http://www.cnblogs.com/hhelibeb/p/7754487.html
