背景

        自從我們使用scrum進行專案開發後，出現了這樣那樣的問題，有些是因為我們對scrum的理解不到位，有些則是客觀因素導致的，針對這些問題，在每次迭代的總結會上，我們進行了反思，並根據具體環境對scrum進行了一一調整，想通過幾篇文章和大家分享一下我的經驗。

我說的不一定正確，只是描述問題，然後說說我對問題的看法，採取的解決方案，希望使用敏捷開發的大牛提供寶貴意見。

為什麼我們需要持續整合？

又要從我們的故事說起，我越來越喜歡講故事了…… 在前幾個sprint的評審會上，我們只是讓各個組員單獨演示了自己開發的功能，並且約定時間，大家都提交一個穩定的版本，做了一次整合。 過了一些天，領導L突然造訪，想看看專案進展，讓我們整合起來，這時候問題來了，各個模組開發進度不一，很難找到某個時間點，讓大家順利整合。上次是約定好時間，大家有所準備，這次又不能使用上次的整合版本，太陳舊了。所以出現了這樣的情況，領導L坐在那裡等著看，大家趕緊手忙腳亂的構建，然後整合，幸好沒出大問題，結果可以看了，但中間浪費了不少時間。 領導L的造訪，說明了他對進度和質量的擔憂，我們該如何讓他放心？ 另一方面，scrum提倡，可用的軟體優於面面俱到的文件。但如何保證可用軟體的質量成了一個棘手的問題，尤其是在不斷變化的需求中。 怎麼辦才能看出軟體質量的優劣，進度的快慢？  經常整合起來，看看效果，不就知道質量怎麼樣，進度怎麼樣了嘛？而且經常整合起來看，有助於發現問題，解決問題，如需求有沒有偏差，是不是領導和客戶想要的效果，又或者發現和解決這樣那樣的bug等等。 但經常整合，又會牽扯開發人員很多精力去更好地協同工作，這是在開發過程中不可迴避的問題。 這次又得站在巨人的肩膀上了，看下面一段話： 持續整合正是針對上述一系列問題的一種軟體開發實踐，它倡導團隊開發成員必須經常整合他們的工作，甚至每天都可能發生多次整合。而每次的整合都是通過自動化的構建來驗證，包括自動編譯、釋出和測試，從而儘快地發現整合錯誤，讓團隊能夠更快的開發內聚的軟體。                                                                                                                                                                               —— Martin Fowler

持續整合的核心價值在於：

1、降低風險，每天都可能發生多次整合，有利於及早發現軟體質量問題。

2、自動完成，通過自動化工具可以避免開發人員投入過多精力

3、軟體執行狀態隨時可看，可以增加領導和團隊成員對專案的信心。

4、利於對未來進行把控，持續整合的資訊有利於我們對未來進行更好地規劃和把控。

概念不多說，我們團隊非常需要持續整合，所以經過調研，我們採用jenkins作為持續整合的大管家，Jenkins 就是一個配置簡單和使用方便的持續整合伺服器。由它完成自動構建、自動部署、整合。用了一段時間，還不錯，上面說的一系列問題也迎刃而解。

寫到這裡有一點小感觸：很多東西的產生是那麼地理所當然，順理成章。