版本与迭代、发布的关系
pjw
|
关于“版本”的设计讨论: 版本,有集成版本和非集成版本。非集成版本,必须关联迭代处理,为什么设计成这样? 版本为什么不能只关联产品分支(产品型项目),或只关联项目(项目型项目)? 目前的设计,如果迭代周期短,则不能提前设置版本,难以使用版本来提前做“版本计划”和“测试计划”。 要建好迭代,才能做版本计划。 并且,间接地限制了迭代必须足够大,否则可能多个迭代才能完成一个版本,此时操作极其麻烦,反复切换版本与迭代的关联,同时还要处理关联的需求、缺陷等等。(大的迭代,可能导致工时估算、燃尽图,等功能的存在意义和作用都降低) 问题1: 在项目视图创建 发布时,不关联版本,默认会关联主干(项目关联的是其他分支), 修改这个“发布”时,无法再关联其它分支,也无法修改关联其它分支的需求或版本。 问题2: 集成版本,创建时不能选分支,默认为主干。 建一个非集成版本,在项目视图不能修改该版本为集成版本; 但在迭代视图,可以把版本的关联迭代去掉,保存后自动变为集成版本,并且此时该版本的关联分支是之前分支,而不是默认为主干。 (建议去掉 版本 与 迭代 的关联,或把版本的所属迭代,改为非必填项) |
王林
|
你好 禅道中非集成版本是指项目下某个迭代中完成的需求和解决bug进行测试时打包的版本。 其实都是在某个迭代下进行管理的,可以从某个迭代-版本进行创建,也可以在项目-版本创建时选择到某个迭代上。 集成版本是指项目下对某几个迭代完成的需求和解决的bug进行集成测试时打包的版本。所以集成版本这里可以不选择具体迭代。 如果咱们不是在每个迭代完成部分功能后就打包版本进行测试,而是多个迭代完成后集中打包测试的话,可以在项目下创建集成版本,然后关联相应的需求和bug。 咱们这里的“版本计划”和“测试计划”是否是指发布的计划?如果是的,可以在产品-计划中对产品的版本发布进行创建计划。如果计划按期完成,可以在产品下创建对应的发布。项目、迭代中的版本,更多的是对已完成的需求和解决的bug限定一个测试范围创建版本后,对版本进行提交测试。 另外,如果咱们的一个项目就是一个迭代的话,也可以在创建项目时勾选不启用迭代概念,这样进入项目后可以直接在项目下创建任务、版本等信息,不需要再单独创建迭代。 产品或项目发布时,通常建议是对某个版本进行发布的。项目创建发布时不关联版本,会默认关联到产品主干上的问题,我们记录下反馈。 目前发布后是无法再编辑修改关联的产品分支的。 |