自動化測試是持續整合的前提
毋庸置疑，自動化測試是持續整合的前提。持續整合有很多實踐，通過實際專案的經歷，總結三個基本實踐：如果您的專案還沒有單元測試或功能測試**，那麼持續整合的意義就不那麼重要了。只有隨著專案的進行，不斷增多的自動化測試，才能突顯持續整合的重大意義。持續整合是**健康狀況的指示器或風向標。通過持續整合，可以盡早發現問題，提醒團隊成員盡早修復問題，得到更健康的**。
一、盡早開始
持續整合應該在專案初始階段就給予考慮，並在搭建開發環境的同時建立持續整合環境。而且，你最先check-in的**檔案應該包括你的構建指令碼，從而觸發第一次構建，並使這次構建通過。此後，你所需要做的就是不斷增加**，改進構建過程。其實，很多時候一旦說「等以後」，那就等於說「never」。就象單元測試一樣，「開始時**這麼簡單，不用測試也沒問題；而當認為**不那麼簡單需要測試時，就會發現此時單元測試太難了，要重寫好多**，還是不寫了吧！」結果可想而知。
所以，持續整合還是在專案最簡單的時候引入為好。
二、盡快執行
持續整合最主要的目的就是得到盡早的反饋。專案開始時，**較少，持續整合所用的時間不會太長，只有幾分鐘。對於開發團隊來說，這個時間還可以忍受。可是，隨著**庫的不斷增大，功能增多，持續整合所花的時間越來越長，以至於影響開發團隊的生產力。一定要在此之前再去優化你的持續整合。因為當你意識到這個問題的時候，它已經產生了負面影響。那麼如何讓持續整合盡快執行呢？一般來說，有三種途徑可以達到：（一）優化**，即通過對現有**的優化使執行更快，如盡可能地減少外部依賴，使用記憶體資料庫代替基於檔案系統的資料庫等；（二）縱向擴充套件，即通過增強持續整合所需硬體的效能［如記憶體，cpu］等提高執行速度；（三）橫向擴充套件，即通過將測試分成多個部分，在多個環境下並行執行後彙總結果，以達到節省時間的目的。
三、專人負責
在專案中，要有專門的人員或角色（ci engineer）來負責持續整合的改進。只有某種任務有相應的責任人後，該任務的執行才能得到保障。這一點在較大或較複雜的專案中尤其重要。當然，這並不是持續整合的全部，只是持續整合的基本實踐。只有做到了這三個基本實踐，才能高效地發揮持續整合的作用。因為在專案較小，人員較少的情況下，大家可能會對持續整合的環境都非常了解，只要有問題發生，都會找到問題，加以解決。但是，在較大較複雜的專案中，持續整合環境可能會比較複雜，持續整合的伺服器以及構建機在**，有什麼樣的配置，如何管理不可能被所有的專案成員了解。此時，就該ci engineer出現了。他的責任就是盡可能地利用資源使持續整合的週期縮短，使反饋更加迅速。
當然，這並不是說，有了ci engineer，持續整合的結果就由他負責。對於持續整合中的失敗，所有團隊成員都有責任有義務去fix，即使自己不能fix，也要找到正確的人去fix。
關於程序之一二三
程序是作業系統中乙個非常重要的概念。就像生活中人與人打交道的時候都會去了解對方的來歷和背景一樣，在學習程序的時候我們也有必要把程序的來龍去脈搞清楚。這就是為什麼會產生程序這個概念，它的特點是什麼，程序和通常所說的程式的區別在 如果我們能夠搞清楚這幾個疑問，我想對程序也就基本掌握得差不多了。一 程序產...
持續整合（一）
一 提出 整合軟體 的過程不是新問題，如果專案開發的規模比較小，比如乙個人的專案，如果它對 外部系統 的依賴很小，那麼軟體整合不是問題，但是隨著軟體專案複雜度的增加 即使增加乙個人 就會對整合和確保 軟體元件 能夠在一起工作提出了更多的要求 要早整合，常整合 早整合，頻繁的整合幫助專案在早期發現專案...
持續整合簡介
想起我剛畢業後，進入一家以軟體外包為主的外企做開發。它使用傳統的瀑布式的軟體開發流程，沒有使用任何的敏捷實踐。我每天上班開啟電腦，拿到自己的任務，然後從版本控制更新 開啟工程按下build，準備進行今天的開發任務。突然發現build失敗 通常是編譯不過 大喊一聲 誰break build啦 也沒有人...