小编Dav*_*Lin的帖子

我们的开发团队一直在使用GitFlow分支策略,它一直很棒!

最近我们招募了一些测试人员来提高我们的软件质量.这个想法是每个功能都应该由测试人员测试/ QA.

过去,开发人员在单独的功能分支上处理功能,并develop在完成后将它们合并回分支.开发人员将在该feature分支上自行测试他的工作.现在有了测试人员,我们开始问这个问题

测试人员应该在哪个分支上测试新功能？

显然,有两种选择:

• 在个别功能分支上
• 在develop树枝上

测试开发分支

最初,我们相信这是肯定的方法,因为:

• develop自开发开始以来,该功能已与所有其他功能合并到分支进行测试.
• 任何冲突都可以在以后检测到
• 它使测试人员的工作变得轻松,他只是在处理一个分支(develop).他不需要向开发人员询问哪个分支是针对哪个功能的(功能分支是由相关开发人员独立管理的个人分支)

最大的问题是:

• 该develop分支被污染与臭虫.

  当测试人员发现错误或冲突时,他会将它们报告给开发人员,开发人员会在开发分支上修复问题(功能分支在合并后被放弃),之后可能需要更多修复.多个子序列提交或合并(如果develop再次在分支上重新创建分支以修复错误),develop如果可能的话,从分支回滚功能非常困难.develop在不同时间有多个功能合并到分支并在其上固定.当我们想要创建仅包含develop分支中某些功能的版本时,这会产生一个大问题

功能分支测试

所以我们再次思考并决定我们应该在功能分支上测试功能.在我们测试之前,我们将更改从develop分支合并到功能分支(赶上develop分支).这很好:

• 您仍然可以使用主流中的其他功能测试该功能
• 进一步的开发(例如错误修复,解决冲突)不会污染develop分支;
• 在完全测试和批准之前,您可以轻松决定不发布该功能;

但是,存在一些缺点

• 测试人员必须合并代码,如果有任何冲突(非常可能),他必须向开发人员寻求帮助.我们的测试人员专门从事测试,无法编码.
• 可以在不存在其他新功能的情况下测试功能.例如,特征A和B同时都在测试中,这两个特征彼此不知道,因为它们都没有合并到develop分支.这意味着,develop无论如何,当两个功能都合并到开发分支时,您将不得不再次测试分支.你必须记得将来测试这个.
• 如果功能A和B都经过测试和批准,但在合并时发现冲突,两个功能的开发人员都认为这不是他自己的错误/工作,因为他的功能分支超过了测试.沟通会产生额外的开销,有时解决冲突的人会感到沮丧.

以上是我们的故事.由于资源有限,我想避免在所有地方进行测试.我们仍在寻找更好的方法来应对这种情况.我很想知道其他团队如何应对这种情况.

背景：

我有一个 Javascript 托管在 S3 存储桶上，带有静态网站 + Cloudfront 分发 + Route 53 设置。我需要 Cloudfront，因为我需要支持 SSL 的自定义域。这工作正常。例如，可以通过https://app.example.org/myscript.js访问该脚本。此 URL 提供给客户以嵌入他们的网页，我无法更改它。

Route 53 中的设置是这样的：

app.example.org => Cloudfont Distribution (s3://app.example.org)

我想要的是：

我想为新功能设置一个临时环境。我想将 10% 的生产请求定向到脚本的另一个版本。

我试过的

我尝试使用不同的备用域名（例如 app-beta.example.org）设置另一个带有静态网站 + cloudfront 的 S3 存储桶。

我需要使用不同的替代子域，因为 Cloudfront 不允许具有多个分配的相同替代域名。

在 Route 53 中，我设置别名 A 记录如下：

app-beta.example.org => Alias Cloudfont Distribution (s3://app-beta.example.org) app.example.org => Alias app-beta.example.org (weighted 10) app.example.org => Alias Cloudfont Distribution (s3://app.example.org) (weighted 100)

为什么没有用

事实证明这是行不通的：

因为请求的域是相同的app.example.org，无论app.example.org => Alias app-beta.example.org.

我认为这里的 …