無伺服器——CI/CD 系統應該是短暫的和無伺服器的。沒必要管理 Jenkins 或單個節點。管理 CI/CD 機器使得引入配置和環境漂移變得非常容易，這會導緻難以追蹤錯誤。 Container-native 通常是一個不錯的選擇，尤其是當您經常在容器内部署軟體時，但任何提供真實臨時環境的東西都是好的。
本地（雲端）——對于小型項目，使用托管 CI/CD 服務很好，但對于任何比玩具項目更大的項目，您可能應該在自己的雲帳戶中啟動 CI/CD 運作器。
最小權限/本機 IAM – 從業人員應以雲原生方式（例如 OIDC）進行身份驗證，并使用最小權限集進行部署。雖然在項目部署更多種類和數量的服務時擴大從業人員的範圍似乎很麻煩，但限制爆炸半徑和隔離環境将使您避免出現各種錯誤和錯誤。
易于調試——易于調試意味着可以在本地以有意義的方式運作管道。這也意味着可以從運作中輕松通路日志和工件。
觸發器，但并不複雜——GitHub Actions 提供了一個很好的模型來自動運作工作流（來自拉取請求或合并事件）以及手動觸發器。但是，不要圍繞手動觸發器建構複雜的業務流程。
代碼，而不是 YAML——Code for Infrastructure ，我相信用完整的程式設計語言而不是配置語言來設計管道要容易得多。您可以獲得可重用性、控制流、強類型以及描述依賴關系圖時可能需要的其他屬性。
DAG——已經有一些關于擁有完全事件驅動的 CI/CD 系統的實驗。一般來說，我認為最好有一個編碼依賴圖的靜态 DAG。事件可能會觸發初始工作流，并可能在 DAG 競争（或失敗）時發出，但不會在兩者之間觸發。
更進一步交流可以SX加入我的知識星球擷取更多資料和雲原生技術書籍。
