在本指南中，您将了解持續內建的所有方面，它與持續部署和持續傳遞的關系以及如何開始使用這些實踐。了解了它們之後，我們将詳細讨論最佳實踐和工作流程，并在最後提供完整的資源清單。
什麼是持續內建？
持續內建（Continuous Integration）是一種開發實踐，開發人員經常将代碼內建到共享存儲庫中，最好每天進行幾次。然後可以通過自動建構和自動測試來驗證每個內建。盡管嚴格來說，自動化測試不是CI的一部分，但通常會暗示它。
定期內建的主要好處之一是，您可以快速檢測到錯誤并更輕松地定位它們。由于引入的每個更改通常很小，是以可以快速查明引入缺陷的特定更改。
近年來，CI已成為軟體開發的最佳實踐，并遵循一系列關鍵原則。其中包括版本控制，建構自動化和自動化測試。
此外，持續部署和持續傳遞已成為最佳實踐，可讓您随時随地部署應用程式，甚至在每次引入新更改時甚至将主代碼庫自動推入生産環境。這使您的團隊可以快速行動，同時保持可以自動檢查的高品質标準。
持續內建并不能消除錯誤，但确實可以使查找和删除錯誤變得更加容易。
– ThoughtWorks首席科學家Martin Fowler
持續內建，持續部署和持續傳遞之間有什麼差別？
持續內建 Continuous Integration
這種做法是将團隊中不同開發人員的變更盡早內建到主線中，最好每天進行幾次。這樣可以確定各個開發人員處理的代碼不會轉移太多。當您将流程與自動化測試結合在一起時，持續內建可以使您的代碼變得可靠。
持續部署 Continuous Deployment
與持續內建密切相關，是指使您的應用程式随時可部署，如果最新版本通過了所有自動化測試，甚至可以自動釋出到測試或生産環境。
持續傳遞 Continuous Delivery
保持代碼庫随時可部署的做法。除了確定您的應用程式通過自動化測試外，它還必須具有将其投入生産所需的所有配置。然後，許多團隊都會進行推送更改，以立即将自動化測試傳遞到測試或生産環境中，以確定快速的開發周期。
閱讀有關該主題的更多資訊：
- 持續傳遞與持續部署 作者：Jez Humble
- 為什麼您應該使用持續內建和持續部署 作者：Florian Motlik
- 持續傳遞vs持續部署vs持續內建-等待吧？由Michael Chletsos
- Florian Motlik 着手進行持續傳遞的五個技巧
- Timothy Fitz的持續部署
- Martin Fowler的連續傳遞
- 維基百科的持續傳遞
- 持續傳遞管道-它是什麼以及為什麼在開發軟體時如此重要 的作者安德魯·菲利普斯（Andrew Phillips）
第1部分：持續內建初學者指南
您應該集中精力盡早建立簡單的 持續內建過程。但這不是結束的地方。盡管持續內建（CI）很重要，但這隻是該過程的第一步。您還希望設定持續部署（CD），該流程可自動執行軟體部署并讓您專注于建構産品。
持續內建（CI）與持續部署（CD）
正如我們之前所指出的，持續部署與持續內建緊密相關，是指保持您的應用程式可随時部署，甚至在最新版本通過所有自動化測試後甚至自動釋出到生産環境中。
如果您希望真正快速地 釋出産品，則應該自動化整個工作流程，而不僅僅是測試。設計良好且運作順利的持續部署（CD）解決方案将成為您使用的工具之間，尤其是SCM（源代碼管理）提供商/伺服器與所使用的托管環境之間的粘合劑。從一開始，他們就可以依靠完全自動化的流程來幫助新員工加入并發展團隊。
在此處閱讀有關該主題的更多資訊： Jason Blanchard的“ Thoughtful：持續內建（CI）推廣”
什麼是最好的持續內建和部署工具或服務？我該如何選擇呢？
有很多解決方案。如果隻想擷取工具清單，則可以檢視Codeship，TravisCI，SemaphoreCI，CircleCI，Jenkins，Bamboo，Teamcity或許多其他工具。在Quora上，您還可以找到有關該主題的許多文章和讨論，其中包含有價值的資訊 。那裡幾乎有無限的機會。但是随後出現了一個問題：“如何在這些之間進行選擇？”
您的選擇将在很大程度上取決于：
- 根據您的要求，
- 在您擁有的技術堆棧上，
-
有關如何處理日常工作流程的資訊。
正如Codeship首席執行官Moritz Plassnig 在Quora上指出的那樣，通常可以先提出幾個簡單的問題，然後在選擇任何解決方案之前将其回答。這将幫助您确定哪種解決方案最适合您。
- http://stackshare.io/codeship
- https://www.g2crowd.com/products/codeship/reviews
- http://www.quora.com/Reviews-of-Codeship-Software/
托管與非托管解決方案
您必須做出的第一個決定是要托管的軟體即服務（SaaS）解決方案還是自托管的解決方案。
如果您喜歡自托管解決方案，則需要管理自己的伺服器。SaaS解決方案不需要這樣做，但是如果您需要一些邊緣保護功能，它可能會受到更大的限制。如果您碰巧使用GitHub，Bitbucket，Heroku或其他雲服務，那麼您很可能需要SaaS解決方案，因為它适合您現有的工作流程。
如果資料安全性非常重要，那麼自托管伺服器可能是您更好的選擇。SaaS解決方案通常 使您可以将更多的精力放在核心産品上，因為您不必花費時間來維護基礎結構并更新所有依賴項，而無需付出一些靈活性。
測試開源軟體與專有軟體
如果您有開源項目，則可以使用任一解決方案對其進行測試。可以是托管主機，也可以是非托管主機。他們兩個都有優點和缺點。如前所述，托管（SaaS）解決方案不需要維護您身邊的伺服器，進而為您的産品工作/編碼留出了更多時間。
絕大多數SaaS解決方案都遵循GitHub模型，您可以免費測試開源項目。一些開源項目确實需要對建構基礎結構進行大量控制，盡管它們可能正在測試無法在托管解決方案中通路的作業系統的各個部分。在這種情況下，盡管增加了必要的維護開銷，但任何現有的開放源CI伺服器都應該做得很好。
持續內建和部署的優點和優勢
持續內建有很多好處。良好的CI設定可以加快您的工作流程，并鼓勵團隊推動所有更改，而不必擔心會破壞任何内容。它不僅具有更好的軟體發行流程，還擁有更多的好處。持續內建也帶來了巨大的業務收益。
降低風險
如果您更頻繁地測試和部署代碼，最終可以降低您正在從事的項目的風險級别，因為您可以更早地檢測到錯誤和代碼缺陷。這意味着它們更易于修複，您可以更快地對其進行修複，進而使它們的修複成本更低。正如Intercom的Darragh Curran在本文中所提到的那樣，這将加快回報機制并使您的溝通更加順暢： 運輸是您公司的心跳。
更好的溝通
當您擁有已插入持續傳遞工作流程中的CI流程時，可以輕松地定期共享您的代碼。此代碼共享有助于在團隊成員之間實作更大的可見性和協作。最終，由于每個人總是在同一頁面上，是以這提高了組織内部的通信速度和效率。
更快的疊代
當您經常釋出代碼時，生産中的應用程式與開發人員正在開發的應用程式之間的差距将大大縮小。您對如何開發功能的想法很可能會改變。由于将自動測試每個小的更改，并且整個團隊都可以知道這些更改，是以在開發新功能時，您将希望處理小的增量更改。這樣可以減少假設，因為您可以更快地建構功能并自動測試和部署功能，以供使用者盡快檢視，進而更快地從中擷取有價值的回報。
更快地回報業務決策
擁有配置項流程不僅對軟體開發人員有利，而且對他們的經理也有利。雙方都可以收集有價值的回報并更快地獲得見解。随着您更頻繁地推送代碼，您将擁有更多可用資料，可以對這些資料進行分析以檢查産品是否朝着正确的方向發展。這種連續的資料流和度量标準的時間表（如依賴性， 單元測試，複雜性和 代碼氣味）也可以幫助更頻繁地反映項目的進度，進而可以更快地做出技術和業務決策。
使用CI和CD的其他一些好處
- 減少開發和部署過程的開銷
- 減少內建不同代碼更改的時間和精力
- 對每個更改啟用快速回報機制
- 可以及早發現并預防缺陷
- 幫助團隊成員之間的協作，是以始終共享最新代碼
- 減少手動測試工作
- 逐漸建構功能可以節省調試時間，是以您可以專注于添加功能
- 邁向完全自動化整個釋出過程的第一步
- 定期整合以防止不同分支機構出現分歧
-
如果您要使用的功能長期運作，則可以持續內建，但請使用功能标志阻止釋出。
在此處閱讀有關該主題的更多資訊：持續內建的好處 Joe Green
第2部分：深入了解持續內建和持續傳遞
如果您對持續內建教程和最佳實踐感興趣， 建議您閱讀下面提到的一些工程部落格。您可以在那裡找到非常有用的内容。
自2006年以來，CI和CD的格局正在迅速變化和塑造。不過，值得一提的是Martin Fowler的《持續內建》的原始 原理。Martin解釋了最佳實踐工作流程：
- 維護代碼庫
- 自動化建構
- 使您的建構自測
- 團隊中每個人的每日承諾達到基線
- 每次送出（到基線）都應該建構
- 保持快速建構
- 克隆生産環境并在那裡進行測試
- 輕松擷取最新傳遞物
- 中的每個人都可以看到您最新建構的結果
- 自動化建構部署
業界一直在做得很好，以使這一點得以實作，軟體團隊在很大程度上能夠遵循這些原則。随着容器的 出現，現在克隆本地和生産環境并在那裡進行測試變得容易得多。Codeship的新Docker平台将為您提供更多的幫助。随時 在這裡了解更多資訊。
連續傳遞清單
Martin Fowler的原則是考慮最佳設定軟體開發過程的一個很好的起點。Jez Humble和David Farley在他們的《持續傳遞：通過建構，測試和部署自動化的可靠軟體版本》一書中也指出，當您要送出代碼時，以下清單應該是概述和清單。
- 送出更改之前，請檢查建構目前是否處于“成功”狀态。如果沒有，您應該在送出新代碼之前協助修複建構。
- 如果狀态目前為“成功”，則應将個人工作空間重新配置為該配置。
- 在本地進行建構和測試，以確定更新不會破壞功能。
- 如果成功，請簽入新代碼。
- 允許配置項完成新的更改。
- 如果建構 失敗，請 停止并 修複您的計算機。傳回步驟3。
- 如果建構 通過，請 繼續處理下一項。
您應該注意，這隻是一個概述。您會發現許多不遵循這些确切步驟的服務和解決方案（例如步驟2）。但是，最好知道這些步驟。為什麼？
因為許多開發人員（根據DZone 2014年的研究，高達41％）認為他們正在實作持續傳遞，而實際上隻有不到10％的人實作了。（該調查是針對500多名IT專業人員進行的。大部分受訪者是開發人員（68％）或團隊經理（14％），而業務，品質保證和執行管理人員所占比例較小。大多數受訪者的總部位于美國（36％）或歐洲（43％）。
這些人中隻有不到10％的人從事連續傳遞工作。讓這一切沉浸其中。這就是提醒我們不斷逼近真正的持續傳遞的好原因之一 。一份好的清單肯定有助于建立正确的流程，并向您的團隊以及潛在的管理人員進行解釋。
這就是研究背後的公司DZone編制清單的原因之一。在“ 持續傳遞成熟度檢查清單”中，您可以實際檢查目前執行的實踐，以了解您在“持續傳遞”的每個區域中的成熟程度。您在測試中獲得的分數越高，您越接近CD成熟度。該清單不僅在編寫代碼時遵循，而且還可以幫助您确定公司CD流程中的弱點和需要改進的地方。CD過程的主要領域包括：
- 源代碼控制
- 建立過程
- 測試與問答
- 部署方式
- 能見度
您可以在此處下載下傳他們的 清單。
克裡斯·沙揚（Chris Shayan）在此處撰寫有關持續傳遞成熟度矩陣的文章時，介紹了您可能希望了解的該過程的早期版本 。
閱讀有關該主題的更多資訊：
- Eric Minick的連續傳遞成熟度模型
- Chris Shayan的連續傳遞矩陣
- DZone的連續傳遞成熟度清單
如何開始連續傳遞
如果您想知道如何開始使用持續傳遞，我們的CTO Florian Motlik在Amazon Web Services Blog上發表的這篇文章将非常有幫助，閱讀： 持續傳遞入門的五個技巧。
如果您準備進行持續內建和傳遞，請立即嘗試您的項目，立即注冊一個免費的Codeship帳戶！隻需通過您的GitHub，BitBucket或GitLab帳戶登入。
持續內建資源
我們已編制了一份資源清單，供您開始使用“持續內建和傳遞”，如果您對本主題的了解更多，則可以進行更深入的研究。您絕對應該檢視我們的Codeship資源庫 ，在這裡可以找到免費的電子書，視訊和指南。
圖書
- 持續傳遞：通過建構，測試和部署自動化實作可靠的軟體釋出– Jez Humble和David Farley：http://www.amazon.com/gp/product/0321601912
- 持續內建：提高軟體品質并降低風險-Paul M. Duvall，Steve Matyas和Andrew Glover：http://www.amazon.com/gp/product/0321336380
- 靈活成熟度模型應用于建構和釋出軟體– Jez Humble和Rolf Russel：http://info.thoughtworks.com/agile-maturity-model-applied-building-and-releasing-software.html
- 連續資料庫內建的食譜– Pramod J. Sadalage撰寫：http://www.amazon.com/Recipes-Continuous-Database-Integration-ebook/dp/B000RH0EI4
- 清潔代碼-羅伯特·C·馬丁（Robert C. Martin）：http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
- 鳳凰城計劃– Gene Kim撰寫：http://itrevolution.com/books/phoenix-project-devops-book/
- 更快的釋出會提高軟體品質嗎？– Mozilla案例研究（PDF）http://swat.polymtl.ca/~foutsekh/docs/Khomh-MSR-2012.pdf
部落格和網站
- http://www.martinfowler.com/
- http://www.martinfowler.com/articles/continuousIntegration.html
- http://martinfowler.com/articles/is-tdd-dead/
- http://agilemanifesto.org/
- http://blog.codeship.com
- https://blog.codeship.com/testing-tutorial/
- http://blog.codeship.com/benefits-of-continuous-integration/
- http://blog.codeship.com/seven-steps-to-continuous-deployment/
- http://blog.codeclimate.com/
- http://chadfowler.com/
- https://codeascraft.com/
- https://resources.codeship.com/email-courses/continuous-delivery-crash-course
- http://patshaughnessy.net/
- https://www.twilio.com/engineering/
- http://blog.risingstack.com/
- https://blog.engineyard.com/
- https://blog.engineyard.com/2012/continuous-integration
- https://www.digitalocean.com/community
- https://www.airpair.com/posts
- https://github.com/kilimchoi/engineering-blogs
- https://www.cloudbees.com/blog
參考
https://codeship.com/continuous-integration-essentials
http://www.ruanyifeng.com/blog/2015/09/continuous-integration.html
https://martinfowler.com/articles/continuousIntegration.html