gitflow，QA，CI/CD在所有环境中部署相同的工件
我认为，构建工件然后在所有环境，测试，预杂种，产品中部署它是个好主意。 但是根据Gitflow，我们使用“释放”分支进行测试，然后将其合并到Main，开发和删除发行分支。因此，我们有“释放”工件并进行测试，但是据我了解，我们部署了从标记的主部门生产工件。对我来说，这很奇怪。 这可能是什么客观原因？
I think that it's good idea to build artifact and then deploy it across all environment, test, preprod, prod.
But according to Gitflow we use "release" branches for tests and we merge it to main, develop and delete release branch. So we have "release" artifact and we test it, but as I understand we deploy to prod artifact from tagged main branch. And for me it's strange.
What could be the objective reasons of this?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
main＆lt; =＆gt;产品
的原因很简单，但是，主分支的通常名称是
master。一个人需要一种简单的方法来引用任何产品所包含的任何东西，因为在hotfixs的情况下，您想从prod中分支，因为那里的问题是可重现的。这是另一回事，通常还有一个用于hotfix的分支。释放分支机构
基本上，您可能会同时开发许多不同的东西。您可能想创建问题空间的分隔良好的分区来定义您的任务，每个分区都代表一个版本。因此，如果您一方面要优化某些业务逻辑，并且另一方面正在抛光UI，那么您不一定会首先发布哪个业务逻辑，因此您将为这些命名分支机构。拥有“释放”分支是这样的惯例。现在，当您部署发布版本时，您可以将
Master合并到您的版本分支中，并执行自动和/或手动测试。成功后，您的发布分支将合并到您的Master分支中。删除释放分支
一旦成功完成了以释放分支代表的工作，在合并后将其删除以避免在不太可能更改的事物上浪费存储空间（因为被接受）是有意义的。请注意，如果以后发行时出现问题，您可以始终
结帐标记的comm释放分支已发布。main <=> prod
The reason for this is simple, however, the usual name of the main branch is
master. One needs to have an easy way to refer back to whatever prod contains, because, in the case of hotfixes, you want to branch out from prod, because the issue is reproducible there. It is another matter that there is usually a branch for hotfixes as well.release branches
Basically, you may have many different things that are being developed at the same time. You probably want to create well-separated partitions of problem-spaces to define your tasks, each such partition would represent a release. So, if you are optimizing some business logic on the one hand and you are polishing the UI on the other hand, then you not necessarily know which one will be released first, so you will have some named branches for those. Having "release" branches is a convention for this. Now, when you are deploying a release to prod, you can merge
masterinto your release branch and perform automatic and/or manual tests. When this is successful, your release branch is merged into yourmasterbranch.Deleting a release branch
Once the work represented by a release branch is successfully completed, it makes sense to remove it after it was merged to avoid wasting storage space on things that are unlikely to change (because they were accepted). Note that if a problem arises with a release later on, you can always
checkoutthe commit hash of the tagged commit that represents the release merge in order to see whether the problem you have seen was already manifesting when the release branch was released.