TFS2015 + Git门控构建......价值损失 [英] TFS2015 +Git gated builds...value lost
问题描述
据宣布，TFS2015 + Git现在拥有"gated builds"。对于Git。
这只是部分正确而且很多"门"。在当前的实施中，值会丢失。
TFSVC中传统门控版本的价值很多：
1）确保代码通过各种已定义的门在它检查到分支之前是正确的。
这意味着分支机构的代码符合你制定的任何门。
2）你可以扩展那些门不仅仅是编译和测试。它们可以是您的脚本所需的任何内容。
包括正确打包和部署的能力......从而在提交之前确保E2E准备就绪。
3）将提交紧密结合在一起大门，确保更好的可追溯性和代码进展以及过程耦合。
4）可以用作与代码更改和提交过程相关的其他事件的触发器。
<现在，由于在"门"处的微弱尝试，这一切都毁了。使用Git。
我们所能做的就是确保Pull-Request编译并通过测试。 重复....一个"拉请求"，而不是提交。这些都是截然不同的事情，让世界变得与众不同。
这是我们现在失去的真正的大门，它会检入：
1）现在没有办法真正将特定的代码段大规模地定义为特定的定义。您必须更改整个分支策略才能使用它。瘸。 &NBSP;
现在你可以定义1 build def来映射到分支的pull请求。
$
整个分支与git build def一对一映射，它也必须是ENTIRE代码分支到门。 代码子区域的手术门被拧紧，在界面中不可用。
再次，这将强制您将Git分支方案更改为基于组件而不是基于产品，即使您尚未准备好或不愿意走这条路线或者它不匹配与您的开发团队或环境。
或者只是.....你跳过所有类型的构建脚本箍试图完成以前的门的目标....非常具体和灵活。容易出错。▼
2）提交不再与门控构建有关。这是最大的损失之一。您曾经能够在成功登机口结束时依靠签到。这确保了你知道分支机构上的内容是什么。随着大门申请拉取请求，
你现在......只能验证什么等同于"搁置"....在批准之前，在虚拟监狱中进行了一系列更改。如果他们通过了大门，则只有在完全批准并完成了拉动请求后，才会立即签入。这个
"缺口"及时提出了许多风险，打开了打破TFSVC之前紧密耦合的场景。
3）部署大门是危险的。构建增加了一倍。
所以，虽然我曾经在测试和编译代码时使用我的门，然后立即将这些更改快速部署到QA环境中，我再也无法接受风险。 我不能把QA环境代码放在非"真正"的环境代码上。代码分支上的
。这是一个很大的禁忌。
所以我不能从Git gated构建部署，因为它只是给你"希望"的门控代码。在拉动请求批准后，将在未来的某个时间在分支机构上进行。它可以随时以任何理由中止。此外，在等待批准时，
任何其他拉取请求也可以进入，首先获得批准，因此您的环境可能会被搞砸并且与您的代码库不匹配。
另一个损失价值和紧密耦合。
因此，要解决这个问题，我们必须转到"松耦合"。 CI构建。这是TFS平台中提供的关于所有其他构建和源解决方案的门控构建的价值的回归。门控构建。 所以现在，我必须等待
并在代码实际提交时执行CI构建。您可以从任何构建和源系统中获取此信息。 CI是旧消息。
为了动态地构建变化，我现在必须"松散地"。弄清楚上次成功的CI和这个之间发生了什么变化，并希望能够正确地构建和部署它。 我说"松散地"，因为它现在是一个逻辑
的发现游戏，以确保你不会因为你在逻辑上可能选择差异中的错误更改来构建错误的东西而搞砸你的环境。 想想有人删除构建，或者回滚，或者其他任何代码库的情况。你现在必须在逻辑上解决这个问题。而在门控构建之前，确实在提交中发生了变化。没有猜测或弄清楚CI之后的事实。
而且，你现在还需要建立2x（一次拉动请求，一次关于CI），以获得我曾经离开的价值一个手术门。
我强烈建议带回与Git中的提交有关的真正的门控版本，就像在TFSVC中工作一样。
你好russweb，
对于Git ，它是一个分布式版本控制系统，如果我们提交，更改仍然在本地，所以在我看来，gated build是没有意义的。
对于这些与Git Gated构建相关的功能，我建议您提交用户语音
这里。
问候
Starain
It was announced that TFS2015 + Git now had "gated builds" for Git.
This is only partially true and alot of the "gate" values is lost in the current implmentation.
The value of the traditional gated builds in TFSVC were many:
1) Ensure that code passed various defined gates RIGHT before it checked it onto the branch.
This mean that the code ON THE BRANCH was compliant with whatever gates you enacted.
2) You could extend those gates to be more than just compile and tests. They can be whatever your scripting heart desired.
INCLUDING the ability to properly package and deploy...thus ensuring E2E readiness before commit.
3) Tightly coupled the commit with the gates, assuring better traceability and code progression and process coupling.
4) Could be used as a trigger for other events that relates code change and commits with process.
This is all ruined now with the weak attempte at "gates" with Git.
All we can really do is ensure a Pull-Request compiles and passes tests. Repeat.... a "pull request", not a commit. These are very different things, and make a world of difference.
Here is what we lose now w/o a true gate which checks in:
1) there is no way to really gate a specific section of code now to a specific definition at scale. You have to change your entire branching strategy to use it. Lame.
Now you can define 1 build def to map to a branch's pull requests.
The ENTIRE branch maps one to one with a git build def which also has to be the ENTIRE code branch to gate. Surgical gates on sub areas of the code are screwed and not available in the interface.
Again, this will FORCE you to change your Git branching scheme to be component based instead of product based, even if you are not ready or willing to go that route or it does not match with your dev teams or environment.
Or simply.....you jump through all kinds of build script hoops to try and accomplish the goals of what gates used to be....very specific and flexible. Expensive an error prone.
2) A commit no longer relates to a gated build. This is one of the biggest losses. You used to be able to count on a checkin right at the end of successful gate. And this ensured you knew what was on the branch was built. With gates applying to pull-requests,
you are now..only validating what equates to a "shelveset"....A bunch of changes held in virtual jail until approved. If they pass the gate, they are NOT checked in immediately, only after the pull-request is full approved and completed. This
"gap" in time poses many risks and opens scenarios that breaks the tight-coupling we had before with TFSVC.
3) Deploying with gates is dangerous. Builds doubled up.
So, whereas I used to use my gates in both testing and compiling the code, and then immediately deploy those changes to the QA environment rapidly up to date, I can no longer take that risk. I cannot put on the QA environment code which is not "really"
on the code branch. That is a big no-no.
So I cannot deploy from the Git gated build because it only is gating code that you "hope" will make it on the branch at some time in the future upon pull-request approval. It could be aborted at anytime for any reason. Also, as it waits for approval,
any other pull request can also come in, be approved first, and thus your environment could be screwed and not match your code base.
Another loss of value and tight coupling.
So, to work around this, we have to goto "loose coupling" with CI builds. This is a regression in the value that gated builds provided in the TFS platform over ALL OTHER build and source solutions out there. Gated builds. So now, I have to wait
and do a CI build when the code is ACTUALLY committed. You get this out of any build and source system. CI is old news.
To build changes dynamically, I now have to "loosely" figure out what was changed between last successful CI and this one and hopefully get it right and build and deploy it. I say "loosely", because it is now a discovery game of logic
to be sure you dont screw up your environment by building the wrong thing just because you logically may choose the wrong changes in the diff. Think of scenarios where someone deletes a build, or does a rollback, or whatever else to the codebase.You
now have to logically work around this. Whereas before a gated build was EXACTLY what changed in the commit. No guessing or figuring out AFTER the fact with a CI.
And, also you now have to build 2x (one on pull request, one on CI), to get the value I used to get out of one surgical gate.
I would HIGHLY recommend bringing back the real gated builds which related to commits in Git, just like it works in TFSVC.
Hi russweb,
For Git, it is a distributed version control system, the changes still in local if we just commit, so in my opinion, gated build is not make sense.
For these feature related to Git Gated build, I suggest that you could submit the user voice here.
Regards
Starain
这篇关于TFS2015 + Git门控构建......价值损失的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
