時下大多數開發人員對持續集成(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也可以算是一種有效的構建提示方法了。

　　保持構建過程高效率

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

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