|
锁定老帖子 主题：团队出现这样的场景大家一般怎么处理
精华帖 (2) :: 良好帖 (8) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2009-01-13
最后修改：2009-01-13
说白了，没有经常与svn同步。
或者说更新不够频繁。 在过去的项目我是遇到这种情况，某些程序员，为了完成自己任务，从任务开始到结束都没有更新svn，结果到他提交的时候（可能是几天或者一个星期后），问题一大堆，因为他是以几天前的代码为基础上开发的。 因此，我建议的作法是每天上班后第一件事，从svn上更新代码，每天下班之前提交所有代码，同时解决所有冲突问题。这是至少每天要做的事，当然我是欢迎随时进行更新或提交，这样更能及时发现由代码更新产生的问题。 另外，我比较喜欢持续集成的方法，要求程序员必须坚持写单元测试。搭建CI服务器，代码集成测试交给集成服务器，代码进行每夜构建，将问题通过邮件或者其他方式通知所有项目人员，第二天程序员解决集成发现的问题。 当然，实际操作中很难去实施。我过去只是在一些项目实施，而且做得很勉强，很多程序员有抵制情绪。于是产生什么“国情说”之类的笑话，在我看来，主要是懒惰在做怪，当然一些公司领导由于自己个人利益，不愿意将开发过程透明化，喜欢用一些流于形式的文档来掩盖项目中的存在问题（如分工问题，技术问题等）。 可以说对国内的开发团队的现状我是心灰意冷。 |
| 返回顶楼 | |
|
发表时间：2009-01-13
zhuixinjian 写道 建SVN分支版本！
有SVN还不让人提交，那要SVN干嘛。可以分支版本测试没问题，再合到主版本去！ 这不是搞的更复杂了么？ 千万别建分支。提交后，集成测试出问题可以再改了提交，但看楼主的意思好像是不好明确谁改（开发人员认为凭什么要我改？） 另外，使用git来进行版本控制，好像可以解决楼主面临的问题。 |
| 返回顶楼 | |
|
发表时间：2009-01-13
这是SVN使用的问题吧。
你们有了稳定版本之后应该添加新的branch来做开发，然后找developer坐在一起做merge吧。 dev和prod环境混在一起，有点乱。 |
| 返回顶楼 | |
|
发表时间：2009-01-13
为什么不能建新的branch呢？ 建了新的branch还是可以看到trunk的更新啊，每天做更新，等到自己做完在找developer做merge，这样也能解决LZ的问题吧。
pipilu 写道 zhuixinjian 写道 建SVN分支版本！
有SVN还不让人提交，那要SVN干嘛。可以分支版本测试没问题，再合到主版本去！ 这不是搞的更复杂了么？ 千万别建分支。提交后，集成测试出问题可以再改了提交，但看楼主的意思好像是不好明确谁改（开发人员认为凭什么要我改？） 另外，使用git来进行版本控制，好像可以解决楼主面临的问题。 |
| 返回顶楼 | |
|
发表时间：2009-01-13
产生这个问题的一个主要原因是开发团队中一些成员对代码checkin认识不够，需要做一些培训以及在项目中做出一些规定来解决。
配置管理产生了本地和远程库两个版本，当本地版本由于很久不更新过于老久，那么这种情况下checkin代码无疑影响是比较大的，负责任的程序员应该是经常更新代码，甚至在ｃｈｅｃｋｉｎ代码前先进行一次同步然后编译，没有问题后再提交。这种问题就需要培训和讲清楚原则来解决了。 另外为了避免坏代码造成ｂｕｉｌｄ失败和耽误开发进度，可以采用连续构建工具来及早发现源代码库的编译问题，写个ａｎｔ脚本就行，也可以用ｌｕｎｔｂｕｉｌｄ这种系统。 通常开发团队会规定一个ｃｈｅｃｋｉｎ时限，比如每天下午5点钟之前ｃｈｅｃｋｉｎ代码，5点之后就不再ｃｈｅｃｋｉｎ，可以立即进行构建，发现问题及时解决，确保第二天的开发不受影响。 |
| 返回顶楼 | |
|
发表时间：2009-01-13
Maven和SCM一起可以解决这个问题，公司里面的nexus让你没办法不用统一的jar。
csevan 写道 我认为定个规矩，首先第一修改之前需要先UPDATE，再进行修改。
第二每天都要养成下班前提交的好习惯。 第三每天都要养成上班前UPDATE的好习惯。 如果有JAR包冲突，在SVN上要养成，统一开发包的好习惯。 （即：JAR包一起放入SVN里面，开发只准用SVN里面的包，如果出现新增包，也应该加入SVN中，以避免后期这种包冲突及兼容问题，也可以提早发现新包存在。） 第四最好是要有所沟通，每次新加入的东西，确定会影响其他模块的话，应该在开发之初就要了解，开发后也要知会相关人员，看是否符合要求。避免后期修改问题。最好能做代码review （对方很忙的话，也可以口头描述一下） |
| 返回顶楼 | |
|
发表时间：2009-01-13
seemoon 写道 通常开发团队会规定一个ｃｈｅｃｋｉｎ时限，比如每天下午5点钟之前ｃｈｅｃｋｉｎ代码，5点之后就不再ｃｈｅｃｋｉｎ，可以立即进行构建，发现问题及时解决，确保第二天的开发不受影响。 这个想法很不错，我原来的想法进入了一个较为极端的误区，7×24小时保证svn随时build，deploy，运行没问题似乎有点理想化，还是得在团队内部定个契约，比如哪个时间段属于构建阶段，不容许提交引起不稳定的代码，哪个时间段属于一个能够容错的“缓冲阶段”。 建分支也尝试过，但是多个分支间代码同步比较烦人。 |
| 返回顶楼 | |
|
发表时间：2009-01-13
最后修改：2009-01-13
terencewong 写道 这是SVN使用的问题吧。
你们有了稳定版本之后应该添加新的branch来做开发，然后找developer坐在一起做merge吧。 dev和prod环境混在一起，有点乱。 关于merge，有什么好的措施么？以前这merge这块往往都是我一个人做，基本体力活，团队在配置管理这块是个弱项，每次提交代码都得我再三提醒“写comment、写comment” |
| 返回顶楼 | |
|
发表时间：2009-01-13
很多人知道冲突了， 但是不想知道为什么冲突了。 还是回味下看看为什么冲突了。 不说为什么了， 反正是没有人理会的，
|
| 返回顶楼 | |
|
发表时间：2009-01-13
最后修改：2009-01-13
sdh5724 写道 合并规则
代码合并是项目必然要经过的事情. 合并部分最难处理的就是冲突. 这过程也是最容易产生潜在BUG的地方. 有几个地方会发生冲突, 1. 测试合并 在发布测试程序后, 会发生比较严重的冲突行为, 随着测试的进行, 需要解决冲突的地方越来越多. 程序员可能在这种无穷冲突当中感到非常的苦恼. 导致想发布单一的分支进行测试. 此类型问题发生后, 可以根据最新的主干, 建立一个新的项目分支. 然后, 把当前开发的分支合并到新建分支上, 根据该分支进行测试, 开发人员切换到新建分支进行继续开发. 这么样做, 可以保证当前测试是最新主干, 减少回归测试压力. 并减少发布当中可能会出现的冲突出问题. 2. 发布合并 在进行发布过程中如果出现冲突, 不允许在编译机器上解决冲突. 在测试阶段, 持续的使用最新主干建立分支并切换开发分支的形式, 已经杜绝了冲突带进发布环境. 但是, 测试的并一定要求使用和主干合并的情况下, 我们可以做适当的调整, 满足实际开发中过于复杂情况的产生. 因此, 发布过程合并分支持过程要求按如下方式进行: a) 发布人员必须使用要发布的分支在开发机器测试是否会和主干发生冲突行为. b) 如果发生冲突, 那就建立从主干建立一个新的分支, 然后把要求发布的分支合并到新建分支. c) 把新建分支在编译机上合并到主干. 以上是基于分支开发的一些规则。 需要建立一整套的规则。 这只是我的合并规则， 还有： SVN帐户管理 SVN目录管理 SVN项目管理 SVN主干管理 SVN分支管理 如果这个事情都处理不好， 还当什么程序员。 洗洗回家吧。 开发一定要建立新的分支， 或者在主干。 就3个项目人员要吵架， 要是30个人要互相残杀了？ 这个问题首先是项目架构师不作为， 或者项目经理不作为。 基本SVN的规范没有制定， 自己不熟悉SVN操作。 不好意思，刷得太快，刚读到您的回复，坦白而言，不管是我们组内的架构师，还是公司的QA，对svn的管理，都远远达不到您提的标准，惭愧。 |
| 返回顶楼 | |
