1. CI(持續集成)
CI技術已經出現很多年了（出書年是2015），因爲在微服務之間的映射、構建以及代碼庫版本管理等方面，不同的考慮會有不同的選擇。
CI能夠保證新提交的代碼與已有代碼進行集成，從而讓所有人保持同步。CI服務器會檢測到代碼並檢出（check-out），然後花些時間來驗證代碼是否通過編譯以及測試能否通過。
CI的好處有很多。通過它，我們能夠得到關於代碼質量的某種程度的快速反饋。CI可以自動化生成二進制文件，並且使用的代碼都會歸納到版本控制，所以CI可以很方便的完成更新、測試、回滾的高度自動化，當然回滾是需要人操作的。
作者提出，很多團隊正在做的CI並不是真正的CI，因爲它們並沒有嚴格遵循下面的操作：
- 是否每天合併代碼到master？
- 我們應該讓自己和他人的本地代碼儘快的與主線進行合併，如果沒有就會導致將來的集成非常困難。即使你只使用生命週期很短的分支來管理這些修改，也要遵循此原則。
- 是否有一組測試來驗證修改？
- 如果沒有測試，我們只知道集成後沒有語法錯誤，但無法知道系統的行爲是否被破壞。沒有對代碼行爲進行驗證的CI不是真正的CI。
- 當構建失敗後，團隊是否把修復CI當做第一優先級的事情來做？
- 如果在構建失敗後還允許繼續提交修改，那麼用於修復構建的時間就會大大增加。
2. 把CI應用到微服務
理想化的CI應該是：
- 每個微服務都有自己的CI，這樣就可以在將單個微服務部署上線時做一個快速的驗證
- 每個微服務都有自己的代碼庫，分別綁定相應的CI；當對代碼庫進行修改時，只運行相關的構建以及其中的測試。
- 每個微服務的測試代碼也應該和服務代碼放在一起，這樣就容易知道對於某個服務來說應該運行哪些測試。
如果你對某個服務負責，就應該同時對相關的代碼庫和構建負責。
3. 構建流水線和CD（持續交付）
作者說到在早些時候使用CI時，把一個構建分成多個階段是很有價值的。比方說，測試環節包含了多個測試步驟，其中有的能夠快速完成，有的比較耗時，如果所有測試一起運行，那一個快速測試失敗後還得等待耗時測試的完成，這個等待其實沒有意義，因爲在一個測試失敗時就應該立即停止構建流程。
解決這個問題的一個辦法就是將構建分成多個階段，從而得到我們熟知的構建流水線。在第一個階段運行快速測試...
CD基於上述的基本概念，並在此之上有所發展。它能夠檢查每次提交是否達到了部署到生產環境的要求，並持續把這些信息反饋給我們。爲了更好的理解這些概念，在這裏我們把從代碼提交到部署上線這個過程中所需要的流程進行建模。在CD中，我們會把多階段構建流水線的概念進行擴展，從而覆蓋軟件通過的所有階段，無論是手動的還是自動的。
下面是一個使用構建流水線建模的標準發佈流程：
編譯及快速測試——耗時測試——用戶驗收測試——性能測試——生產環境
我們需要一個真正重視CD概念的工具來輔助它的實施，作者提到，很多人嘗試對CI工具進行擴展來做CD，這樣的結果就是得到一個複雜的系統。所以，我們應該選擇專門的CI和CD工具。
4. 結束
在書中本章的內容到此還遠遠沒有結束，但對我個人來說，我認爲沒有記錄的必要了，因爲這些內容描述的多是一些七八年前的一些概念性的東西，我能夠明顯感覺到一些老舊過時的氣息。當然這只是我個人的想法，如果讀者有興趣可以親自去閱讀本章剩餘內容。
我找了一篇個人覺得還不錯的描述CI/CD的文章，有興趣可讀。