No, a Scrum sprint/iteration is a fixed period of time, and there's no 1:1 correspondence of such amounts of time with tags (or branches, &c) in whatever version control system you prefer.
The use of tags in svn & friends is more of a matter of release engineering (for most SW development shops, at least) than of development process per se.
Of course, nothing stops your specific team from deciding that every releaseable-increment resulting at the end of a sprint must be somehow tagged, but if you reserved tags for only that purpose, you're cramping your release engineering processes unnecessarily.
I think it would be more likely that for each sprint, the development team would be working in a specific subversion branch, which is merged back to trunk at the end of the sprint and a new branch created for the next one. That way, trunk is always keep "clean" with the previous sprint's work in it, allowing you to quickly cut a new release with a bug fix if an emergency arises.
No, but that's not to say that they are unrelated.
A tag equates to a build from your build system. You might use a version number on the tag that equates to an iteration -- let's say you number your releases with a major version number, and you use a "minor" version number that equates to the iteration you're in. So you might be in iteration "1.2", and each tag in SVN would start with a 1.2. Maybe the 3rd number is a build number. It's up to you on the specifics, but you would likely have multiple builds per iteration -- 1.2.1, 1.2.2., 1.2.3, and so on...
Scrum doesn't say anything about the use of a version control system by the team - in fact, Scrum doesn't say anything about technical practices. Scrum just says team must deliver a "shippable product increment" every sprint - that is a version of the product that is fully integrated and meets the definition of DONE.
Now, on the practical side it is quite logical that you want some way of marking in the repository those milestones that represent the product of each sprint. Yes, you can do it with tags and it is quite intuitive - this is how we did it in our team when we still used SVN - but you could also do it differently, I guess. I think it all depends on your particular circumstances and I would leave it to the team to figure this one out. As long as they can reliably produce the source for the product of each sprint any way they achieve it is fine.
We designate a "tag" as our sprint deliverable to be used during the sprint review meeting, but it is never the only tag we create during the sprint. We create a tag as and when we have code that can be tested after integration to our "trunk/master".
发布评论
评论（6）
不，Scrum 冲刺/迭代是一个固定的时间段，并且在您喜欢的任何版本控制系统中，这样的时间量与标签（或分支，&c）都没有 1:1 的对应关系。
svn & 中标签的使用朋友更多的是发布工程的问题（至少对于大多数软件开发商店来说），而不是开发过程本身。
当然，没有什么可以阻止您的特定团队决定在冲刺结束时产生的每个可发布增量都必须以某种方式标记，但如果您仅出于此目的保留标签，那么您就会限制您的发布不必要的工程流程。
No, a Scrum sprint/iteration is a fixed period of time, and there's no 1:1 correspondence of such amounts of time with tags (or branches, &c) in whatever version control system you prefer.
The use of tags in svn & friends is more of a matter of release engineering (for most SW development shops, at least) than of development process per se.
Of course, nothing stops your specific team from deciding that every releaseable-increment resulting at the end of a sprint must be somehow tagged, but if you reserved tags for only that purpose, you're cramping your release engineering processes unnecessarily.
我认为对于每个冲刺，开发团队更有可能在一个特定的颠覆分支中工作，该分支在冲刺结束时合并回主干，并为下一个冲刺创建一个新分支。这样，主干始终保持“干净”，其中包含之前的冲刺工作，使您可以在出现紧急情况时快速发布包含错误修复的新版本。
I think it would be more likely that for each sprint, the development team would be working in a specific subversion branch, which is merged back to trunk at the end of the sprint and a new branch created for the next one. That way, trunk is always keep "clean" with the previous sprint's work in it, allowing you to quickly cut a new release with a bug fix if an emergency arises.
不，但这并不是说它们无关。
标签相当于构建系统中的构建。您可以在标签上使用相当于迭代的版本号 - 假设您使用主版本号对版本进行编号，并使用相当于您所在迭代的“次要”版本号。处于迭代“1.2”中，SVN 中的每个标签都以 1.2 开头。也许第三个数字是内部版本号。具体取决于您，但每次迭代您可能会有多个构建 - 1.2.1、1.2.2.、1.2.3 等等......
No, but that's not to say that they are unrelated.
A tag equates to a build from your build system. You might use a version number on the tag that equates to an iteration -- let's say you number your releases with a major version number, and you use a "minor" version number that equates to the iteration you're in. So you might be in iteration "1.2", and each tag in SVN would start with a 1.2. Maybe the 3rd number is a build number. It's up to you on the specifics, but you would likely have multiple builds per iteration -- 1.2.1, 1.2.2., 1.2.3, and so on...
如果您决定发布，则应该创建一个标签。
在 Scrum 迭代结束时，您将拥有一个可能可交付的产品。这并不意味着您应该释放。
You should create a tag if you decide to release.
At the end of a scrum iteration, you have a potentially shippable product. This doesn't mean that you should release.
Scrum 没有提及团队使用版本控制系统的任何内容 - 事实上，Scrum 没有提及任何有关技术实践的内容。 Scrum 只是说团队必须在每个冲刺中交付“可交付的产品增量”——这是完全集成并满足“完成”定义的产品版本。
现在，在实际方面，您希望以某种方式在存储库中标记那些代表每个冲刺产品的里程碑，这是非常合乎逻辑的。是的，您可以使用标签来做到这一点，而且非常直观 - 这就是我们团队中仍然使用 SVN 时的做法 - 但我想您也可以采用不同的方式。我认为这一切都取决于您的具体情况，我会将其留给团队来解决这个问题。只要他们能够可靠地为每个冲刺的产品提供源代码，无论他们以何种方式实现就可以了。
Scrum doesn't say anything about the use of a version control system by the team - in fact, Scrum doesn't say anything about technical practices. Scrum just says team must deliver a "shippable product increment" every sprint - that is a version of the product that is fully integrated and meets the definition of DONE.
Now, on the practical side it is quite logical that you want some way of marking in the repository those milestones that represent the product of each sprint. Yes, you can do it with tags and it is quite intuitive - this is how we did it in our team when we still used SVN - but you could also do it differently, I guess. I think it all depends on your particular circumstances and I would leave it to the team to figure this one out. As long as they can reliably produce the source for the product of each sprint any way they achieve it is fine.
我们指定一个“标签”作为冲刺交付成果，在冲刺评审会议期间使用，但它绝不是我们在冲刺期间创建的唯一标签。当我们有可以在集成到“主干/主干”后进行测试的代码时，我们会创建一个标签。
We designate a "tag" as our sprint deliverable to be used during the sprint review meeting, but it is never the only tag we create during the sprint. We create a tag as and when we have code that can be tested after integration to our "trunk/master".