JavaEye：1.李彥輝老師，您好，您是什么時候加入ThoughtWorks公司的，進入公司后的感受如何？

李老師：我是2007年加入Thoughtworks的。 進入公司后感覺這種平等、開放的態(tài)度以及追求卓越的精神很符合自己的個性，所以我很喜歡在這里工作。


JavaEye：2.可以介紹下敏捷開發(fā)的一些實踐嗎？

李老師：我自己常用的一些實踐包括TDD、重構、簡單設計、持續(xù)集成等。在我看來，TDD確保我編碼前理解了需求，并保持設計的簡單性；然后TDD帶來的大量自動化單元測試保證了持續(xù)集成的有效性，讓我在重構代碼時得到及時并有效的反饋，進而更有信心通過不斷的重構來達到簡單設計。

JavaEye：3.對目前敏捷開發(fā)在國內(nèi)的發(fā)展現(xiàn)狀，能做一個簡單的評價嗎？

李老師：比起兩年前我加入Thoughtworks的時候，我覺得現(xiàn)在國內(nèi)越來越多的人已經(jīng)或多或少地了解了敏捷，他們的問題已經(jīng)從Why轉向了How，這點可以從今年的敏捷中國大會看得出來。


JavaEye：4.目前您致力于構建、測試、部署方面的研究，能說明下他們的特點以及在開發(fā)的過程中需要注意的事項嗎？

李老師：傳統(tǒng)的構建包括產(chǎn)品的編譯、打包， 但在今天的持續(xù)集成上下文中構建涵蓋軟件開發(fā)周期中更多的階段，比如測試和部署。一個好的構建過程往往包含大量的自動化測試，甚至自動化部署。從開發(fā)的角度來看，構建、測試和部署都是對編碼工作的反饋，都需要被納入到開發(fā)人員的考慮范圍。


JavaEye：5.早在一年前，ThoughtWorks就發(fā)布cruise軟件，可以簡單的介紹一下嗎？

李老師：Cruise是Thoughtworks基于自己多年的持續(xù)集成經(jīng)驗所構建的。早在2007年我們的同事Dave Farely就發(fā)布了一篇文章介紹部署管道（The Deployment Pipeline）的概念，用來建模軟件開發(fā)過程中管道式的活動，比如典型的開發(fā)、測試、部署等。Cruise提出的構建管道的概念幫助軟件開發(fā)團隊更好的管理整個開發(fā)流程，提供更好的項目可見性。Cruise迄今為止發(fā)布了7個版本，目前最新版是1.3.2。


JavaEye：6.能為大家列舉一些使用cruise的成功案例嗎？

李老師：Cruise項目組自身應該算一個吧:) 另外我們還有一個大客戶在印度那邊，開發(fā)人員有170多個，同時維護3個版本，16個部署環(huán)境，260臺構建機器，他們在Cruise的幫助下做到了平均每6周交付一次 。


JavaEye：7.您對JavaEye網(wǎng)站有什么評價嗎？可以說說您對JavaEye的建議和期望嗎？

李老師：JavaEye是一個很好的技術交流平臺，ThoughtWorks也有很多同事上JavaEye。我覺得一個技術平臺最大的價值在于溝通交流優(yōu)秀的軟件開發(fā)實踐，幫助大家共同提高，希望JavaEye能在這方面做得越來越好。

JavaEye：1.許偉老師，您好，您是什么時候加入ThoughtWorks公司的，進入公司后的讓您感受最深的是什么？

許老師：我是2008年五月加入ThoughtWorks的, 之前我是一家創(chuàng)業(yè)型外包公司的技術負責人. 我們當時一直用手工測試, 而且部署比較頻繁, 每次有了新的功能,就部署到客戶的測試機器上.這樣客戶可以了解最新做出來的東西是不是他想要的, 然后可能對需求進行更改. 開始的時候, 因為進度比較緊,每次都是到快下班的時候才完成開發(fā)工作, 然后在本地簡單測試后開始部署到美國的服務器,之后再手工測試, 如果發(fā)現(xiàn)有問題, 再匆忙的修改, 然后再部署, 再測試... 每次都花很長時間, 可能到晚上11, 12點, 幾次之后我們決定以后的部署最遲在下午2點前進行, 但這也意味著這天下午所有的人都不能繼續(xù)開發(fā), 因為隨時可能發(fā)現(xiàn)bug, 就需要修改代碼.

于是我們總結了主要問題有:
1. 測試環(huán)境和部署環(huán)境不同. 本地Windows, 服務器Linux,本地程序能運行, 但部署后失敗了, 比如權限, 服務器設置, 數(shù)據(jù)庫連接信息等等各種環(huán)境相關的原因
2. 本地測試不夠,因為人工測試花時間太長, 所以部署前就只選比較重要的功能進行測試, 以前的功能可能被最近的改動破壞了,但是沒有測到

我當時聽說了自動測試和持續(xù)集成, 但是沒有任何經(jīng)驗. 于是找了JUnit的資料, 嘗試寫了一些核心業(yè)務邏輯的測試, 覺得很難寫, 大部分的代碼在準備數(shù)據(jù), 測試也不容易維護, 于是就放棄了. 之后又安裝了Cruise Control, 因為據(jù)說通過它能解決我們的這種問題, 但用了以后什么好處都沒有感覺到, 于是又放棄了.

后來我加入了ThoughtWorks, 發(fā)現(xiàn)原來測試可以這么寫, 持續(xù)集成要這么做! 有了測試以后, 持續(xù)集成自然就在團隊里重要起來, 每個人都會關心集成的結果, 不然總會有人在辦公室里用所有人都能聽到的聲音說"XXX, Build Fail 了".

目前我感受最深的有兩個方面: 公司氛圍上每個人都在不斷的想更好地辦法來改進, 開發(fā)實踐上一定要有自動測試和持續(xù)集成.

JavaEye：2.目前在國內(nèi)使用敏捷開發(fā)的公司多嗎？使用敏捷開發(fā)又能帶來哪些好處呢？

許老師：目前我知道的已經(jīng)使用敏捷開發(fā)的國內(nèi)公司不是很多, 但是有越來越多的公司開始關注敏捷開發(fā).
我目前接觸到的項目都會有需求變更, 如果我們在一開始就把這種變化處理好,會比項目全部做完后再處理成本低得多.
敏捷開發(fā)源自Toyota的精益思想, 它提倡以人為本, 持續(xù)改進, 通過較快的迭代實現(xiàn)頻繁交付, 這樣能夠和客戶做到很好的溝通, 減少對需求理解的不一致, 客戶也可以及時調(diào)整需求來滿足業(yè)務的變化. 每一個迭代過程都是一個完整的瀑布流程, 包括需求分析, 設計, 編碼, 測試, 部署等. 這樣我們可以一直思考一個問題:"什么是客戶真正需要的, 做這件事會給客戶帶來什么好處", 這樣可以有限的精力放到最重要的事情上, 并降低開發(fā)過程中的風險, 最終給客戶帶來更大的價值.

JavaEye：3.對敏捷實踐的推廣以及未來的發(fā)展前景，能談談您的看法嗎？

許老師：越來越多的人發(fā)現(xiàn)了項目中可能存在的各種問題, 比如:需求變更, 不同人對需求理解的偏差, 理解不一致而導致的交付風險等. 我覺得這些問題問題分為兩類 : 需求變化 和 溝通問題.
如果需求一定要變化, 那我們只能改變自己去適應他, 改變的越早, 成本越小.溝通如果有問題, 一方面我們可以增加溝通的頻率, 另一方面我們可以換一種方式, 一百句話可能不如一幅圖更能表達清楚意思, 而一百幅圖也不如讓不同的人操作一下已有的軟件更能理解項目做成了什么樣子.
敏捷實踐就是在解決這些問題, 通過每個迭代的交付品, 客戶可能發(fā)現(xiàn)了新的需求或者發(fā)現(xiàn)已有需求并沒有帶來真正的價值; 開發(fā)人員與客戶可以對需求達成一致, 如果有了偏差, 就及時更正; 所有的人都知道項目的最新狀態(tài), 每個人都可以問:這么做對不對, 能夠給客戶帶來什么好處?
另外, 敏捷提倡的是持續(xù)改進, 他并沒有強制規(guī)定必須這么做或是那么做, 每個項目可以根據(jù)自己的情況, 選取不同的實踐. 選取一個實踐也沒有硬性限制必須怎么做, 不同的項目還是要根據(jù)自身情況進行調(diào)整.
我認為實施敏捷是為了解決問題, 而不是為了敏捷而敏捷. 如果我們在開發(fā)過程中發(fā)現(xiàn)了潛在的問題, 并且能夠找到辦法解決它, 那我個人覺得就無所謂敏捷不敏捷, 如果不能解決, 那可以參考各種敏捷實踐, 看可不可以解決自己的問題. 
我個人認為敏捷= 每個人都在想不斷改進的氛圍 + 一些已經(jīng)驗證的較好實踐. 簡單來說, 你發(fā)現(xiàn)有一個問題需要解決, 而別人已經(jīng)通過某種方法解決了, 那你就可以參考解決方法. 我覺得這是一種很淳樸的解決方法或改進過程, 所以我對敏捷的未來前景比較看好.

JavaEye：4.了解到您發(fā)起了很多開源的項目，您能介紹下嗎？ 

許老師：我目前發(fā)起的開源項目主要是兩個, 一個是代碼生成器, 一個是軟件升級時升級數(shù)據(jù)庫的工具(DB deploy for c++).
代碼生成器是在我以前做外包項目時開發(fā)的. 當時很多項目都采用Struts + Spring + JDBC結構, 項目的核心業(yè)務不是很多, 但是為了支撐這些核心業(yè)務, 需要有很多輔助模塊, 每個模塊可能都需要列表, 增刪改等簡單功能. 為了這些簡單功能, 實現(xiàn)每個模塊需要增加十多個文件, 文件內(nèi)容相似卻不同, 相似是結構相似, 不同在字段不同. 現(xiàn)在如果用RoR,或者Symfony, 他們都生成了很多代碼用來簡化這種重復工作, 我做得代碼生成器也類似, 通過讀取數(shù)據(jù)庫信息, 生成代碼. 要生成什么樣的代碼需要用戶自行設計, 這樣可以滿足不同項目的需要. 一句話來描述就是可以讓所有的語言都可以使用類似RoR里代碼生成的功能. 關于代碼生成器, 從我接觸到的人里, 一半人喜歡,一半人覺得沒用, 這點就看個人喜好了. 另外, 在<程序員修煉之道>這本書中也介紹了代碼生成器.

另一個工具是數(shù)據(jù)庫升級工具, 我在Java項目中用到了DBDeploy. 通過它可以根據(jù)最新的軟件版本自動升級或降級已有的數(shù)據(jù)庫, 但我用C++開發(fā)的項目就沒有類似的庫,所以我就把DBDeploy 移植到了C++上, 所以這實際上是一個移植項目.

JavaEye：5.談談您對開源的看法？

許老師：現(xiàn)在我知道的大部分人都在使用開源軟件, 很多人也給開源社區(qū)貢獻了自己的力量. 如果沒有開源, 我們每個人就得開發(fā)自己專有的的struts, spring, hibernate, 使用昂貴的數(shù)據(jù)庫和操作系統(tǒng). 而我們現(xiàn)在可以找到數(shù)不盡的開源軟件, 從操作系統(tǒng), 編譯器, 數(shù)據(jù)庫, 應用服務器, 云計算, 到很多實用小工具. 我認識的很多人都在使用Linux. 所以我覺得如果你不想用盜版, 又不想花錢, 那就用開源軟件吧, 你總能找到適合自己的工具的, 如果實在找不到, 而你又需要, 那你可以自己寫, 然后貢獻出來, 讓其他人方便的去用. 

JavaEye：6.這次您將作為ThoughtWorks持續(xù)集成培訓的講師，可以向大家簡單的介紹一下持續(xù)集成嗎？

許老師：簡單的說, 持續(xù)集成是對每次代碼或配置的改動都進行編譯, 測試, 檢查本次改動有沒有破壞已有的功能.
我對持續(xù)集成在項目中扮演的的角色這么認為: 持續(xù)集成是項目開發(fā)的一面鏡子, 你可以從中發(fā)現(xiàn)項目潛在的問題, 并進行改進. 比如, 如果寫單元測試很困難, 可能說明當前的類職責太多, 程序結構可以改進; 如果最近失敗的比較頻繁, 說明代碼變得不穩(wěn)定, 發(fā)布的風險變大, 如果不能在一臺干凈的機器上編譯, 可能說明編譯對機器環(huán)境有依賴, 不同機器編譯出的結果不同...
通過持續(xù)集成, 可以降低項目發(fā)布的風險, 如果有問題, 盡早發(fā)現(xiàn), 盡早改正.

JavaEye：7.據(jù)統(tǒng)計，開源項目幾乎都實施了持續(xù)集成的工作，想必一定有他的過人之處，為什么它能吸引這么多的開源項目呢？

許老師：首先持續(xù)集成是一個溝通的工具, 每一個項目的參與人員都可以知道項目的最新進展, 最近修改的什么功能, 其次它又是一個檢查工具, 每個人提交的代碼都會強制經(jīng)過一系列相同的驗證過程, 從編譯, 打包, 各種各樣的測試, 到部署. 這樣一定程度上保證了代碼的質(zhì)量, 并且隨時可以找到一個比較穩(wěn)定的版本. 最后通過持續(xù)集成,我們可以把一部分比較復雜, 手工處理容易出錯的過程自動化, 比如部署, 來減少人為失誤.
不只是開源項目, 很多商業(yè)項目也都在使用持續(xù)集成. 持續(xù)集成是需要付出成本的. 但是隨著項目周期變長, 人數(shù)增多, 我們從持續(xù)集成中得到的收益就越大. 開源項目一般都是在比較長的時間內(nèi), 同時有很多人開發(fā), 并且開發(fā)人員可能不固定, 所以更需要持續(xù)集成的支持.


JavaEye：8.在使用持續(xù)集成的過程中一定會遇到很多的問題，我們應該注意些什么呢，能簡單的介紹下嗎？

許老師：我個人覺得這個問題是關于持續(xù)集成的基本實踐, 因為每一個實踐都是在解決一個或多個問題.
一些常見的問題包括: 構建流程不清晰, 構建時間很長, 只有特定人員關心構建結果, 構建失敗后繼續(xù)提交代碼, 在某個開發(fā)機器上運行構建等等.
那對于這些問題, 我們應該怎么做呢?
首先, 應用持續(xù)集成的過程, 是一個對現(xiàn)有的開發(fā)流程進行分析和改進的過程, 當項目比較大時, 我們需要一個清晰的流程來進行階段性構建, 比如, 單元測試, 打包, 集成測試, 用戶驗收測試, 性能測試, 部署, 不同的項目都有自己特定的具體流程,通過這種流程劃分, 我們可以清晰的知道自己的構建流程, 并且知道每一次構建都到了什么程度.

其次, 每個人都要關心構建的結果, 怎么來保證這一點呢? 項目組可以有一個約定, 如果構建失敗, 所有人都要停止提交, 或者把構建修好, 或者把最近的改動撤銷. 這樣每個人都會關心構建結果, 因為如果你的修改使構建失敗了, 那會影響整個團隊的進度.

再次, 要有一個簡單有效的方式來報告失敗, 這樣構建失敗的時候整個團隊都能夠方便的知道結果, 然后相應的人員就可以進行修復.
因為時間關系, 這里只是簡單介紹, 關于持續(xù)集成實踐的具體內(nèi)容, 我們會在培訓中進行具體的分析和介紹.

JavaEye：9.您對JavaEye網(wǎng)站有什么評價嗎？可以說說您對JavaEye的建議和期望嗎？

許老師：我覺得JavaEye給我們提供了一個很好的交流平臺, 但我個人覺得里面應該有一個地方來發(fā)廣告貼, 比如我在前一家公司的時候, 總是想找一個好些的論壇(比如JavaEye, csdn)發(fā)招聘貼,但總是被刪掉. 我覺得這種招聘帖可以分為企業(yè)客戶和未驗證客戶, 在不同的地方展示. 純屬個人想法, JavaEye應該有自己的定位.（re：JavaEye目前有提供付費的招聘服務）

李彥輝，ThoughtWorks咨詢師，在大規(guī)模企業(yè)應用開發(fā)和互聯(lián)網(wǎng)應用開發(fā)方面有6年經(jīng)驗，對于程序設計和敏捷開發(fā)方法的理論和實踐方面有較深認識。目前致力于研究和傳播構建、測試、部署方面的最佳實踐。

許偉，ThoughtWorks咨詢師，擁有6年企業(yè)應用開發(fā)經(jīng)驗，對于程序設計和敏捷開發(fā)方法的實踐有較深認識。加入ThoughtWorks之前作為項目經(jīng)理成功交付了多個企業(yè)應用項目。目前發(fā)起了Thelei Code Generator和DBDeploy For C++等多個開源項目，現(xiàn)從事敏捷軟件開發(fā)，關注于敏捷實踐在軟件開發(fā)中的應用，致力于敏捷實踐的推廣。

2009年11月19日-20日，ThoughtWorks將在北京舉行持續(xù)集成的培訓大會，講解如何使用Cruise進行持續(xù)集成開發(fā)。相信身為企業(yè)核心的你一定不會錯過！
 

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

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


課程名稱：持續(xù)集成之道－使用Cruise培訓課程

課程介紹：

軟件項目需要敏捷，企業(yè)更需要敏捷。一支敏捷的團隊能夠在項目中收獲成功，而一家敏捷的企業(yè)能夠在市場的風雨中屹立不倒。

在敏捷實踐中存在一種名為“持續(xù)集成”的實踐。持續(xù)集成(ContinuousIntegration,CI)是“節(jié)能減排”的一種重要體現(xiàn),是一種綠色實踐,它在拒絕浪費，降低產(chǎn)品研發(fā)風險，提高軟件質(zhì)量方面起到了舉足輕重的作用。尤其是對企業(yè)級用戶來說，它大大的降低了開發(fā)成本和周期。

從全世界范圍的軟件研發(fā)趨勢來看,開源項目都實施了持續(xù)集成的工作,大量商用軟件的研發(fā)工作也在逐漸擁抱這一敏捷實踐。

通過本課程你將會學到如何搭建有效的持續(xù)集成環(huán)境，來幫助減少開發(fā)中的集成問題，提高代碼質(zhì)量以及整個團隊的溝通和協(xié)作。你也會發(fā)現(xiàn)，一個好的持續(xù)集成環(huán)境如何扮演團隊中溝通樞紐的角色。

培訓目標
理解持續(xù)集成的要點及原則
能夠在自己的組織中搭建持續(xù)集成環(huán)境，運行自動化測試，收集并報告構建結果
能夠識別并解決持續(xù)集成中的常見問題
了解Cruise的特性和用法

培訓對象
　　本課程適合公司技術負責人，項目經(jīng)理，資深開發(fā)人員。

課程內(nèi)容

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