近幾年微服務架構與容器化技術飛速發展，随之而來的是持續內建與持續傳遞的概念又重新不斷被提及，越來越多的公司開始使用持續內建系統來解決頻繁釋出帶來的品質問題，使用持續傳遞工具實作代碼的自動部署。
持續傳遞
持續傳遞（Continuous Delivery，CD）是一種軟體工程方法，開發團隊以快速、自動化和可重複的方式從源代碼生成軟體釋出版本，確定軟體可以随時可靠地釋出，它更加注重給最終使用者提供應用的能力。
随着微服務和雲原生架構的廣泛采用，對持續傳遞工具和實踐的需求越來越大。微服務帶來了許多優點，比如通過把複雜的業務拆分為若幹小業務，每個業務寫成一個服務，服務足夠内聚、足夠小，服務的邊界也明确，代碼會容易了解、開發效率得以提高；每個微服務可以獨立部署，讓持續部署成為可能；可以提高系統的容錯性，不會因為某一個服務的錯誤導緻整個系統癱瘓……
但是系統中微服務不斷增多，需要大量的協調工作才能同步地內建和部署一組微服務，這使得持續傳遞也變得複雜起來，而脫胎于微服務架構思想的容器技術正是解決這一問題的良藥。
簡單來說，通過将一個微服務封裝在一個容器中，開發者可以在這樣一個獨立的環境中進行開發，随後測試與運維人員可以直接使用這個容器進行部署并測試與釋出，大大簡化了軟體傳遞過程。
持續內建
說到持續傳遞就離不開持續內建，持續內建也就是 Continuous Integration，CI，它與持續傳遞是什麼關系呢？
持續傳遞是在持續內建的基礎上，将內建後的代碼進行釋出，供使用者使用，它強調的是“給最終使用者一個交待”；而持續內建是指開發團隊成員經常內建他們的工作，每次內建都通過自動化的建構來驗證，包括編譯、釋出與自動化測試等過程，進而盡快發現內建錯誤。
持續內建的基本思想是使用一個自動化過程監測源碼倉庫是否有變更，當變更被推送到倉庫時，它會監測到更改、下載下傳副本、建構、部署、運作相關單元測試并釋出。
随着公司業務流量、使用者數不斷增長，無論傳統的測試團隊如何增加人力，也無法解決軟體重構、系統增加新功能等測試需求，持續內建變得困難重重。前邊說到微服務架構使得持續傳遞變複雜，其實這樣的複雜性也展現在持續內建中，比如它會帶來一些問題：
- 服務傳遞周期變短，自動化測試開發速度跟不上傳遞的速度
- 多個服務同時開發，聯調耗時日益增長
- 自測時需要部署和維護多個依賴方服務
- 由于服務數量增多，鍊路變長，調用依賴增多，整個環境的搭建會十分吃力
- 多人共用一套環境，互相影響，容易影響測試結果
- 一次提測服務增多，提測了多個倉庫，使得 CI 工作爆炸性增加
- ……
然而團隊可以基于微服務架構與持續內建系統，打造自動化和流程标準化的持續內建平台，反過來讓持續內建為微服務架構強有力的基礎設施支援，充分利用微服務的優勢。
但是具體怎樣去落地呢？目前業内已經有不少團隊分享過他們打造微服務持續內建工具鍊的實踐方案，一般情況下，根據不同業務性質與團隊特性，每家都有自己面臨的問題，并且基于具體問題設計出不同的持續內建方案。
雖然方案不同，但是在傳播通用經驗方面還是起了不小的作用。在本周末開源中國源創會上，來自閱文集團的背景開發專家與使用者中心架構負責人俞慧濤也将為大家分享如何利用微服務架構 Tars 結合 CI/CD 系統 Jenkins 打造持續內建開發測試環境。機會難得，歡迎參與。詳情可以閱讀原文。
【上海】OSC源創會第84期報名中，速戳…