設計原則

• 盡量不改變和影響原先開發者的習慣來建置 CI / CD 流程
• 所有 CI / CD 過程均使用 AWS CDK 來 IaC 化，自動化整個流程
• 承上，若使用如 AWS CodeBuild、CodePipeline 來建造 CI / CD，其本身 AWS CodeBuild、CodePipeline 的 Infra 也是需要 IaC 化
• 依照此篇 Blog (AWS CDK best practice) 中建議的 Infrastructure code and application code lives in the same package 來設計

擬定大致上的原則後，來看一張流程圖

這邊選擇以 AWS CodeBuild 來建置 CI / CD，最後部署到 Lambda

CodeBuild Infra CI / CD 流程說明

• 這邊算是滿單純，先用 GitHub Actions (當然也可以選用其他工具，如 Travis CI 等…) 把 AWS CDK Deploy 動作自動化，先把 AWS CodeBuild Infra 建置好

• 這邊的 CodeBuild 其實要指定 repo 位置、 buildspec.yml 等，其實都跟目標要導入 CI / CD 專案有很大的相關性，所以 CodeBuild Infra Iac 也是滿有必要性，因為所有的設定都可以透過 git 來追蹤修改記錄，也方便後續接手維護的人

Lambda CI / CD 流程說明

• 依早前提到的設計原則，盡量不去改動太多原先的 repo 的內容，依流程圖中 BitBucket Lambda repo 就是原有專案，這邊把它設定為 CodeBuild 主要的 Source 來源，目前是為了開發人員 push 特定 branch 後，去觸發 AWS CodeBuild

• 依 Blog AWS CDK 最佳實踐的建議，Infra Code 和 Source Code 放在一起是個不錯的選擇，但由於不想增加原有專案的複雜性，因為開發團隊在原有專案上已經開發習慣，且專案成長的複雜度也不小，如果在原先 repo 上再加上 Infra code ，可能不是個太好的方法，所以新建一個 BitBucket Build Lambda Infra repo ，並把原有專案使用 git submodule 的方式引入 (如流程圖中所示)，如此一來，既不會影響原有的 repo，新開的 repo 也同時擁有 source code

• 承上，為何選用 git submodule 而不是 git subtree，以此情境來說，原有專案 repo 只會在原先專案中修改，而在 BitBucket Build Lambda Infra repo 中只是為了要建置 CI / CD 流程，並不會在 infra repo 去修改原有專案的檔案，故選用 submodule 個人覺得比較適合

• 依流程圖中的 BitBucket Build Lambda Infra repo 是當作 CodeBuild secondary source，而 CodeBuild 的 buildspec.yaml 主要是用 secondary source 來 Build CI / CD，而原有專案 repo 當作 CodeBuild First source 只是為了要 push trigger CI / CD

• 如此一來，在原先 Repo 中，大致上只需要新增 builspec.yml、configs/staging.yml、configs/prod.yaml (為了不同環境區分 Lambda 設定檔)，若是以 docker image 的方式建置 lambda ，則需要再多一個 Dockerfile，如此就可以在原有專案下，打造 CI / CD 管道

缺點

目前想到的缺點，在於 CodeBuild 拉取 First Source 和 Secondary Source 時，Secondary Source 的 submodule 就是 First Source，重覆拉取相同的程式碼，或許可以考慮移除 submodule，但缺點就是在 lambda infra repo 時，沒辦法很清楚看到 source code 和 infra code

結論

導入 CI / CD 是 DevOps 中的一環，目前這篇文章是站在 DevOps 和 SRE 的角度來看，盡量不影響原先開發團隊的習慣下所建造出來的一種方式，每個團隊的情況可能不盡相同，但要達到的目的都是一樣的，若有更好的建議或方法，也歡迎在下方使用 FB comment 的方式留言給我