經常發生這種事：開發者修改源**，dba修改了表定義 構建部署團隊修改了配置檔案 介面團隊修改了規範。
如何利用持續反饋，測試（單元測試，自動化瀏覽器測試），部署（自動化構建部署），審查（和同事或者架構師經常**審查），資料庫整合來是實現持續整合?
要經常進行整合構建：編譯 重新建立資料庫 執行自動測試發郵件和審查 部署軟體並接收反饋發郵件。
開發的**複雜程度如何？
應用程式是否仍然滿足效能要求？
自動測試覆蓋了多少**？
最後一次變更以後，是否通過了所有的測試？
最近的開發是否存在問題？
持續的構建，持續的反饋，開發周期內得到修正？
連線版本控制系統
構建指令碼（指令碼自動化）
反饋機制（電子郵件）
整合原始碼變更的過程（編譯和單元測試）
自動化【資料庫整合、測試、審查、部署】和反饋
單元測試 元件測試 系統測試 負載效能測試 安全測試
自動化資料庫整合
自動化測試（單元函式，元件，系統，功能）
自動化**審查（靜態分析+動態分析）
自動化部署（解決了人為過程中的瓶頸）
有些過程，人為操作反而會心累又出錯，所以自動化
【對於開發者，要減少假設，假定，想到任何可能出現的情況】
自動化測試的指令碼要構建到版本庫中，整個可持續的整合都要完全自動化
重複**是有風險的，貼上複製存在風險；
累死**副本需要維護的時候，帶來忽略；
硬編碼；
！！！！！！！！！！！！！
哪些是手工的，是否可以自動化？
構建過程中，重建資料庫和測試資料？
每次軟體變更執行自動化回歸測試？功能，整合。負載，效能測試？
哪些**沒有對應測試？是否使用覆蓋率工具？
軟體**重複百分比是多少？設法減少百分比
當前**是否遵守軟體架構？
通知構建版本和部署版本可以接受測試了？
當前的軟體結構圖是怎麼樣？如何跟新來的解釋軟體架構？
【以前我以為測試不重要，因為之前公司一直是人為的功能流程測試。現在看來，開發和自動化測試(單元，功能，效能，負載，整合)一陰一陽；測試驅動開發；】
構建指令碼
——》清理
——》編譯源**
——》整合資料庫
——》執行測試
——》執行審查
——》部署軟體
為了執行構建更加容易，設立整合目錄：
需求目錄
設計目錄
源**目錄
文件目錄
測試目錄
部署目錄
開發-測試-文件編寫共行
構建的觸發機制：
使用者驅動：手工發起
定期執行：定時任務
輪詢變更：從版本庫中簽出變更，ci工具觸發
事件驅動：監測到版本庫更新就檢測，版本庫觸發
使用ci 構建計算機伺服器
軟體資產統一放到版本庫中
整合伺服器-整合按鈕？
構建花費多少時間？是否嘗試減少時間？提高反饋速度？
構建頻率？每週？每晚上？發生變更時？
很多專案使用共享資料庫，開發者對共享資料庫操作極有可能影響其他團隊成員的工作。所以開發者要有自己本地的資料庫沙盒。
要準備資料庫整合自動化指令碼。
利用版本控制庫共享資料庫資產（包含資料庫配置，測試資料，實體關係圖，儲存過程和函式，刪除建立表和檢視的ddl,包括約束條件和觸發器）
在版本庫中專門新建目錄存放資料庫資產（開發目錄和測試目錄都要分開）。
開發和測試一陰一陽，不可分割，同樣重要；測試驅動開發。
自動化測試分為一下標準測試
單元測試：沒有外部依賴關係
系統測試：測試外部介面，web頁面，web服務selenium
功能測試：以客戶的視覺和行為驗收測試
為缺陷編寫測試。
將測試用例限制為乙個斷言。
測試資產要提交到版本庫中持續整合。
源**的可靠取決於測試覆蓋率；
測試價值取決於執行頻率。
降低**複雜度
減少重複**
持續進行設計複查
判斷**覆蓋率
自己小黃鴨除錯方法
靜態**分析，動態**分析
結對程式設計
自動化**審查能解決80%的問題
**的路徑數和缺陷之間存在關係
不穩定性 = 傳出耦合/（傳入耦合+傳出耦合）
1 確定單元測試的執行頻率？偶爾/定期/持續/專案部署前
2 如何檢查單元測試 元件測試 系統測試的覆蓋率？
3 是否監控**的複雜度？是
4 持續的自動化設計複查？工具？
5 **審查自動化？
6 是否監控**的重複情況
7 是否產生覆蓋率報告？
持續整合的目的就是搞隨時隨地可發布的軟體。
你寫的軟體真的可以隨時隨地可發布麼？
假如外包軟體，在期望時間內最終向使用者提交高品質能工作的軟體，而不是噩夢發行版，失去控制，每個人驚慌失措、失眠、白頭髮…
高效的建立能工作的軟體是專業軟體開發者存在的理由。持續整合使得平時工作可能稍微繁瑣，但是發布的工作量變小而且穩定性提高。
專案持續部署：
1 是否擁有回滾發行版本的能力？
2 構建版本控制庫中的構建版是否打上標籤？
3 候選發行版 是否整套自動化測試和人工測試？
4 團隊如何處理缺陷修復的發布？
5 版本控制標籤和構建版本標籤是否相關？
6 構建是否提供反饋報告
7 是否命令列單條命令部署軟體？
8 能否從版本庫中取出所有軟體資產進行構建部署？
9 能否在乾淨的計算機上正確安裝並執行？
10 是否有缺陷追蹤系統？能否自動生成報告？
一切都在變化，不斷擁抱變化
在正確的時間（每天/每週/問題發生時），以正確的方式（電子郵件/簡訊），講正確的資訊（構建狀態/審查報告/測試結果）傳送給正確的人（構建負責人，技術負責人，專案經理，產品經理，業務分析師，開發者）。
是否有太多的人過於頻繁的收到反饋資訊？
反饋是否及時？
資訊是否適量？
專案團隊在地理位置上是否是分布式的？資訊發射器自動化？
反饋機制有趣麼？
持續反饋裝置cfd,向專案風險承擔者通知構建是否失敗，比如**重複率超過百分比。
持續整合 軟體質量改進和風險降低之道
size medium 粗略翻了一遍jolt大獎書籍 持續整合 軟體質量改進和風險降低之道 發現基本原則和我前面在做的並無差別，不過對方顯然是百試不爽經驗豐富，我在具體操作的過程中卻停下了無數次，按照陽明先生的話來說，不能實踐的知，實在不是真知，結合自己的認識，把讀書後獲得的一點小的總結放到後面，用...
持續整合質量保證方案
需求評審 介面 使用者介面 功能 效能 安全性 單元測試 junit 掃瞄 sonar 依賴檢查 引用包安全性 測試用例評審 實際評審和需求及開發會並行進行 介面測試 postman http介面 自定義測試工具 dubbo jsf http介面 robot framework 功能測試 robot...
如何提高研發質量與持續整合
隨著軟體業的不斷發展，軟體專案的規模越來越大，軟體結構越來越複雜，技術要求越來越高，參與人員越來越多，管理也變得越來越難。在這樣乙個大背景下，如何提高軟體研發質量，相信是所有軟體公司都在關注的話題。但是，如何提供研發質量，這決不僅僅是乙個口號，我們必須有一套行之有效的方法加以管理。然而有效的管理帶來...