昨日講到CICD Pipeline的目的是利用自動化的手段，去讓整個軟體開的的流程更安全及可靠。
自動化的好處是讓開發人員可以習中精力去編寫程式碼，而測試及部署的部份則交由一套預先設計好的CICD Pipeline去執行。所以為了實現以上的目的，一般我都會把CICD Pipeline大致分為以下的階段去設計合適的方案。
用來管理及追蹤整個開發過程。一般中型或以上的項目，很多時候都會多於一位程序員對同一個程式進行開發。所以就要利用到版本管理工具，去協調及同步程序員之間的開發內容。
與此同時，版本管理工具在我們整個自動化的過程中，將會作為程序員進行部署的入口。跟據CICD Pipeline不同的設計，程序員可以利用標籤(Tag)或是分支(Branch)去觸發(Trigger)整個CICD Pipeline。
持續整合是一條CICD Pipeline的重心。一般來說，整個CICD大部份的步驟，例如之後的持續測試流程或是持續交付的流程，都會在這個階段進行編排(Orchestration)。也就是說，一個CICD中會執行甚麼動作，都可以按不同的程式語言、部署環境、或者不同的需求，而安排執行不同後續的步驟。
在我個人的經驗當中，持續測試對於整個開發項目來說，有著十分重要的角色。因為一個好的CICD Pipeline設計中，這個階段可以最大限度保障及提升整個項目的安全性和可靠性。
在不同的需求下，測試中所需要使用的工具都各不相同。而這次鐵人賽的系列中，我會主要介紹以下幾類測試中所用到的工具：
一般開發過程完成後，我們會把相關的程式碼打包成為一個可以執行的程序，或是可以被引用的套件。而這個打包後的文件，我們通常都會把它放到成品倉庫中進行存檔，以便以後需要的時候可以隨時存取利用。
另外今天虛擬化的技術日趨成熟，Docker Image的使用越見頻繁。在High-Availability (HA)及Disaster Recovery (DR)的設計下，Docker Image更加需要一個儲存倉庫，以便隨時取得編寫好的Docker Image去生成一個新的Pod。因此一個安全可靠的成品倉庫絕對是相關架構中的必須品。
使用成品倉庫的好處是可以有系統化的管理相關的套件/程序。由於成品倉庫中的文件已經打包完成，往後即使項目的套件供應鏈中有缺失亦不會受到影響。另外如果要存取舊版本的程式時，亦可以更快捷便利地存取及部署相關版本的程序。
持續交付跟持續部署是兩個類似但有點不同的概念。持續交付是把程式交付到維運人員(Operation)以便進行下一步部署的動作，後續可以以自動化或手動的方式部署到生產環境中。持續部署則是以完全自動化的方式部署到生產環境中。而本系列的內容，將會主要介紹自動化部署工具，亦即是如何進行持續部署的部份。
每個階段中，我們可能會利用到一套或以上的工具去幫助我們建立這條自動化的管道。由於今次設計的重點是不用吃土降低成本，所以我們今後會逐一介紹相關的開源工具。明天，我們會先開始講一講版本管理的工具。
當初定下這個題目的時候没有細想，現在發覺好像太多內容需要寫出來，這幾天占據了我大量工餘時間去準備接下來的文章。希望接下來這三十天，我能夠成功撐得過並順利完賽吧⋯⋯
iThome鐵人賽
看影片追技術