项目现在到了后期debug阶段,为了保持发布包的稳定可用,公司先后采用了以下手段:
1、开发人员在向CVS提交代码时描述修改内容和填写的单子号
2、手工填写一份单子,填写bug号,bug内容,修改的class全限定名称,对其他模块的影响;
提交给某个人去对比CVS和单子上描述的内容。
3,在部署到指定服务器之后,由小组长测试通过,然后再部署到另外一台服务器上由测试组测试。
刚刚又发布了更加复杂的单子填写项目
这就是企业级软件吗?
有没有更好的维护方式?
难道非得回到半自动时代才能限制开发者的随意提交?
是否有更好的解决方式?
1、开发人员在向CVS提交代码时描述修改内容和填写的单子号
2、手工填写一份单子,填写bug号,bug内容,修改的class全限定名称,对其他模块的影响;
提交给某个人去对比CVS和单子上描述的内容。
3,在部署到指定服务器之后,由小组长测试通过,然后再部署到另外一台服务器上由测试组测试。
刚刚又发布了更加复杂的单子填写项目
这就是企业级软件吗?
有没有更好的维护方式? 难道非得回到半自动时代才能限制开发者的随意提交?
是否有更好的解决方式?
又是对日项目么?
如果不是tdd开发这的确是个好办法....
如果不是tdd开发这的确是个好办法....
美国总公司的项目,现在有了一个超级客户,公司全力维护。
如果多出现几个客户,不知道又该怎么维护?
到那个时候既要考虑主版本,又要考虑各个客户的个性化需求。
按照这种模式的话,想想就觉得头大。。。
美国总公司的项目,现在有了一个超级客户,公司全力维护。
如果多出现几个客户,不知道又该怎么维护?
到那个时候既要考虑主版本,又要考虑各个客户的个性化需求。
按照这种模式的话,想想就觉得头大。。。
分版本部署其实是一件很幸福的事情。
我这里某客户高层觉得数据太过分散,搞起数据大集中,集中到后面直接把项目都集中起来。
最搞笑的是it部和行政部门互相扯皮,it对行政完全没有约束力,总公司对分公司的约束力也不够,一个版本里面要满足所有分公司的需求,从权限到业务林林总总都有个性化定制的需要。
美国总公司的项目,现在有了一个超级客户,公司全力维护。
如果多出现几个客户,不知道又该怎么维护?
到那个时候既要考虑主版本,又要考虑各个客户的个性化需求。
按照这种模式的话,想想就觉得头大。。。
分版本部署其实是一件很幸福的事情。
我这里某客户高层觉得数据太过分散,搞起数据大集中,集中到后面直接把项目都集中起来。
最搞笑的是it部和行政部门互相扯皮,it对行政完全没有约束力,总公司对分公司的约束力也不够,一个版本里面要满足所有分公司的需求,从权限到业务林林总总都有个性化定制的需要。
我没什么想法,只是想说。。。。
可怜的孩子!
经常有人说xp没有文档,起因就是在这里。每次集成,你们的集成服务器不能提供一个完成的报告,这样的企业应该补课了。这些东西都应该是非人工自动化的完成的。
问题:
用CVS,VSS来做版本控制,可是,还是一团糟。有了历史记录,可是找一个文件很麻烦,得查一堆的文档,烦死了。
想从配置库中找到当前的最新项目情况,看不出来。
分支,合并的太多了,看管理的历史文档,一堆,头大了。
想查一下,当前的产品5。0版本下面有那些模块组成,那些在4。0的基础上做了修改,那些是新增加的模块,太难了。
产品开发容易,维护难啊,管理明白了更难!
我该怎么办啊?
这里是ozzzzzz回复中最长的一篇,也是个人以为更有价值的:
而每一次建造会得到一般版本,这样的版本我们叫build,它只是通过了白盒测试的版本。而你所做的内部黑盒测试就是,针对这些build的。当你的这些黑盒测试达到一定水平的时候,你就要沿着版本树向上测试,当到达最后一个完全通过的版本时,你就把那个版本确定为release。而我们说的阿拉发版本和贝塔版本,你就可以认为贝塔是这个release,也可以认为阿拉发版是这个release,而通过一定的客户测试后得到的修改版是贝塔,这写你们可以自己选择。而最后当这个发展后的release,你判断它已经符合市场的要求,达到成品标准的时候,你就可以认定它为一个standard,这就是一个真正的产品版。你从我上面的表达可以看出,standard肯定是一个release,而release不一定是standard。每一个release都是一个build,而build不一定是一个release。那么standard也是一个build,而build不一定是一个standard。于是有极端的人要求,每一个build,都必须达到standard的外在标准,比如如果你会以cd发布你的软件,那么你得到的build就应该是cd,如果是dvd,你就应该拿到dvd的build。需要用户手册,那么你的build也必须有那个手册,总之每一个build除了bug和功能的差异,和真正的产品都完全一样。当然我觉得这有些过分,它也告诉你build,不是那么简单的把代码放到一块就可以了,你必须为其准备集成测试,还要把他们完全编译。
这是简单的单版本情况,而实际情况往往是多版本同时开发。比如当你有了standard1·0之后,你要维护它,修补bug,于是会不断的推出1·1-1·2之类的版本。而同时你还在开发新的更多功能的2·0版本。这些版本间有共有的代码,注意是代码而不是模块,特别是那个小火柴,一定要理解这些共有是建立在代码基础上的。比如你修改了一行代码,那么你的版本升级了,可是你并没有模块级的改变。在多个版本共同开发的时候,你会发现有不同的几个standard和release以及build,这个时候就要建立他们不同的分支。而由于有cvs等版本控制软件的支持,我们可以很容易的得到当前的最新版本和以前的任一版本,这是因为你的每一次集成都会被记录到你的资料库中。这些资料要包括你测试的版本,代码的版本,建造的时间,产生bug的记录。这些都是可以用工具自动执行的,如果达不到自动,就去查查手册。
而不同的体系版本间会有兼容问题,这也要看你的产品策略。我们以简单情况为代表,这个时候你的新开发的代码如果不使用在1·0的系统下,就只要去考虑对于其在2·0体系下的测试。而你要为修改的1·0的bug,则你要看在2·0是不是也同样有这个bug,如果有就说明这是你在原始代码中的bug,你需要回归测试到0·0,寻找到底是那一点代码产生了这个bug。而如果只是1·0体系下的bug,则当然只要回归测试到1·0。
其实说了半天,没有什么复杂,关键是要坚持做到每一次少提交一点代码。而那些记录其实都是可以由程序自动完成的。
考虑:
1、如果采用持续集成,就意味着需要为现有的代码添加大量的测试代码,这个工作量委实不小。
2、项目存在纵向(升级、添加新的功能)和横向(不同的客户要求)的版本差别,那其实每个版本之间的测试代码也是存在差异的。如果在某个版本的测试中发现了问题,就需要再在其他版本的测试代码中添加类似的单元测试以求正是否存在类似的bug。
3、公司现在考虑将来把新开发的功能从分支上merge到主干上,这个其实也是冒着巨大的风险的,因为没有持续集成,全凭测试组MM鼠标点。如果出了问题,领导就会说我们不敬业。
实际上我对于CMM的从欣赏走向不认同,其实也就是从SCM开始的。最开始是CMM让我知道了有一个SCM,很不幸当去切实的去了解CMM和使用CMM的公司的时候却发现他们的SCM是那么不能让我满意。而对于XP的喜好也是来自我对持续集成这个概念的赞赏,虽然在现实中我不使用XP,但是可以说XP在持续集成方面给了我方法论层次上最大的支持。
进一步说从SCM的角度来说RAILS是一个巨大的进步——在持续的程序结构上给SCM提供了重大的便利,但是我并不认为RAILS做的就足够了。简单的说一个真正高效的开发工具,应该提供从需求到测试的所有开发核心工作流及其产品的SCM支撑。只有这样才能从根本上解决后期维护的成本考量,才能做到持续而平滑的成本输出曲线——这个曲线是XP方法的基本理论出发点。