こんにちは。
今回はAWSで動くアプリケーションのリリース自動化について書きます。
想定読者
①AWS運用（インフラ）しているが、リリースは手動で行っていて、面倒に感じている
②リリース自動化担当になったが、自動化するメリットやどの範囲まで自動化できるのか分かっていない
※①は今の、②は過去の自分です。
記事のテーマ
・【AWS運用担当者向け】リリース自動化導入の全体像把握と始め方
リリース自動化の威力
リリース自動化の導入可能な範囲
リリース自動化導入後のつまずきポイント
まずは何を学ぶか、どう学んでいけばよいか
秒間数百アクセスの大規模ECサイトのリリース自動化を設計した経験で得た知見を纏めます。
なぜ自動化するのかという点については下記も参考にしてみてください。
（クラウドのベストプラクティス集に自動化必須の旨が記載されています）
AWS Well-Architected 5本の柱を要約する（運用上の優秀性）
リリース自動化の威力
自動化というと面倒なことを自動化して運用が楽になるというイメージが先に来ると思うのですが、それだけではなく、システムの品質があがるという効果があります。
物事が簡単にできるということで劇的に変わることの例えです。
EX.水道が無かったら
⇒体を洗うのに川に水を浴びに行かないといけない
⇒体を洗う頻度は下がる
⇒健康を害したり、体臭を気にするようになる
⇒生活の品質が下がる
Ex.リリースに置き換えると
⇒リリースが自動化されて簡単にできるようになったら
⇒リリースの頻度が変わる
⇒細かくリリースするようになる
⇒細かいリリースは品質を上げる
リリース自動化の導入範囲
リリースフローの中でどの部分が自動化可能か、その中でどれを自動化するべきかを考えます。
案件毎に違うかもしれませんが、リリースの一般的な流れは下記の通りだと思ってます。
○開発
・自分の開発端末での開発（コード修正、試験）
・バージョン管理ツール（CodeCommitやGITやSVNなど）へのアップ
・コードレビュー
○検証
・バージョン管理ツールから検証環境へコピー
・検証環境固有の情報の注入
・（必要な言語なら）ビルド
・新機能の検証、試験の実施
・既存機能の検証、試験の実施
○リリース準備
・有識者のリリース判定会（検証結果を基に）
○リリース（サービスイン）
・バージョン管理ツールから本番環境へコピー
・本番環境固有の情報の注入
・（必要な言語なら）ビルド
・サービスイン
・（可能なら）簡易動作確認
上記の流れの中で自動化できることは
○検証
と
○リリース（サービスイン）
です。
その中でも自動化が困難、不可な部分は諦めます。
リリース自動化導入後のつまずきポイント
・自動化処理がエラーとなり、手動リリースが行われ、自動化環境のメンテもされず、徐々に自動化が使われなくなる
⇒自動化の設計時に自動化環境の維持をどうするか検討した方が良いです。
・パラメータ変更時に自動テスト用のコードも修正しないといけなくなる。（2重管理状態になる）
⇒何をテストするべきか検討した方が良いです。（多少のリスクはとっても）パラメータの自動試験は行わず、サイトの動作についてのみ自動試験を行うようにした方が良いと考えています。
※テスト自動化は自分でも最適解が分っていないです。ここはもう少し勉強します。
データベース変更のようなサービス停止が必要なリリースでは自動化使えない？
⇒画像だけが変わる、アプリケーションコードが変わる、サーバ設定が変わる、データベースのテーブル列が増える、色々なリリースパターンを考えてそれぞれの自動化設計を行うようにします。
頻度が少ないリリースパターンなら自動化しないという選択もあるかと思います。
まずは何を学ぶか、どう学んでいくか
Codeシリーズでスクリプト（シェル）をデプロイしてみるのが良いと思っています。
バージョン管理ツール、AWSのCodeシリーズの理解につながります。
色々なツールがありますが、AWSであればまずはGit（or CodeCommit）、CodePipeline、CodeDeployを利用してみてください。
環境固有の情報はSystemsManagerのパラメータストアで管理するようにします。
全体像のイメージは下記のくろかわさんの動画が分かりやすいです。
【はじめてのCI/CD】AWSでやってみるDevOps最初の一歩、CodeDeploy、CodePipelineを使った自動デプロイのハンズオン
IaCを利用して自動化環境を構築する場合は、下記が大変参考になります。
aws-samples/aws-cdk-examples/python/codepipeline-docker-build/
IaCについては下記に記事を書いていますのでご参考ください。
AWS自動化の心得（IaC編）