[size=medium]粗略翻了一遍jolt大獎書籍《持續整合：軟體質量改進和風險降低之道》，發現基本原則和我前面在做的並無差別，不過對方顯然是百試不爽經驗豐富，我在具體操作的過程中卻停下了無數次，按照陽明先生的話來說，不能實踐的知，實在不是真知，結合自己的認識，把讀書後獲得的一點小的總結放到後面，用來逐步改善自己的工作。
實現持續整合的第乙個要點，簡言之就是需要實現「一鍵構建」，展開來說那就是「在任何情況下，都能根據需要，從指定的服務上獲得無二義性的乙份材料來順利完成這個構建過程」。這個講起來有點抽象，不過拆開分為幾層意思來說就明了了，要獲得無二義性的構建材料，包括**、配置等，那麼肯定就需要版本管理工具的介入了，如集中式管理**的svn，分布式管理**的git，都是這類工具中的翹楚；獲得了可靠的素材，構建還需要隔離環境或者配置變化帶來的傷害，比如在開發者自己機器上運作構建，而不能執行到伺服器上，那麼就不是好的構建，這個時候需要通過一些配置項來調整平台或者其它構建環境的差別；第三個從這裡引申出來的要點，那就是構建不能依賴於具體的ide，因為這並非是所有環境都應該有的東西，這點我體會尤深。
持續整合的第二個要點，就是在上面第一點的基礎上，需要在構建過程中，必須加入能夠度量產品質量的一系列工具或過程。這點就很好理解了，持續整合不是為了持續的編譯**，或者說不只是。更多的是監控在變化的過程中，是否引入了複雜性、重複度、不好的**風格、隱藏的bug。這些都是乙個產品健康與否的關鍵指標，恰如乙個人的身高體重血壓，只有具備了這些過程，構建才能對產品形成乙個客觀的報告，在這方面我用過的工具就有sonar，pmd，checkstyle，findbug等，當然，這裡有乙個並非現成的工具，而需要開發者辛勤的去積累的乙個東西，那就是對於產品的自動化測試**，根據我的實踐，在乙個既有**全無測試的工程裡加入測試，揹負的歷史包袱不可謂不重，報告裡對**測試覆蓋率極低的資料，又會成為開發者最終放棄做單元測試的理由，這個大概可以用「破窗理論」來解釋，一旦開發者覺得無望處理遺留的**，他就有可能轉為順從歷史，也放棄寫測試，進而導致這個洞越來越大。這事我覺得較為靠譜的或許就是由開發者堅持對新功能加測試，然後對於出現問題的老**加上測試，逐步進行。
然後是持續整合的第三個方面，這個點可以很自然的從第二點推導而來，既然我們視整合構建是一件「有用」的事，而非乙個玩具或者一種時髦，那麼第二步加入的度量報告就必須受到嚴肅的對待，這些資料必須及時的通知到對應的人員並及時處理。簡單的一些原則包括：必須盡快修復失敗的構建；開發者爭取建立自己的私有構建過程，避免提交不能構建的東西到版本庫等。通知和展現這個目前持續整合的工具都做的比較好。我用過的hudson及其各種外掛程式能滿足大部分場合的應用，最要關心的反而是人的環節，必須有人對持續整合產生的報告做持續的跟進，並及時丟擲一些需要團隊注意的問題，這樣才能規避一系列的開發風險，提高開發的質量和效率。[/size]
讀書 持續整合軟體質量改進和風險降低之道
經常發生這種事 開發者修改源 dba修改了表定義 構建部署團隊修改了配置檔案 介面團隊修改了規範。如何利用持續反饋，測試 單元測試，自動化瀏覽器測試 部署 自動化構建部署 審查 和同事或者架構師經常 審查 資料庫整合來是實現持續整合?要經常進行整合構建 編譯 重新建立資料庫 執行自動測試發郵件和審查...
持續整合質量保證方案
需求評審 介面 使用者介面 功能 效能 安全性 單元測試 junit 掃瞄 sonar 依賴檢查 引用包安全性 測試用例評審 實際評審和需求及開發會並行進行 介面測試 postman http介面 自定義測試工具 dubbo jsf http介面 robot framework 功能測試 robot...
如何提高研發質量與持續整合
隨著軟體業的不斷發展，軟體專案的規模越來越大，軟體結構越來越複雜，技術要求越來越高，參與人員越來越多，管理也變得越來越難。在這樣乙個大背景下，如何提高軟體研發質量，相信是所有軟體公司都在關注的話題。但是，如何提供研發質量，這決不僅僅是乙個口號，我們必須有一套行之有效的方法加以管理。然而有效的管理帶來...