如果是我：

1. 不会建立 1.06，直接让 1.06 developer check-in trunk。
2. developer check-in trunk 时，同时 check-in 1.05 branch。
3. 临近 release 的最后时刻再 branch。

仅供参考

存在就是合理，所以不可能找出一个完美的工具。项目需求最重要：

规模，经费，multi-site，经验，流程，和其他工具的集成，个人喜好。。。

理论上，任何影响到重建 build 以及交付物的工具都应该进行集中管理。是否需要放到版本控制工具中，要看具体情况。

如果属于代码类，脚本类，可以和项目代码放到一起。如果许多项目共用，单独放到一个 repo 中。在各自项目中，引用这个 repo 的不同版本。

如果属于第三方工具，如 MS studio，集中存储就行了。不过要在项目的文档中，著名使用的工具版本号。

文档一般分两种，由代码自动生成的文档，一般和项目保存在一起。doc/ppt/vsd 等文档，可以放到专门的文档管理工具中。(livelink 等)，如果没有条件，放到代码版本管理工具也可以。

codyzhang 于 2010-12-15 11:12 发表
[点评] 1 和 2 是互相矛盾的，要互相平衡。一个最佳实践是如何分割是当得工作单元 (task)。另外一个避免冲突的方式是，不要在同一时间 check-in 代码。例如下班之前。

个人认为不矛盾，我们公司也这样实行的。 频繁 checkin ... [/quote]

恩，矛盾用的不好，原来想说高频率的 check-in 和 保证分支或主干 runnable/tested 是一个 dilemma，解决方法就是定义合适的 work unit (task)。

用过 clearquest /clearddts/change synergy/ Jira / teamforge/Gnats/ netsuite/....

一般一个公司会有两个，一个做 ticket 管理 (IT/ helpdesk 用)，一个做变更管理 (项目用)。但其实都是一类工具。

i 子休 于 2009-11-20 10:37 发表
我们用 GNATS，哪位听说过…… [/quote]

我们用过，开源，可以自己改 bug

laofo 于 2009-5-27 00:03 发表
CCB 一般由 PM 主持和召开,一般不是用来讨论,评估 ChangeRequest,而是用来做决定的. 召开时机一般为当 ChangeRequst 对系统有了很大的影响,以至于 cost, schedule,requirement 三者有相应的变化,需要让 CCB 的成员作出一个决定 ... [/quote]

CM 要牢记自己的身份，属于 support role。所以像 CCB 这种会议，CM 一般就是在工具和流程上给与支持，并不做决定。

p39 那些好的习惯可以使 CI 更好用？

1. 尽量频繁的 check-in 代码，越频繁，越容易集成，越小的概率发生冲突。
2. check-in 之前要本地编译 + 测试，尽量不要破坏主干
3. 一但主干发生问题，修复 build 是第一优先级的任务
4. 增加测试覆盖率 (可以通过工具)，虽然不能 100% 覆盖，但是定下来的测试项要 100% 通过。
5. 避免从代码库 check-out 错误的代码

[点评] 1 和 2 是互相矛盾的，要互相平衡。一个最佳实践是如何分割是当得工作单元 (task)。另外一个避免冲突的方式是，不要在同一时间 check-in 代码。例如下班之前。

1. 可以通过工具来强化，总的来说工具分为三大类： "x"unit testing tools，code coverage tools， code standard/style tools。这三类工具及本来讲是要 100% 通过的，如果不符合要 failed build。其他更复杂的工具可以只给出 warning

yaner 于 2010-12-15 09:48 发表
不同的项目之间可以作分支吗?? 我现在是这样的.A 和 B 是不同的项目.A 下的 C 文件夹是有内容的,B 下的 D 文件夹是空的,现在是要把 A 下 C 文件夹整个移动到 D 文件夹下,然后删除 C 文件夹.明白不?需要保留历史记录... ... [/quote]

SVN 没有项目的概念，你是说不同的 repository ?

elian 于 2010-12-15 09:47 发表

1. 把库转为 dump 文件 2. 利用 svndumpfilter 把需要的目录过滤出来
2. 最后在 load 回仓库 [/quote]

agree

rani 于 2010-12-14 12:45 发表
补充几点：

1、该职位要求良好的英文口语能力； 2、过去不是专职 CM 也可以，只要在研发团队中 60% 以上工作职责与 CM 相关； 3、年薪 25 万左右。 [/quote]

25 万加上奖金了吧，14 薪什么。北京机会比上海多。上海工资高些。不过考虑房子，持平。

我在两个城市各干过几年。

svnadmin hotcopy hot-backup.py svnadmin dump svnsync

其中 svnsync 支持子目录

svnsync

svn + 一个变更管理的 tools (jira, temforge....) 一般变更管理的统计功能更强大，都支持输出。

在持续集成/发布的环境里，code complete 已经不重要。部署到客户环境里才算 complete

Sonar :victory:

rexuekonglong 于 2010-12-13 16:38 发表
比如： 1、加密打包 2、功能说明 3、下载地址

4、安装使用说明 5、建立客户问题反馈机制 [/quote]

6、Escrow 7、大客户 preview (SaaS)

这个对外发布，肯定和产品类型也有关系：

大众市场软件 -- 发布给最终消费者 产品类型软件 -- 发布给供应商 服务类型软件 -- 发布给自己公司的产品 team

cvs 应该有 binary 的包的。另外还使用 svn 吧，想不出什么理由继续用 cvs

一直做得都是专职 CM，有时的确感到和 biz 脱节

海关还进出口，搞得这么复杂。不是西门子就是索爱吧

解决办法很简单：

一切修改尝试不要在 production 服务器上进行，要有镜像的测试环境。

虚拟化 SVN 等服务器，修改配置前建立 snapshot。

谢谢

构建 ，集成 如果抛开持续的概念先：

集成指的是把不同的软件模块，放到一起，使只能继续工作。其中隐含的代码 merge 的概念更显著一些。

构建原先主要指编译 + 前后的一些脚本工作，如打包，测试，发布。可能发生在集成之后，亦可能是集成中的一部分。

总的来讲我认为，集成更广义一些。构建更具体一些。两个词不是一个层次的，但是做的事情差不多。

现在加入持续的概念。持续集成 CI 是标准叫法，也涵盖了 CB（持续构建）的部分。只是没人这么叫。

之前还要通知 developer 目标分支暂时冻结 check-in。如果工具支持更好。