編碼規范也可以作為非常有效的培訓支持和指導活動，尤其對于那些經驗不足的開發人員。CI工具可以提供這些數據如何隨著時間的推移而變化的高層次圖片，還可以關注開發人員在應用他們學到的技巧時做得有多好。例如，如果一個類只有很低的代碼覆蓋率，甚至沒有，意味著某個新的開發人員在消化吸收小組培訓的測試驅動開發和測試實踐上出現了問題。這種方法還可以通過代碼審查和定期的代碼質量會議(討論任何新問題或者動向的會議)完成。

　　一旦構建結束??自動化部署過程

　　構建應用程序只是開發生命周期中的一部分。一旦代碼編譯測試后，需要進行其他的活動，例如部署到階段性(staging)環境、冒煙測試、功能測試和性能測試、準備發布說明和提醒QA人員新的發布。

　　將新的構建結果自動部署到集成服務器上是一件相對簡單的事情。而將其部署到階段性環境或者生產環境下，則需要涉及一些與常規構建作業不一樣的工作。一般而言你需要一個更加嚴格，更加正規且有更多可跟蹤性和問責的過程。它通常涉及到的任務如下：

　　* 為階段發布標記源代碼

　　* 編譯測試應用程序

　　* 發布構建產品

　　* 將應用程序部署到階段性環境中

　　* 運行數據庫更新腳本或者其他特定環境腳本

　　* 運行冒煙，功能和性能測試

　　* 準備并發布產品說明

　　* 提醒關于新階段發布的相關利益人

　　這通常是一個手工任務，但是其中的大部分工作沒有理由不能自動化。事實上，開發生命周期中的自動化包裝，部署和發布具有很穩固的商業意義。一方面自動化能夠得到更加可靠的構建：計算機不會忘記部署過程中的某一步，也不會在發生測試失敗后繼續進行。它還能夠節約開發人員的時間：階段性發布由之前幾小時的 shell腳本編程變為了只要點擊一下按鈕。它比以前的速度要更快，并且可以在沒有人的情況下完成工作(例如，通宵或者午休時間)。

　　像Maven 2這樣的工具也能夠幫助自動化一些步驟。Maven Release插件使得Maven的用戶能夠自動化處理一些如“更新版本號”，“Subversion中新增標簽”，以及“向Maven存儲庫中發布構建產品”的工作。它可以用來管理階段構建，并決定在不同的環境部署不同的發布產品。盡管如此，一旦產品構建結束并且可以部署到階段性環境者生產環境時，這個過程會變得更復雜。

　　千真萬確，現實世界中的部署步驟數目經常要比簡單的用一個WAR文件多。根據應用程序架構和產品平臺，你可能需要在階段性環境者生產環境下的數據庫中運行SQL更新腳本、用一個專用的工具部署web服務、運行自動化的冒煙測試或者做一定量服務端的工作。

　　CI可以幫助簡化比這些還要復雜的步驟。例如通過分布式構建，你可以設立階段性環境或生產環境上的構建代理，并在該機器上直接運行相應的任務。幾乎所有的 現代CI工具都支持相當好的安全模型，目的是為了將應用和產品環境限制給一些特定的人，以及跟蹤誰在什么時間運行了什么構建。

　　這是CI的一個相對較新的應用，不同的工具在處理應用程序部署時使用的方法也不一樣。有一些，如Hudson，允許在構建作業中定義多個步驟，只有當前一 個步驟成功后，才能執行后續步驟。其他的像Cruise和Anthill Pro，都嘗試將部署生命周期中的如階段和生產環境直接集成到構建工具中，盡管有時候這樣會帶來額外的復雜度開銷。

　　還有更多低層次的操作可以和CI服務器聯合起來使用。一個選擇是使用諸如Ant或者Maven的構建工具。Ant對于這種類型的腳本特別靈活。另一個流行的選擇是古老的Makefile，或者Unix上的shell腳本。它們的缺點是操作系統相關的，并且對于那些不熟悉shell腳本精髓的Java 開發人員來說很難掌握。想要與Java更加友好，可以選擇動態語言諸如Groovy或者Gant(一個使用Groovy而不是XML來制作Ant腳本的工具)。 Groovy在提供所有輕量級的動態腳本語言中所有的優點的同時，也保留了對Java開發人員的熟悉程度和可讀性。

　　總結

　　這些只是使用現代持續集成環境完善構建過程和增強團隊的幾個方法。持續集成環境不僅僅是一個構建計劃表，它還可以用來幫助打開隊伍內部的溝通渠道、保持構建過程平穩有效的運行、時刻監控代碼質量以及自動化發布和部署過程。