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的特性和用法

培訓對象
　　本課程適合公司技術負責人，項目經理，資深開發人員。

課程內容

持續集成的要點和原則
持續集成的準備工作
搭建持續集成環境
構建策略和最佳實踐
構建結果通知機制
自動化測試
自動化代碼分析
與問題追蹤工具集成
自動化發布管理
分布式構建
在大型項目中應用持續集成