Java开发网 - 版本控制难题求解

Java开发网

您没有登录

» Java开发网 » Design Pattern & UML

打印话题 寄给朋友 订阅主题

作者

版本控制难题求解

dissip

BigCat

发贴: 240
积分: 60

于 2005-10-12 21:09

我们为integration test, uat（user acceptence test） , production在版本控制工具中创建了不同的branch,
比如，在一个enhancement项目完成后(我们有几个项目并行)，把项目改动的源码merge到integration test branch 上，打tag/baseline，然后做测试；测试成功后，把代码从integration test branch merge到uat branch上，打tag/baseline，然后做uat；用户确认后，把代码从uat branch merge到production branch上, release team从production branch上check out, build, deploy.

我的问题是：由于项目的复杂性等的差异，项目uat的时间不同，就可能会出现后merge到uat branch 上的项目代码，可能比先merge(到uat branch 上)的要求更早release到production . 如果直接按UAT branch 的tag做merge到production branch, 会包含并不需要的feature. 如果做减量merge(把UAT branch中不需要的feature 减去),后release，会有风险，因为先前做的integration test, uat 都没测过这种code.

不知您对这个问题是怎么看的？有什么意见？

To live is to fight.

作者	Re:版本控制难题求解 [Re:dissip]
dissip BigCat 发贴: 240 积分: 60	于 2005-10-13 16:37 难道没人愿发言? dissip edited on 2005-10-13 19:33 To live is to fight.

作者

Re:版本控制难题求解 [Re:dissip]

floater

Java Jedi

总版主

发贴: 3233
积分: 421

于 2005-10-13 20:47

就可能会出现后merge到uat branch 上的项目代码，可能比先merge(到uat branch 上)的要求更早release到production

should avoid this kind of behavior, through a better planning. Fool me once, it's your fault; fool me twice, it's my fault, Tounge

.

If unavoidable, create different branches after integration and before uat so that you can selectively merge anything version.

"Any fool can write code that a computer can understand. Good programmers write code that humans can understand."
- Martin Fowler, Refactoring - Improving the Design of Existing Code

作者

Re:版本控制难题求解 [Re:floater]

dissip

BigCat

发贴: 240
积分: 60

于 2005-10-14 09:38

Thanks for your reply. that's why i post the question in your column. Smile

floater wrote:
should avoid this kind of behavior, through a better planning. Fool me once, it's your fault; fool me twice, it's my fault, .

I thinkd this kind of thing is unavoidable. it's because user acceptence test mainly depends on the users.
suppose project 1 has a relatively fundamental change to a function. and we need time to train a lot of users to get used to it before production and verify whether it meets the majority of the user's needs. e.g. it tooks 2 weeks to finished the job. another project 2 is a simple enhancement that change a report layout, only a few user use it. it takes only a few days for users to test it. so if project 2 release to uat just after project 1, 2 will request to release earlier than 1. if these 2 projects are the only projects, i think we can arrange the test to avoid such colission. but there are several concurrent projects and it's really hard to avoid all of them.

floater wrote:
create different branches after integration and before uat so that you can selectively merge anything version.

by integration, we mean to eliminate all technical defects.
by uat, we mean to get user's approval to release to production.
use the former example, if p1 and p2 have dependency, there will definitely be a plan about the 2 project's release time. if the 2 projects don't have dependency, i don't understand what you mean by 'create different branches after integration'. would u please explain it?

To live is to fight.

作者	Re:版本控制难题求解 [Re:dissip]
floater Java Jedi 总版主发贴: 3233 积分: 421	于 2005-10-14 10:56 "Any fool can write code that a computer can understand. Good programmers write code that humans can understand." - Martin Fowler, Refactoring - Improving the Design of Existing Code

作者

Re:版本控制难题求解 [Re:dissip]

floater

Java Jedi

总版主

发贴: 3233
积分: 421

于 2005-10-14 11:07

you just create two branches between int and uat(Both charts are not very accurate in the sense that there is a time lagging between consecutive merges).

I like another approach - for each project, create int, uat, and prod branches, and then eventually merge prod into head.

"Any fool can write code that a computer can understand. Good programmers write code that humans can understand."
- Martin Fowler, Refactoring - Improving the Design of Existing Code

作者

Re:版本控制难题求解 [Re:floater]

dissip

BigCat

发贴: 240
积分: 60

于 2005-10-23 14:02

floater wrote:I like another approach - for each project, create int, uat, and prod branches, and then eventually merge prod into head.

Are your system cliearly modularized?
how much modules does a project, as you refer to, include? 1 module per project or 1 biz function(several modules) per project?

if the later, there may by some modules shared by paralell projects. without central control/test before production, these changes may controdict each other and made production fails. what's your opinion?

dissip edited on 2005-10-23 14:04

To live is to fight.

已读帖子

新的帖子

被删除的帖子