UXが向上したCodePipelineのメリット

そうなんですよ！昔のCodePipelineのUIは「なんで俺だけWindows95なん？」って言いたくなるくらいの地味っぷりでしたが、今はしっかり“令和の顔”になってます。左から右に流れる構成、ステージごとの視認性の高さ、実行ログの確認のしやすさ…地味にどれも便利です。

UXの進化ポイント

• ビジュアルフローが見やすい
  • ステージ・アクションの流れが一目瞭然なので、どこで止まったか、どこを承認待ちかが分かりやすいです。
• 実行履歴やログもワンクリックで到達できる
  • CloudWatch Logsとの連携も改善されていて、デバッグも以前より楽になっています。

辛い構築 = きめ細かさの代償

たしかに「初期構築のつらみ」はまだ健在です。codebuild.yml や各IAMロール、イベント連携など、一個ずつ設定するのは結構骨が折れます。ただそれはつまり、「自分たちで全部決められる」自由度の裏返しなんですよね。

TerraformのCI/CDのように、壊れたら即インフラ大惨事なワークフローでは、この「カチカチに定義できる」構成こそが一番安心できます。

Github側でどうなろうと、Approveさえしなければパイプライン自体を改ざんされる恐れがほぼ考えられない

この一言が刺さります。GHAだけでやっていると、ブランチ保護ルールやPRレビューをかいくぐって、CIの定義自体を書き換えられるリスクが付きまといます。そしてそのまま危険な apply を実行される…というパターンも想定せざるを得ません。

CodePipelineなら、パイプラインの本体はAWSの中にあるので、GitHub上のコードでワークフロー自体を乗っ取るのは非常に難しい。Approveアクションを入れておけば、たとえplanが流れても、「applyに行くには人間の判断が要る」状態にできます。

結論：「安全性のために面倒を受け入れられる構成」

CodePipelineは、まさに「使いこなせれば最高の守り刀」みたいな存在です。ちょっと重いし研ぎにくいけど、その分絶対に折れない。TerraformでのCI/CDには、その安心感が何より頼もしいですね。UXの進化も追い風、ますます頼れる存在になってきました。