JavaEye：1.李彦辉老师，您好，您是什么时候加入ThoughtWorks公司的，进入公司后的感受如何？

李老师：我是2007年加入Thoughtworks的。 进入公司后感觉这种平等、开放的态度以及追求卓越的精神很符合自己的个性，所以我很喜欢在这里工作。


JavaEye：2.可以介绍下敏捷开发的一些实践吗？

李老师：我自己常用的一些实践包括TDD、重构、简单设计、持续集成等。在我看来，TDD确保我编码前理解了需求，并保持设计的简单性；然后TDD带来的大量自动化单元测试保证了持续集成的有效性，让我在重构代码时得到及时并有效的反馈，进而更有信心通过不断的重构来达到简单设计。

JavaEye：3.对目前敏捷开发在国内的发展现状，能做一个简单的评价吗？

李老师：比起两年前我加入Thoughtworks的时候，我觉得现在国内越来越多的人已经或多或少地了解了敏捷，他们的问题已经从Why转向了How，这点可以从今年的敏捷中国大会看得出来。


JavaEye：4.目前您致力于构建、测试、部署方面的研究，能说明下他们的特点以及在开发的过程中需要注意的事项吗？

李老师：传统的构建包括产品的编译、打包， 但在今天的持续集成上下文中构建涵盖软件开发周期中更多的阶段，比如测试和部署。一个好的构建过程往往包含大量的自动化测试，甚至自动化部署。从开发的角度来看，构建、测试和部署都是对编码工作的反馈，都需要被纳入到开发人员的考虑范围。


JavaEye：5.早在一年前，ThoughtWorks就发布cruise软件，可以简单的介绍一下吗？

李老师：Cruise是Thoughtworks基于自己多年的持续集成经验所构建的。早在2007年我们的同事Dave Farely就发布了一篇文章介绍部署管道（The Deployment Pipeline）的概念，用来建模软件开发过程中管道式的活动，比如典型的开发、测试、部署等。Cruise提出的构建管道的概念帮助软件开发团队更好的管理整个开发流程，提供更好的项目可见性。Cruise迄今为止发布了7个版本，目前最新版是1.3.2。


JavaEye：6.能为大家列举一些使用cruise的成功案例吗？

李老师：Cruise项目组自身应该算一个吧:) 另外我们还有一个大客户在印度那边，开发人员有170多个，同时维护3个版本，16个部署环境，260台构建机器，他们在Cruise的帮助下做到了平均每6周交付一次 。


JavaEye：7.您对JavaEye网站有什么评价吗？可以说说您对JavaEye的建议和期望吗？

李老师：JavaEye是一个很好的技术交流平台，ThoughtWorks也有很多同事上JavaEye。我觉得一个技术平台最大的价值在于沟通交流优秀的软件开发实践，帮助大家共同提高，希望JavaEye能在这方面做得越来越好。

JavaEye：1.许伟老师，您好，您是什么时候加入ThoughtWorks公司的，进入公司后的让您感受最深的是什么？

许老师：我是2008年五月加入ThoughtWorks的, 之前我是一家创业型外包公司的技术负责人. 我们当时一直用手工测试, 而且部署比较频繁, 每次有了新的功能,就部署到客户的测试机器上.这样客户可以了解最新做出来的东西是不是他想要的, 然后可能对需求进行更改. 开始的时候, 因为进度比较紧,每次都是到快下班的时候才完成开发工作, 然后在本地简单测试后开始部署到美国的服务器,之后再手工测试, 如果发现有问题, 再匆忙的修改, 然后再部署, 再测试... 每次都花很长时间, 可能到晚上11, 12点, 几次之后我们决定以后的部署最迟在下午2点前进行, 但这也意味着这天下午所有的人都不能继续开发, 因为随时可能发现bug, 就需要修改代码.

于是我们总结了主要问题有:
1. 测试环境和部署环境不同. 本地Windows, 服务器Linux,本地程序能运行, 但部署后失败了, 比如权限, 服务器设置, 数据库连接信息等等各种环境相关的原因
2. 本地测试不够,因为人工测试花时间太长, 所以部署前就只选比较重要的功能进行测试, 以前的功能可能被最近的改动破坏了,但是没有测到

我当时听说了自动测试和持续集成, 但是没有任何经验. 于是找了JUnit的资料, 尝试写了一些核心业务逻辑的测试, 觉得很难写, 大部分的代码在准备数据, 测试也不容易维护, 于是就放弃了. 之后又安装了Cruise Control, 因为据说通过它能解决我们的这种问题, 但用了以后什么好处都没有感觉到, 于是又放弃了.

后来我加入了ThoughtWorks, 发现原来测试可以这么写, 持续集成要这么做! 有了测试以后, 持续集成自然就在团队里重要起来, 每个人都会关心集成的结果, 不然总会有人在办公室里用所有人都能听到的声音说"XXX, Build Fail 了".

目前我感受最深的有两个方面: 公司氛围上每个人都在不断的想更好地办法来改进, 开发实践上一定要有自动测试和持续集成.

JavaEye：2.目前在国内使用敏捷开发的公司多吗？使用敏捷开发又能带来哪些好处呢？

许老师：目前我知道的已经使用敏捷开发的国内公司不是很多, 但是有越来越多的公司开始关注敏捷开发.
我目前接触到的项目都会有需求变更, 如果我们在一开始就把这种变化处理好,会比项目全部做完后再处理成本低得多.
敏捷开发源自Toyota的精益思想, 它提倡以人为本, 持续改进, 通过较快的迭代实现频繁交付, 这样能够和客户做到很好的沟通, 减少对需求理解的不一致, 客户也可以及时调整需求来满足业务的变化. 每一个迭代过程都是一个完整的瀑布流程, 包括需求分析, 设计, 编码, 测试, 部署等. 这样我们可以一直思考一个问题:"什么是客户真正需要的, 做这件事会给客户带来什么好处", 这样可以有限的精力放到最重要的事情上, 并降低开发过程中的风险, 最终给客户带来更大的价值.

JavaEye：3.对敏捷实践的推广以及未来的发展前景，能谈谈您的看法吗？

许老师：越来越多的人发现了项目中可能存在的各种问题, 比如:需求变更, 不同人对需求理解的偏差, 理解不一致而导致的交付风险等. 我觉得这些问题问题分为两类 : 需求变化 和 沟通问题.
如果需求一定要变化, 那我们只能改变自己去适应他, 改变的越早, 成本越小.沟通如果有问题, 一方面我们可以增加沟通的频率, 另一方面我们可以换一种方式, 一百句话可能不如一幅图更能表达清楚意思, 而一百幅图也不如让不同的人操作一下已有的软件更能理解项目做成了什么样子.
敏捷实践就是在解决这些问题, 通过每个迭代的交付品, 客户可能发现了新的需求或者发现已有需求并没有带来真正的价值; 开发人员与客户可以对需求达成一致, 如果有了偏差, 就及时更正; 所有的人都知道项目的最新状态, 每个人都可以问:这么做对不对, 能够给客户带来什么好处?
另外, 敏捷提倡的是持续改进, 他并没有强制规定必须这么做或是那么做, 每个项目可以根据自己的情况, 选取不同的实践. 选取一个实践也没有硬性限制必须怎么做, 不同的项目还是要根据自身情况进行调整.
我认为实施敏捷是为了解决问题, 而不是为了敏捷而敏捷. 如果我们在开发过程中发现了潜在的问题, 并且能够找到办法解决它, 那我个人觉得就无所谓敏捷不敏捷, 如果不能解决, 那可以参考各种敏捷实践, 看可不可以解决自己的问题. 
我个人认为敏捷= 每个人都在想不断改进的氛围 + 一些已经验证的较好实践. 简单来说, 你发现有一个问题需要解决, 而别人已经通过某种方法解决了, 那你就可以参考解决方法. 我觉得这是一种很淳朴的解决方法或改进过程, 所以我对敏捷的未来前景比较看好.

JavaEye：4.了解到您发起了很多开源的项目，您能介绍下吗？ 

许老师：我目前发起的开源项目主要是两个, 一个是代码生成器, 一个是软件升级时升级数据库的工具(DB deploy for c++).
代码生成器是在我以前做外包项目时开发的. 当时很多项目都采用Struts + Spring + JDBC结构, 项目的核心业务不是很多, 但是为了支撑这些核心业务, 需要有很多辅助模块, 每个模块可能都需要列表, 增删改等简单功能. 为了这些简单功能, 实现每个模块需要增加十多个文件, 文件内容相似却不同, 相似是结构相似, 不同在字段不同. 现在如果用RoR,或者Symfony, 他们都生成了很多代码用来简化这种重复工作, 我做得代码生成器也类似, 通过读取数据库信息, 生成代码. 要生成什么样的代码需要用户自行设计, 这样可以满足不同项目的需要. 一句话来描述就是可以让所有的语言都可以使用类似RoR里代码生成的功能. 关于代码生成器, 从我接触到的人里, 一半人喜欢,一半人觉得没用, 这点就看个人喜好了. 另外, 在<程序员修炼之道>这本书中也介绍了代码生成器.

另一个工具是数据库升级工具, 我在Java项目中用到了DBDeploy. 通过它可以根据最新的软件版本自动升级或降级已有的数据库, 但我用C++开发的项目就没有类似的库,所以我就把DBDeploy 移植到了C++上, 所以这实际上是一个移植项目.

JavaEye：5.谈谈您对开源的看法？

许老师：现在我知道的大部分人都在使用开源软件, 很多人也给开源社区贡献了自己的力量. 如果没有开源, 我们每个人就得开发自己专有的的struts, spring, hibernate, 使用昂贵的数据库和操作系统. 而我们现在可以找到数不尽的开源软件, 从操作系统, 编译器, 数据库, 应用服务器, 云计算, 到很多实用小工具. 我认识的很多人都在使用Linux. 所以我觉得如果你不想用盗版, 又不想花钱, 那就用开源软件吧, 你总能找到适合自己的工具的, 如果实在找不到, 而你又需要, 那你可以自己写, 然后贡献出来, 让其他人方便的去用. 

JavaEye：6.这次您将作为ThoughtWorks持续集成培训的讲师，可以向大家简单的介绍一下持续集成吗？

许老师：简单的说, 持续集成是对每次代码或配置的改动都进行编译, 测试, 检查本次改动有没有破坏已有的功能.
我对持续集成在项目中扮演的的角色这么认为: 持续集成是项目开发的一面镜子, 你可以从中发现项目潜在的问题, 并进行改进. 比如, 如果写单元测试很困难, 可能说明当前的类职责太多, 程序结构可以改进; 如果最近失败的比较频繁, 说明代码变得不稳定, 发布的风险变大, 如果不能在一台干净的机器上编译, 可能说明编译对机器环境有依赖, 不同机器编译出的结果不同...
通过持续集成, 可以降低项目发布的风险, 如果有问题, 尽早发现, 尽早改正.

JavaEye：7.据统计，开源项目几乎都实施了持续集成的工作，想必一定有他的过人之处，为什么它能吸引这么多的开源项目呢？

许老师：首先持续集成是一个沟通的工具, 每一个项目的参与人员都可以知道项目的最新进展, 最近修改的什么功能, 其次它又是一个检查工具, 每个人提交的代码都会强制经过一系列相同的验证过程, 从编译, 打包, 各种各样的测试, 到部署. 这样一定程度上保证了代码的质量, 并且随时可以找到一个比较稳定的版本. 最后通过持续集成,我们可以把一部分比较复杂, 手工处理容易出错的过程自动化, 比如部署, 来减少人为失误.
不只是开源项目, 很多商业项目也都在使用持续集成. 持续集成是需要付出成本的. 但是随着项目周期变长, 人数增多, 我们从持续集成中得到的收益就越大. 开源项目一般都是在比较长的时间内, 同时有很多人开发, 并且开发人员可能不固定, 所以更需要持续集成的支持.


JavaEye：8.在使用持续集成的过程中一定会遇到很多的问题，我们应该注意些什么呢，能简单的介绍下吗？

许老师：我个人觉得这个问题是关于持续集成的基本实践, 因为每一个实践都是在解决一个或多个问题.
一些常见的问题包括: 构建流程不清晰, 构建时间很长, 只有特定人员关心构建结果, 构建失败后继续提交代码, 在某个开发机器上运行构建等等.
那对于这些问题, 我们应该怎么做呢?
首先, 应用持续集成的过程, 是一个对现有的开发流程进行分析和改进的过程, 当项目比较大时, 我们需要一个清晰的流程来进行阶段性构建, 比如, 单元测试, 打包, 集成测试, 用户验收测试, 性能测试, 部署, 不同的项目都有自己特定的具体流程,通过这种流程划分, 我们可以清晰的知道自己的构建流程, 并且知道每一次构建都到了什么程度.

其次, 每个人都要关心构建的结果, 怎么来保证这一点呢? 项目组可以有一个约定, 如果构建失败, 所有人都要停止提交, 或者把构建修好, 或者把最近的改动撤销. 这样每个人都会关心构建结果, 因为如果你的修改使构建失败了, 那会影响整个团队的进度.

再次, 要有一个简单有效的方式来报告失败, 这样构建失败的时候整个团队都能够方便的知道结果, 然后相应的人员就可以进行修复.
因为时间关系, 这里只是简单介绍, 关于持续集成实践的具体内容, 我们会在培训中进行具体的分析和介绍.

JavaEye：9.您对JavaEye网站有什么评价吗？可以说说您对JavaEye的建议和期望吗？

许老师：我觉得JavaEye给我们提供了一个很好的交流平台, 但我个人觉得里面应该有一个地方来发广告贴, 比如我在前一家公司的时候, 总是想找一个好些的论坛(比如JavaEye, csdn)发招聘贴,但总是被删掉. 我觉得这种招聘帖可以分为企业客户和未验证客户, 在不同的地方展示. 纯属个人想法, JavaEye应该有自己的定位.（re：JavaEye目前有提供付费的招聘服务）

李彦辉，ThoughtWorks咨询师，在大规模企业应用开发和互联网应用开发方面有6年经验，对于程序设计和敏捷开发方法的理论和实践方面有较深认识。目前致力于研究和传播构建、测试、部署方面的最佳实践。

许伟，ThoughtWorks咨询师，拥有6年企业应用开发经验，对于程序设计和敏捷开发方法的实践有较深认识。加入ThoughtWorks之前作为项目经理成功交付了多个企业应用项目。目前发起了Thelei Code Generator和DBDeploy For C++等多个开源项目，现从事敏捷软件开发，关注于敏捷实践在软件开发中的应用，致力于敏捷实践的推广。

2009年11月19日-20日，ThoughtWorks将在北京举行持续集成的培训大会，讲解如何使用Cruise进行持续集成开发。相信身为企业核心的你一定不会错过！
 

链接：http://www.javaeye.com/news/10959-thoughtworks

11月19日（周四、全天）、11月20日（周五、上午半天）
北京京仪大酒店
每天7小时 （9：00－12：00，13：30－17：30），上午半天（9：00－12：00）


课程名称：持续集成之道－使用Cruise培训课程

课程介绍：

软件项目需要敏捷，企业更需要敏捷。一支敏捷的团队能够在项目中收获成功，而一家敏捷的企业能够在市场的风雨中屹立不倒。

在敏捷实践中存在一种名为“持续集成”的实践。持续集成(ContinuousIntegration,CI)是“节能减排”的一种重要体现,是一种绿色实践,它在拒绝浪费，降低产品研发风险，提高软件质量方面起到了举足轻重的作用。尤其是对企业级用户来说，它大大的降低了开发成本和周期。

从全世界范围的软件研发趋势来看,开源项目都实施了持续集成的工作,大量商用软件的研发工作也在逐渐拥抱这一敏捷实践。

通过本课程你将会学到如何搭建有效的持续集成环境，来帮助减少开发中的集成问题，提高代码质量以及整个团队的沟通和协作。你也会发现，一个好的持续集成环境如何扮演团队中沟通枢纽的角色。

培训目标
理解持续集成的要点及原则
能够在自己的组织中搭建持续集成环境，运行自动化测试，收集并报告构建结果
能够识别并解决持续集成中的常见问题
了解Cruise的特性和用法

培训对象
　　本课程适合公司技术负责人，项目经理，资深开发人员。

课程内容

持续集成的要点和原则
持续集成的准备工作
搭建持续集成环境
构建策略和最佳实践
构建结果通知机制
自动化测试
自动化代码分析
与问题追踪工具集成
自动化发布管理
分布式构建
在大型项目中应用持续集成