專案經理不但要用管理實踐掌控專案，還可以歡迎團隊改變自己的技術實踐，從而獲得更大收益。本章包含的一系列實踐，能為專案帶來很多好處。專案經理和團隊要根據自身的實際情況，判斷如何調整、使用這些實踐，而不要強制推行。如果你認為它們有所裨益，不妨將其介紹給團隊，並歡迎團隊積極嘗試。
9.1 在專案中使用持續整合
開發人員用一兩個小時編寫一段**，對其進行編譯，測試，複查，構建，執行冒煙測試，並驗證做出的改變不會破壞現有系統**，再將其簽入到**庫中。持續整合就這麼發生了。
持續整合可以讓開發人員馬上得到所做工作的反饋。他們開始考慮將大任務拆分成更小的部分（這可以讓他們以更快的步伐前進），還能盡早識別出專案的整合風險。持續整合讓開發人員每天都能有所收穫，幫助專案團隊找到符合自己的節奏。
開發人員只有在完成了某個功能的**後才將其簽入，這就是按階段整合的方式。有些開發人員一周簽入一次**。有些更糟糕的專案，開發人員一到兩個月才簽入一次**。按階段整合會打斷專案的節奏。構建時出現的問題，會中斷設計和編寫新功能**的人們的思路。他們不得不記住很多小細節，而這些小細節覆蓋了從專案開始直到進行整合的各個階段。如果忘記了這些細節，專案進度會放緩，因為團隊發現了缺陷，而且必須想起可能是幾個月前所寫**的細枝末節。這其實是一種同時處理多工的方式，而且特別不容易發現。人們是在做同乙個專案的工作，而且手上的任務可能也相關，但是思考問題時的抽象層次卻有所不同（設計比除錯的抽象層次更高），而且也不再是處理同乙個功能的問題，思考問題的上下文由此發生了變化。所有切換上下文的代價都發生在這裡（參見16.7.3節），在設計下乙個功能時，開發人員可能會因此而喪失好的想法，還可能增加向設計中引入缺陷的潛在風險。
頻繁構建是為開發人員和專案經理準備的
如果你提出使用每日構建，測試人員可能會抱怨：「我們做不到以如此快的速度構建，只能每週構建一次。」頻繁構建，比如每小時甚或每天，不是為測試人員準備的。頻繁構建可以為開發人員提供反饋，同時讓專案經理了解專案狀態。
如果測試人員可以利用每日構建來執行測試，那就太棒了。不過即使測試人員做不到這一點，通過每天構建可工作的**，並維持這樣的節奏，開發人員也可以從中獲得有價值的反饋。
如果專案經理不能將變更後的**整合到**庫中，你可以採取持續整合的變種。假設你管理乙個專案團隊，大家的任務是擴充套件乙個已存在產品的設計。團隊目前正在處理的部分產品**是整個產品的基礎。如果這部分**無法執行，那整個產品都不能執行。你現在不想簽入**，因為這樣會破壞現有的產品，而且會占用三個月的時間來新增和替換產品的現有功能。你該怎麼做？
應該選擇現有狀況下的最佳方案。你可以將主**庫做乙個分支版本，並讓所有開發人員在這個分支版本上開發。他們每次簽入一些**，都會與主線**進行同步，保證自己的分支**是最新版本。這使得開發人員總是在最新和最全的**版本庫上進行開發，而且他們一直都在進行整合。當他們完成各自工作後，就會將所有**都合併回主線。
這是持續整合的乙個變種。如果必須重寫已經存在的**，而且在開發變更**時不想破壞現有系統，可以採用這種方式。如果專案經理管理的專案所提供的服務要為一組產品使用，比如乙個程式庫或是乙個平台，這種方式同樣適用。
見
保持敏捷 持續整合
敏捷的乙個要點就是 快速反饋。從最早的每日構建，到現在的持續整合，都是開發者為了迅速獲得系統反饋而採取的一系列措施。而且反饋資訊越來越快速，資訊要求越來越高。一次整合的過程步驟大概如下 自動更新 編譯構建 自動測試 報告整合結果。需要使用者寫好各過程命令 比如更新版本 並在整合伺服器的支援下，把各過...
「持續整合」之一二三
自動化測試是持續整合的前提 毋庸置疑，自動化測試是持續整合的前提。如果您的專案還沒有單元測試或功能測試 那麼持續整合的意義就不那麼重要了。只有隨著專案的進行，不斷增多的自動化測試，才能突顯持續整合的重大意義。持續整合是 健康狀況的指示器或風向標。通過持續整合，可以盡早發現問題，提醒團隊成員盡早修復問...
持續整合（一）
一 提出 整合軟體 的過程不是新問題，如果專案開發的規模比較小，比如乙個人的專案，如果它對 外部系統 的依賴很小，那麼軟體整合不是問題，但是隨著軟體專案複雜度的增加 即使增加乙個人 就會對整合和確保 軟體元件 能夠在一起工作提出了更多的要求 要早整合，常整合 早整合，頻繁的整合幫助專案在早期發現專案...