以前没有仔细推敲过这两个词

process - 宏观 procedure- 微观

Software Configuration Management: A Clear Case for IBM Rational ClearCase and ClearQuest UCM

这里是第二版：

[url]http://www.redbooks.ibm.com/abstracts/sg246399.html/url][

中文版早就有了

这个问题是个很实战的问题，有点像流程改进。理论上大家讨论的头头是道，以做起来却不知道如何下手。作者在这方面总结的还是很清楚的。

原文： Identify -〉 Build -〉Share -〉Continuous

Identify:识别一个需要自动化的过程。一般都是开发过程，不过有时候会是测试或者其他。 Build: 通过脚本工具，把这个过程自动化 Share: 将变更保存到版本库中以便重复利用 Continuous: 点题！ 将这个自动化的过程，持续的，周期性的，运行下去。

[b][点评]：[/b] 胖子不是一天吃出来的，CI 和过程改进一样，要一点一点进行。要从最薄弱的地方入手 (效果最好，老板最喜欢)，要用最简单的技术 (维护群众的积极性)。

[[i] 本帖最后由 shawn2001 于 2010-12-9 11:36 编辑 ]

通过 CI，自动化那些重复进行的工作，节约时间干重要的事情-- 例如 上 SCMroad 发帖。

节约时间是最初的目的，不过也带来了一些其他的好处：

-- 自动化操作，避免了手动中容易出现的错误 -- 通过持续集成，可以随时得到项目的反馈。有多少编译错误，测试的覆盖率等等。项目经理可以随时调整进度。 -- 在实现持续集成后，随时都会有一个可以交给老板和客户的软件。这点我不太赞同，一个可交付的软件，不一定具备客户需要的功能。 -- 对于项目有更大的信心。 每次 build 成功后的 email，所有人都是很开心的

[b][点评][/b] 说了半天好处，那坏处是什么？:( 说到底，以前是人做的流程现在自动化了，那还要那么多人干什么。。。。:L

集成 integration = 编译 + 单元测试 + 代码检查 + 发布

自动集成 就是把上述内容自动化

有规律的持续不断的进行 自动集成，持续自动集成，简称持续集成 Continuous Integration :lol

[b][点评]：[/b] 活儿还是那些活儿，换个说法或者起个名字，就显得很上档次。让我一下想到了 cloud :victory:

web/agile/svn/jira/confluence 这不就是我们公司用的吗 看着心动:victory:

不过看着 offshore 就有气

laofo 于 2010-12-8 02:46 发表
:'( 我刚在 amazon 上买了个英文原版的。。。。亏了 [/quote]

多看两遍就赚回来:lol

codyzhang 于 2010-12-2 09:20 发表
我们是 java 项目测试数据使用的是 dbunit 的 dataset，数据准备都在 xml 中。 生产用的数据放在一个规律的目录下按版本划分、每次修改版本好就可以了。[color=red] 若是参数为 all 就发布所有的。若是没有就是发布当前版本 ... [/quote]

可否详细解释一下红色部分:lol

codyzhang 于 2010-12-2 09:20 发表
我们是 java 项目测试数据使用的是 dbunit 的 dataset，数据准备都在 xml 中。 生产用的数据放在一个规律的目录下按版本划分、每次修改版本好就可以了。若是参数为 all 就发布所有的。若是没有就是发布当前版本 ... [/quote]

很不错的建议。

[attach] 942[/attach]

[attach] 943[/attach]

[attach] 944[/attach]

[attach] 945[/attach]

laofo 于 2010-12-7 03:41 发表
有的公司好像是专门 developer 负责数据库创建脚本的维护。数据库结构的变化在研发的前期可能很大，后期应该趋于稳定。

至于研发测试的数据库需要 backup/restore 么？是不是每次都用最新的脚本创建一个最新的就可以了？

ps: ... [/quote]

对于 SaaS 的产品，数据库变化总是很大，尤其是当有多个客户使用不同的数据库结构，那更是庞大的灾难。 数据库脚本也有很多种：DML / DDL ，其中有的是可以重复执行的，有的不行。所以管理起来很费劲。

对于研发初期，的确不需要 backup/restore，因为可以简单的通过 script 重建数据库，来进行集成测试。 当产品 deploy 后，需要解决一些只有生产环境中才遇到的问题，尤其是 performance 的问题。也会需要将 production DB 同步到研发环境，这里就牵扯到一个 backup/restore。当然有一种思路是，还是通过 script 重建数据库 schema，然后通过程序生产一些模拟数据，不过当表很多时，这个也很难。

codyzhang 于 2010-12-7 11:02 发表
我们公司是架构师写了一个工具。 目录结构固定，且有规律。如： src\main\db\1.0.0.0 src\main\db\1.0.0.1 测试时会根据参数去使用不同的数据库脚本。 [/quote]

这的确是现在用得最多的办法，把 SQL script 编号，存储到相应的版本目录中。不过怎么看都不舒服，属于最原始的 CM。

已经有 WAN svn (svn multi-site)，不过属于收费软件

我也是工作中遇到了这方面的问题，才开始研究的。

其实背景很简单：

• 如何象管理代码一样管理 database。 这里的数据库指的是：schema + data。既要能处理数据库的结构，又能处理数据。
• 如何能快速的 backup/restore/deploy database，例如，让每一个 developer 能够拥有一个单独的数据库用于开发/测试
• 如何应用真实数据，如产品数据库，进行 QA 测试

laofo 于 2010-12-6 15:36 发表
你对知识吝啬，工资就对你吝啬

我最近又买了本《Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation (Addison-Wesley Signature Series (Fowler)) - Jez Humble; Hard ... [/quote]

很长时间没有买过书了，都是下载下来当字典用。

这本书很好，提供不少理论支持，正在学习中。

这个沙发要坐的，管理员这么晚都没睡？

承蒙厚爱，大家一起进步！:loveliness:

有用,我们一个 build 要 4-5G

小蚂蚁办大事

tooo nice to be true.:lol

[url]http://blog.crisp.se/henrikkniberg/url][

codyzhang 于 2010-12-2 09:05 发表
java wrapper 是指什么？ java 是开发语言 tomcat、resin、jetty 都是做容器的 appserver。 若是指 hudson 发布到的容器，个人认为 jetty 做好 若是和语言结合最好应该是 java 吧。其他 c++、ruby、.net 应该可能都要插件或自已写脚 ... [/quote]

我们的确有许多 app 用 java wrapper service: http://wrapper.tanukisoftware.com/doc/english/download.jsp

java 指的是用 java.exe 直接启动 jar

tomcat, resin, jetty 也都在用，但是那个更好都是众说纷纭

项目的变更管理和 CM 变更控制不是一个层次的东西。

CM 变更控制相对简单，一般有相应工具配合就更简单了，如 DOORs + Clearquest。 当项目进行中有 CR(change request) 近来后，要维护 CR 的 dashboard；要起组织 CCB；对批准的 CR 要细化成任务分配给开发人员....

事情很多，不过大部分是 PM 在系统中完成，CM 只起 support 和日后的 audit。

xiaoxiang7788 于 2010-5-7 15:26 发表
这篇文章很不错, 完全体现了持续集成的核心:自动化... [/quote]

自动化的难点是测试自动化，尤其是 unit testing。要想持续集成搞得好，要先去提高程序员写 Unit test 的功底。

持续集成是一个在敏捷开发的大环境下，产生的东东。所以充分体现了 agile 的特点。

持续构建，如果从作用上分类，只能属于 automation build，即自动化构建。这个属于持续集成的一部分。持续集成的 best practice 还包括，自动测试，自动发布，通知.... 不多说了，摘抄如下：

CI recommended practices:

• maintain a code repository
• automate build procedure (compile + testing)
• everyone commits every day
• every commit should be built
• build fast
• test in the clone of production environment
• golden build repository
• result publishing for latest build
• automate deployment