CI/CD（持續整合構建/持續交付）：如何測試/整合/交付專案程式碼？（Jenkins，TravisCI）
Table of Contents
CI(Continuous integration，持續整合)
Different types of testing explained
TravisCI -Test and Deploy with Confidence
CI(Continuous integration，持續整合)
CI(Continuous integration，中文意思是持續整合)是一種軟體開發時間。持續整合強調開發人員提交了新程式碼之後，立刻進行構建、（單元）測試。根據測試結果，我們可以確定新程式碼和原有程式碼能否正確地整合在一起。借用網路圖片對CI加以理解。
持續構建一直是比較熱門的話題，通過持續整合可以自動編譯、打包、簽名專案，配合單元測試可以實現持續整合+自動化測試。本文在結合CI的基礎上，通過fir-cli的釋出命令，完成了持續整合+自動化部署。讓工程師從重複而又枯燥的手動打包完全解放出來，讓工程師能更加專注於程式碼本身，最大限度的減少誤操作風險，降低修復錯誤程式碼的成本，大幅提高工作效率。 --https://www.jianshu.com/p/3025c3814961
CD(Continuous Delivery， 持續交付)
CD(Continuous Delivery， 中文意思持續交付)是在持續整合的基礎上，將整合後的程式碼部署到更貼近真實執行環境(類生產環境)中。比如，我們完成單元測試後，可以把程式碼部署到連線資料庫的Staging環境中更多的測試。如果程式碼沒有問題，可以繼續手動部署到生產環境。下圖反應的是CI/CD 的大概工作模式。
Different types of testing explained
https://dev.to/thejessleigh/different-types-of-testing-explained-1ljo
前幾天，在站立時，我的團隊的DBA正在談論為他最近的專案執行煙霧測試。我以前聽過人們談論煙霧測試，但是由於某種原因，它從未真正使我不知道煙霧測試是什麼。它與單元測試有何不同？整合測試？迴歸測試？
在這一點上，我無法表達這些東西之間的區別讓我感到有些尷尬，因此，我決定進行一些研究，並寫一個直譯器，以便將來我可以參考它，而不會覺得自己是無知的橡皮筋。我認為，由於我已經從事開發工作了將近5年，並且遇到了這個問題，所以可能還有其他一些人同樣也不太願意提出這樣的問題。
閱讀了許多不同的部落格文章，堆疊溢位問題和隨機資源後，我為幾種不同類別的測試構建了共識的弗蘭肯斯坦近似。在花了一些時間進行谷歌搜尋之後，我認為要理解各種測試需要考慮三件事。
- 1.）他們測試什麼樣的東西？
- 2.）這些測試什麼時候編寫和執行？
- 3.）測試失敗會提供哪些資訊？
不同的人有不同的定義，一個測試套件可能包含多種型別的測試。例如，您可能要執行一組將整合測試和迴歸測試組合到一個套件中的測試。沒關係。有灰色地帶，團隊有養成自己的，特定於團隊的詞彙的習慣。您不需要為每個類別都提供全面的套件。您應該在以下方面進行測試：
- 您的應用程式的複雜性
- 您的應用看到的流量
- 您的團隊規模
如果您認為我根本錯誤地描述或忽略了一些重要的事情，尤其是在進行測試時，請在評論中告知我！
單元測試
他們測試什麼？
單元測試評估程式碼的每個原子單元都按照預期的方式執行。理想情況下，在計劃和編寫單元測試時，應隔離無法進一步分解的功能，然後進行測試。
單元測試應該沒有測試外部依賴或相互作用。您絕對應該模擬出api呼叫。單元測試純粹主義者還可以讓您模擬資料庫呼叫，並且僅在外部源提供正確輸入的情況下，才能確保程式碼正確執行。根據您現有的程式碼庫或經理的偏好，這可能無法實現。如果您無法從單元測試套件中排除資料庫功能，請確保對效能有所瞭解並尋找潛在的優化方法。我可以從經驗中告訴您，長時間執行的單元測試套件非常令人不快，並且會大大減慢開發速度。
我什麼時候執行它們？
您應該與程式碼並行編寫和執行單元測試。當人們指的是測試驅動開發時，他們指的是單元測試，並使用測試作為程式碼應完成的規範。
他們失敗了怎麼辦？
單元測試失敗使您知道特定的程式碼段已被破壞。如果您已將其分解得足夠遠，則故障應該放大無法正常工作的確切程式碼段。
故障可以幫助您快速發現並解決問題，並在需要更新規格時通知您。對於何時更新程式碼文件，它們也可能是一個很好的指南。
整合測試
他們測試什麼？
整合測試檢查兩個或多個原子程式碼單元之間的互動。您的應用程式由執行特定小功能的各個單元組成，並且這些小功能中的每一個可能都是孤立執行的，但是當您將它們編織在一起時會中斷。
整合測試還測試程式碼與外部依賴項（例如資料庫連線或第三方API）的整合。
我什麼時候執行它們？
整合測試應該是單元測試之後的下一步。
他們失敗了怎麼辦？
整合測試失敗時，它會告訴您應用程式的兩個或多個核心功能無法協同工作。這可能是您編寫的兩個模組，它們在某些複雜的業務邏輯中發生衝突，或者是第三方API更改響應結構而導致的失敗。如果資料庫連線失敗，它可能會提醒您錯誤處理錯誤。
故障可能很容易識別，或者可能需要一些手動驗證和試驗才能識別。難以解決整合測試故障表明您可以在哪裡改進日誌記錄和錯誤處理。
迴歸測試
他們測試什麼？
迴歸測試將檢查一組過去有效且應該相對穩定的方案。
我什麼時候執行它們？
您的整合測試通過後，您應該執行迴歸測試。在現有迴歸測試通過之前，請勿將新功能新增到迴歸測試套件中。
他們失敗了怎麼辦？
迴歸測試失敗意味著新功能破壞了一些現有功能，從而導致了迴歸。
故障應該讓您知道哪些舊功能已損壞，並指示您需要在新功能和舊的，已損壞的功能之間編寫其他整合測試。
迴歸測試失敗還可能表明您無意中引入了過去修復的錯誤。
煙霧測試
他們測試什麼？
冒煙測試是高階的，精心策劃的一組自動化測試，位於整合測試和迴歸測試之間的某個位置。他們在那裡的目的是為了確保您網站的核心功能沒有損壞。
這個詞smoke test似乎是對管道的影響。如果您看到煙氣或蒸汽從管道中逸出，則表明它有洩漏，需要進行修復。
我什麼時候執行它們？
冒煙測試應同時對整個系統進行測試，以確保核心功能保持完整。這些不應該是全面的。這些是您重大的，全面的，不合格的測試失敗。您應該在登臺環境和生產環境中儘早且經常（最好是每天）執行它們。
他們失敗了怎麼辦？
如果冒煙測試失敗，則說明您網站的功能存在重大問題。在解決這些故障之前，您不應部署新更改。如果它們的生產失敗，則應優先解決這些問題。
驗收測試
（我也聽說過這稱為QA / BV /手動測試等）
他們測試什麼？
驗收測試通常是在端到端開發完成之後執行的一組手動測試。他們檢查以確保所編寫的功能實際上符合所有初始規格或接受標準。
他們失敗了怎麼辦？
看起來您在編寫程式碼時錯過了一些功能。您將需要重新進行開發並修復該問題。:(
如果驗收測試失敗，您可能需要在下一次計劃過程中更早地決定驗收標準。
我什麼時候執行它們？
由於這些是手動測試，而不是作為程式碼執行的測試，因此時間安排略有不同。您和您的專案所有者應在專案開始工作之前起草一套驗收標準。發現或新增到專案中的任何其他範圍都應反映在驗收標準中。
在完成開發後，應很快進行驗收測試，以便您可以返回並在不正確的地方快速進行迭代。在單元或整合測試之後立即進行這些操作是很有意義的，在您尚未進行太多測試之前就沒有必要進行重大更改。
效能測試
他們測試什麼？
效能測試檢查產品和基礎架構的穩定性，可伸縮性和可用性。您可能會檢查每秒的錯誤數或載入頁面需要多長時間。效能測試不一定有通過/失敗標準。這個階段更多地是關於資料收集和尋找需要改進的地方。
他們失敗了怎麼辦？
效能測試不會完全以單元測試套件失敗的方式失敗。取而代之的是，您收集一組基準，並根據您希望這些數字的位置對其進行評估。如果效能測試失敗，則可能表明您需要更多地關注基礎結構擴充套件，資料庫查詢時間等。
我什麼時候執行它們？
在主要版本和重構之後，效能測試是一個好主意。
負載測試
他們測試什麼？
負載測試是一種專門的效能測試，可以專門檢查您的產品在預定時間內承受巨大壓力的效能。
他們失敗了怎麼辦？
負載測試可評估您為流量的顯著增長做好準備的情況。如果負載測試失敗，這並不意味著您的站點已損壞，但這並不意味著您沒有為病毒擊中或DDOS攻擊做好準備。對於剛開始的小型產品來說，這可能不是什麼大問題，但是隨著使用者群的擴大，失敗應該成為一個問題。
我什麼時候寫的？
負載測試不應立即成為您首先要解決的問題，但是隨著您的產品變得越來越大和越來越成熟，您可能應該對新功能進行負載測試，以檢視它們是否會影響站點的整體效能，以及是否可以優化。
我不能再說我不知道什麼是煙霧測試，希望您也能從中學到一些東西！如上所述，我不是測試人員，所以如果您發現我遺漏或誤解的內容，請在評論中告訴我！
Jenkins -最流行的開源免費持續整合工具
Jenkins是一個開源的、提供友好操作介面的持續整合(CI)工具，起源於Hudson（Hudson是商用的），主要用於持續、自動的構建/測試軟體專案、監控外部任務的執行（這個比較抽象，暫且寫上，不做解釋）。Jenkins用Java語言編寫，可在Tomcat等流行的servlet容器中執行，也可獨立執行。通常與版本管理工具(SCM)、構建工具結合使用。常用的版本控制工具有SVN、GIT，構建工具有Maven、Ant、Gradle。--https://www.jianshu.com/p/5f671aca2b5a
TravisCI -Test and Deploy with Confidence
https://www.jianshu.com/p/3025c3814961
持續構建一直是比較熱門的話題，通過持續整合可以自動編譯、打包、簽名專案，配合單元測試可以實現持續整合+自動化測試。本文在結合CI的基礎上，通過fir-cli的釋出命令，完成了持續整合+自動化部署。讓工程師從重複而又枯燥的手動打包完全解放出來，讓工程師能更加專注於程式碼本身，最大限度的減少誤操作風險，降低修復錯誤程式碼的成本，大幅提高工作效率。 --https://www.jianshu.com/p/3025c3814961
圍繞Travis-CI持續構建的核心檔案.travis.yml，根據實操所需，涉及到每個具體的點時再進一步講解相關配置，避免前期做一些零散、關聯性不強的操作產生混亂，基於操作流程再進一步細分到對應的配置點，由上而下，由裡到外的瞭解Travis-CI的執行步驟及可能遇到的問題的解決辦法。 --https://www.jianshu.com/p/3025c3814961
這是將Travis CI與您的雲平臺託管程式碼儲存庫一起使用的簡短指南。如果您不熟悉連續整合，或者想了解有關Travis CI功能的更多資訊，請改用Core Concepts for Beginners。
Travis CI 是目前新興的開源持續整合構建專案，它與jenkins，GO的很明顯的特別在於採用yaml格式，簡潔清新獨樹一幟。目前大多數的github專案都已經移入到Travis CI的構建佇列中，據說Travis CI每天執行超過4000次完整構建。