
持續交付:Why 與 What |
5
稍後的章節將會介紹,你可以將許多功能性與非功能(跨功能)屬性的斷言
(assertion)編入現代的 Java 組建管道,包括容錯、確認已知的安全漏洞是否存在,以
及基本的性能 / 負載特性(可以幫助你估算成本)。
探索典型的組建管道:What
了解持續交付管道各個核心階段的“What”或目的非常重要,因為一件事情的目標
與原則通常比實作細節重要(例如,你究竟要使用 Jenkins、CircleCI、JUnit 還是
TestNG)。
組建管道的核心階段
圖 1-1 是典型的 Java app 持續交付組建管道。CD 程序的第一個步驟是持續整合(CI)。
在這個步驟中,開發者將桌機內,已寫好的程式碼持續提交(整合)到一個共用的版本
控制存放區,它會被自動組建與包裝成工件(artifact)。接著,CI 產生的工件會進入一
系列的自動驗收與系統品質屬性驗證階段,完成後,再在越來越像生產環境的環境中進
行手動用戶驗收測試與晉升。
組建管道的主要目的,是證明你對程式碼或組態做的任何修改所產生的結果都是可放入
生產環境的。你提出的修改可能會在管道的任何一個階段失敗,這項修改可能會被拒
絕,不會被標記成可以部署至生產環境。每一個通過驗證步驟的工件都可以部署至生產
環境。我們在這個管道中收集技術與商業遙測數據,用來建立正面的回饋迴圈。