構建自動化駛向何方?

　　時下大多數開發人員對持續集成(Continuous Integration，CI)的基本原理已經很熟悉，但是他們中只有一小部分人能夠從優化CI設置中徹底受益。毫無疑問，一個有效的持續集成環境可以幫助你的團隊節省時間、金錢甚至減少存有的顧慮。通過持續集成，我們可以更早地發現bug，更輕松地找出導致其發生的原因并最終有效地解決。持續集成可以更好地管理源代碼，更有效地使用自動化分析工具，鼓勵編寫好的測試，跟蹤進度以及突破開發人員活動中的瓶頸。持續集成可以讓部署過程更簡單且發布過程更加平穩和可靠。借助于CI，管理者可以得到更多的圖表，了解到更多的信息，而開發者可以專注于開發而不用過多交流，也就更加高興。換句話說，如果不使用持續集成，那么就好比用記事本編寫代碼來開發軟件，雖然可行，但是太低效了。

　　在本文中，來自Wakaleo咨詢公司的首席咨詢師John Smart，將給我們介紹如何把持續集成由一個名義上的定時作業，變為開發活動中一個有效、而且能提高生產力的“中樞”。

　　持續溝通流

　　一個良好的敏捷開發環境本質特征就是盡可能的最大化小組成員間的信息流。每一個開發人員都需要盡快地知道何時構建過程失敗，或者何處改動可能會對應用程序質量造成不良影響。如果構建過程失敗了，那么首要工作就是要知道做了什么改動，以及為什么做這些改動：所有的這些信息都應當在開發人員敲擊幾下鍵盤后就能通過最直接的方式獲得。

　　即便是最基本的CI設置，它也會在構建失敗后給開發人員發送電子郵件。其實我們只需要下一點點功夫，就能比現在做得更好。一個良好設置的持續集成服務器應該像團隊溝通中的中樞一樣工作。除了簡單地發送電子郵件進行提醒外，其實還有很多事情可以做，例如現代CI工具中的許多特性——這些特性可以更平穩、更有效地向開發人員反映代碼改動和構建失敗的情況。

　　電子郵件大概是CI提醒方式中最古老也是最常使用的方式了，只是因為它非常普遍而且易于建立。盡管如此，事實上電子郵件是一個相對低效的提醒機制。當構建過程失敗時，你希望被盡快地通知到，越快越好。如果因為電子郵箱客戶端的更新而等上15分鐘的話，那么可能就浪費掉了開發時間。除此之外，電子郵件通常很容易讓開發人員分心。在企業里，每天的非緊急的或是不重要的電子郵件都會有很多。事實上許多優秀的開發人員都禁用電子郵件提示，只是在一天中定時地去檢查幾次郵件。

　　即時消息相對而言則是一個更加合適的提醒方式，有好幾個原因。最重要的原因是，即時消息是(幾乎是)即時的。你不再需要因為電子郵件客戶端在服務器中檢查新郵件而等上10分鐘，使用即時消息，你能被立即通知到。它比電子郵件更加方便，而且閱讀起來也更快。不僅如此，來自構建服務器的IM消息也會得到相關的重視，而不會淹沒在大量無用的其它信息中。

　　當事件發生后，使用快速即時信息和花上10到15分鐘使用電子郵件也許只相差幾分鐘，但千萬不要低估這幾分鐘的重要性。那幾分鐘足夠讓一個開發人員丟失重點，并轉移到其它的一些事情上，結果就導致了開發人員很難回到上下文中去修復問題。

　　使用即時消息的另外一個好處在于它可以擴展到桌面以外的應用。像BeeJive這樣的應用程序可以將即時消息用到移動設備諸如Blackberries(黑莓)和iPhones上。這樣的話，即使開發人員不在辦公室，也能收到至關重要的構建失敗提醒。

　　即時消息提醒比起電子郵件，可以更多的與CI服務器進行交互。作為一個溝通的中介，即時消息要比電子郵件更加的自然，它還可以進行比 Subversion 提交信息還要多的交互。通過利用即時消息，如今的一些CI工具不僅僅可以發送提醒，還可以讓開發人員更輕松地與構建服務器以及其他組員進行交互與交流。

　　當然，即時消息不是僅有的另一種可用提醒方式。如果想讓大家注意到構建信息的話，最好采用一種能夠融入相應企業文化的提醒機制。例如，一些公司使用社交網 絡的工具例如Twitter，作為一個有效的內部交流渠道。對于這些組織而言，使用Twitter也可以算是一種有效的構建提示方法了。

　　保持構建過程高效率

　　持續集成環境的一個首要目標是要保證開發過程的順利進行，并且避免由集成問題帶來的障礙和開發延期。當集成問題突然出現時，開發人員應當有義務盡快的去提交一些代碼來解決這個問題，以避免影響到其他開發人員。如果沒有持續集成環境，開發人員通常會在集成問題上卡住而找不到一個解決方案(“嘿，它在我的機器上能運行啊!”)。

　　想讓開發過程一直保持最好的狀態，那么團隊成員(尤其是團隊領頭人，流程專家等)需要能夠監測構建過程，這樣他們可以識別定位出日常生活里降低開發人員效率的問題。其中最好的方法就是去了解如何最好地使用構建感測。

　　構建感測是一個用在持續集成周期中，用以描述構建長期統計數據的術語。Bamboo，一個不錯的CI工具，它就提供了很高級的構建特性。構建感測為你提供了關于構建要花多久，是否成功，以及解決這個構建失敗問題要花多久等等之類的信息。這些數據很重要，因為它可以讓你知道構建過程長期以來是什么樣的。正是這種數據，而不是單個構建的結果，可以幫助你最終優化構建過程。

　　一定數量和頻率的構建失敗一直是一個不錯的著手點。隔離的構建失敗通常不需要擔心——你需要做的是去檢查一系列反復出現的構建失敗。當一個構建反復失敗時，也許是因為開發人員正糾結于一段非常麻煩的代碼，或者是團隊人員沒注意到。雖然這兩問題的原因不一樣，并且解決的方法也不一樣，但是它們都應當被進一步地調查。

　　通過深入分析測試結果，你可以了解到更多關于為什么構建會失敗的信息。許多現代的CI工具都可以讓你研究長期的測試行為，例如，把一直經常失敗的、或者要花很長時間進行解決的測試跟其他測試隔離開來。如果同樣的測試不斷失敗的話，這就意味著有什么地方過于復雜或者代碼過于脆弱，這種情況下可以做一些重構。除此之外，這些工具還能讓你知道測試運行了多久，這是另一類問題發生的源頭。

　　事實上，構建失敗不是唯一減慢開發進程的原因。緩慢的構建過程是另一個罪魁禍首。

　　導致構建過程緩慢的最常見的原因是結構混亂的測試套件。經驗豐富的Java開發人員常常會將單元測試與集成測試分開來。雖然兩者區別大差不差，但是一般來說，單元測試是相對孤立的、較小的、快速的、輕量級的測試類。它們主要是用來確保類能夠獨立地正常工作。而另一方面，集成測試則較為緩慢，需要更長的運行時間，并且可能會訪問外部的資源如測試數據庫，或者加載復雜的配置文件。它們被用來測試應用程序中的不同模塊和類如何共同工作。性能測試和集成測試差不多，但是兩者的目標有所不同。

原文轉自：http://www.kjueaiud.com