CI/CD ツール導入で達成した、開発と運用の協力関係強化とストレスフリーなリリースプロセスの実現に迫る！

CODT2023登壇資料。AWSサーバーレスウェブアプリケーションのリリースエンジニアリングをCICDを用いて導入したケースの紹介。

Transcript

1. / CI/CD ツール導入で達成した、 開発と運用の協力関係強化とストレスフリーなリリースプロセスの実現に迫る！
2. / /20 ―― 本セッションについて ―― 1  ゴール • CI/CDツールを用いた運用チームへの展開方法の一例を知ってもらう • CI/CDツール（GitHub Actions）の基本的な使い方  こんな方向けのセッション • 開発チームから運用チームへの業務展開する際に悩んだことがある方 • CI/CDツールをプロダクトに適用されたことがない方
3. / /20 ―― 今回の発表で焦点を当てるケース ―― DevOps ソフトウェア開発の現場ではDevOpsの考えが広まり、 適用されているチームの皆さんも多いのではないでしょうか？ 4
4. / /20 ―― 今回の発表で焦点を当てるケース ―― DevOps ソフトウェア開発の現場ではDevOpsの考えが広まり、 適用されているチームの皆さんも多いのではないでしょうか？ 開発と運用を“同じチーム”で実施する チーム”連携”を迅速に実施する Devチーム とOpsチーム が “ストレスなく協力できる”関係を築くことが重要 4
5. / /20 当社でも取り掛かっているものの、 組織間でストレスフリーで実施することは難しい、、 5 ―― 今回の発表で焦点を当てるケース ――
6. / /20 ―― 発表題材の大規模社内DXツールの概要 ―― 6  特徴 • AWS*を用いたクラウドネイティブのサーバーレスWebアプリケーション 本発表内容はサーバーレス以外も有効と思われます！ • 3つの組織が関わる体制で内製開発（アジャイル手法を採用） 1．企画チーム 2．開発チーム（自組織） 3．運用チーム  大規模社内DXツール（大規模：30~40の組織に展開） 当社のインフラ設備で日々実施している紙媒体中心での点検業務を スマートフォン1台（片手）で実施するWebアプリケーション *AWS (Amazon Web Services)は、米国その他の諸国における、Amazon.com, Inc. またはその関連会社の商標です
7. / /20 • ユニットテスト • 統合テスト ―― 当社で抱えていたストレスポイント ―― 大規模社内DXツールの開発・運用体制は、以下で実施 5 • 実装 • レビュー 開発チームの責任領域 運用チームの責任領域 … … ※デプロイ工程から委任した理由は後ほど説明 • 実装 • レビュー • デプロイ • 環境管理 • モニタリング • ヘルプデスク
8. / /20 • ユニットテスト • 統合テスト ―― 当社で抱えていたストレスポイント ―― 大規模社内DXツールの開発・運用体制は、以下で実施 5 • 実装 • レビュー … … • 実装 • レビュー • デプロイ • 環境管理 • モニタリング • ヘルプデスク 運用チームのリリースプロセス（ ）がストレスを抱える、、
9. / /20 なぜリリースプロセスでストレスを抱えていたか、、？？ ―― 発表題材の大規模社内DXツールの特徴（デプロイ） ―― 6
10. / /20 ―― 発表題材の大規模社内DXツールの特徴（デプロイ） ―― 一般的なサーバーレスWebアプリケーション ap-northeast-1 管理者 S3（Hosting） API Gateway Lambda Congnito DynamoDB X4 X10 CloudFront S3（Storage） CloudFront S3（Hosting） API Gateway Lambda WAF 7 X8 ユーザー
11. / /20 ①インフラストラクチャ：IaC（Terraform）でサービスをプロビジョニング ap-northeast-1 S3（Hosting） API Gateway Lambda Congnito DynamoDB X4 X10 CloudFront S3（Storage） CloudFront S3（Hosting） API Gateway Lambda WAF 7 X8 ―― 発表題材の大規模社内DXツールの特徴（デプロイ） ―― 管理者 ユーザー / /
12. / /20 ②バックエンド：Lambda（Chalice）でプロビジョニング ap-northeast-1 S3（Hosting） API Gateway Lambda Congnito DynamoDB X4 X10 CloudFront S3（Storage） CloudFront S3（Hosting） API Gateway Lambda WAF 7 X8 ―― 発表題材の大規模社内DXツールの特徴（デプロイ） ―― 管理者 ユーザー /
13. / /20 ③フロントエンド：ReactをビルドしてS3にアップロード ap-northeast-1 S3（Hosting） API Gateway Lambda Congnito DynamoDB X4 X10 CloudFront S3（Storage） CloudFront S3（Hosting） API Gateway Lambda WAF X8 ―― 発表題材の大規模社内DXツールの特徴（デプロイ） ―― 7 管理者 ユーザー /
14. / /20 Private ―― 発表題材の大規模社内DXツールの特徴（デプロイ） ―― S3（共通ストレージ） VPC デプロイ体制は、開発チームと運用チームで責任領域を明確化 開発チーム 運用チーム Src Upload S3（共通ストレージ） EC2 SSM (Session Manager) デプロイ環境 本番環境① 本番環境② 本番環境③ 本番環境④ 本番環境⑤ 本番環境㊵ ： 8
15. / /20 9 ―― 発表題材の大規模社内DXツールの特徴（デプロイ） ―― 1. EC2にSSM セッションマネー ジャーにてアクセス 2. 本番環境のステータス確保の外部 ストレージ作成 3. クレデンシャル情報の登録 4. exec_terraform.shの編集・実施 5. provider.tfの編集 6. Terraformコマンドの実施 デプロイ環境に入ってからは、以下のようなマニュアルに従い実施 (1) Terraformのデプロイ手順書 7. exec_chalice.shの実施 8. “6~7”の実行結果をエクセルシー トに記載 (2) Chaliceのデプロイ手順書 (3) フロントのデプロイ手順書 9. “8”で記載したエクセルシートを参 照して、.”env”を編集する 10.npm package.jsonをインストー ル 11.npm buildでビルドする 12.aws s3バケットにアップロード 13.アプリケーションの正常性確認
16. / /20 使い慣れないモダンなツールの操作×環境数 ＝多大な時間＋人為的なミスが発生しやすい環境下 9 ―― 発表題材の大規模社内DXツールの特徴（デプロイ） ―― ※手順書実施時の注意点 IaCの特性上、デプロイした環境情報を”適切に”管理する • 運用チーム側で計30~40環境をディレクトリ毎に管理 • ユーザー組織に合わせた柔軟な変更 （例：パスワードポリシー、ログ保存先など） 環境整理の面で運用チームもIaC技術が必要に… デプロイ環境に入ってからは、以下のようなマニュアルに従い実施 1. EC2にSSM セッションマネー ジャーにてアクセス 2. 本番環境のステータス確保の外部 ストレージ作成 3. クレデンシャル情報の登録 4. exec_terraform.shの編集・実施 5. provider.tfの編集 6. Terraformコマンドの実施 (1) Terraformのデプロイ手順書
17. / /20 ―― 現状と成し遂げたい姿の整理 ―― 10 現状（ストレスポイント） 成し遂げたい姿  リリースプロセスに多大な時間 • 使い慣れないモダンなツール操作で 人為的なミスが発生しやすい環境下 • 環境数が多い  デプロイ環境の整備 • 本番環境のクレデンシャル情報を 開発環境と同様に所持 • 環境数が多い場合のIaC、 ステータス管理 • ソースコードの連携面にも課題あり、、  リリースプロセスの時間を 従来の1/5までに短縮  デプロイ環境の整備 • 本番環境のクレデンシャル情報最適化 • IaC、ステータス管理をソースコード 側に委任 • ソースコードの連携面の 時間を”ゼロ”に
18. / /20 当社での開発チームが扱えるものとして、  GitHub Actions • 既存のコード管理で活用しており、拡張が容易 • パラメータ管理/トリガー戦略を同一設定ファイル（一部UI）で可能  AWS CodePipeline • AWSサービスとの連携面が強く、拡張が容易 • パラメータ管理/トリガー戦略をツールまたぎで設定が可能 ―― 成し遂げたい姿の実現方法を立案 ―― 11 普遍的な解決策が揃いつつあり、その一つが CI/CD ツールの活用 Enterpriseの無料枠で実施
19. / /20 トリガー設定 例） ・プッシュ ・プルリクエスト などで、ユースケースに 合わせて設定可能 ```bash git commit –am “msg” git push origin main ``` 仮想OS設定 一連のジョブを実施する環 境設定を記載 例） ・OS ・ディストリニューション ・ジョブの初期設定 - shell - 初期ディレクトリなど ―― GitHub Actionsの使い方（1/2） ―― 12 GitHub ActionsのYAMLファイル name: job name on: push: branches: - main pull_request: branches: - main jobs: provision: runs-on: ubuntu-latest steps: - name: Git clone the repository uses: actions/checkout@v3 仮想環境に レポジトリ内容をコピー
20. / /20 ライブラリ設定 一連の定型的な設定ジョブを 提供してくれている 例） ・AWSクレデンシャル情報 設定 ・各種プログラミング環境の セットアップ ※引数に与える情報を GitHubレポジトリに環境を 渡すことができる 例） ${{ secrets.var }} ${{ vars.var }} ―― GitHub Actionsの使い方（2/2） ―― 13 GitHub ActionsのYAMLファイル name: Configure AWS Credentials uses: aws-actions/configure~ with: access-key-id: ${{secrets}} secret-access-key: ${{secrets}} region: ${{env.AWS_REGION}} name: set terraform tfstate run: | touch file echo "var1 = ¥"${{vars}}¥"" >> file echo "var2 = ¥"${{vars}}¥"" >> file chmod +x test.sh sh test.sh ~ ~ 細かい設定 ライブラリ提供では補えない or 既存環境でスクリプトが組ま れている場合 には、シェルを組める ※シェルスクリプトの場合 権限に実行権限を付与する必 要があり
21. / /20 基本的な恩恵に加えて、 オプション設定でニッチな需要も解決！ ―― 本施策の運用YAMLファイルの一部 ―― 14
22. / /20 on: workflow_dispatch: inputs: environment: type: environment bool: type: boolean textfield: type: text choice: type: choice options: - 1st - 2nd 抱えていた悩み ①運用チームに各環境設定 の裁量を持たせたい ②新しい技術習得はなるべく 避けたい 応えてくれたオプション設定 トリガーをGUI提供 workflow_dispatchで、 ・選択（環境ごと） ・ブーリアン ・テキストフィールド をブラウザで完結できる！ 15 GitHub ActionsのYAMLファイル ―― 本施策の運用YAMLファイルの一部 (1/2) ―― ※スライドの都合上、Tabが合っておりません
23. / /20 16 GitHub ActionsのYAMLファイル ―― 本施策の運用YAMLファイルの一部 (2/2) ―― 抱えていた悩み ③IaCのステータス管理を ソースコード側に委任 ※CI/CDはジョブごとに環境構築破棄 サイクルを繰り返す 応えてくれたオプション設定 柔軟なシェル設定 ※特別な設定ではないが、以下の対応 1. 外部ストレージの確保 2. 設定ファイルの編集 3. ステータスファイルの アップロード 4. IaCのコマンド実施 2回目以降） 1. ステータスファイルのダ ウンロード 2. 以降、初回と同じ if [ ${{ github.event.inputs. bool }} ]; then aws s3 mb s3://${{ var }} sed -ie "s/%var%/${{ var }}/g" cfg : aws s3 sync cfg s3://${{ var }} else aws s3 sync cfg s3://${{ var }} fi ~ ~ 基本的には外部ストレージと連携してくれるオプションがないかを探す 本施策ではChaliceのステータス管理で、この方法を選択
24. / /20 ―― GitHub ActionsのTips ―― 17 ①環境設定 ②コミュニティ質問 各環境のパラメータを用意して、選択できる 悩めばコミュニティ質問で閲覧から質問投稿 今年1月のアップデート！* 数日程度の返答実績 *https://github.blog/changelog/2023-01-10-github-actions-support-for-configuration-variables-in-workflows/ ；2023年8月2日時点
25. / /20 Private ―― 発表題材の大規模社内DXツールの特徴（再掲載） ―― S3（共通ストレージ） VPC デプロイ体制は、開発チームと運用チームで責任領域を明確化 開発チーム 運用チーム Src Upload S3（共通ストレージ） EC2 SSM (Session Manager) デプロイ環境 本番環境① 本番環境② 本番環境③ 本番環境④ 本番環境⑤ 本番環境㊵ ： 18
26. / /20 ―― 最終的なデプロイ体制 ―― Actions デプロイ体制は、開発チームと運用チームでGitHubを中心に据えて連携 開発チーム 運用チーム Src Upload 本番環境① 本番環境② 本番環境③ 本番環境④ 本番環境⑤ 本番環境㊵ ： 18 数クリックの半自動化 Actions実行権限付与
27. / /20 ―― 実績と運用者の声 ―― 19 本施策により、以下の実績と運用チームからのフィードバックを獲得 Devチーム とOpsチーム が 協力しながらリリースプロセスを改善  リリースプロセスの時間を 半自動化により減少 320 時間/デプロイ ⇒ 40 時間/デプロイ  デプロイ環境の整備 • 環境管理をソースコード側（※IaCのカテゴリ化） やEnviromentに移行 • 開発チームとの統合環境で連携を容易に 手作業で数時間かけていたが、新しい技術を覚えず に数クリックでやってくれてありがたい 時々ライブラリアップデートで失敗するが、 人為的ミスの切り分けをすぐ区別して報告できた 入力パラメータの設定を変更してほしい 本番環境適用後の品質調査も 自動化できるようになってほしい
28. / /20 ―― まとめ ―― 20  大規模社内DXツールの体制において、 運用チームが請け負うリリースプロセス（時間・環境）に課題があった  普遍的な解決策であるCI/CDツール（GitHub Actions）を採用して、 リリースプロセスの半自動化システムを構築した 本施策での特徴 • 運用チームに裁量を持たせる/新しい技術習熟をなくすために、Webブラウザで数クリックで実施 • デプロイ環境の整備として、環境整備をソースコード側やGitHub Actions側に移行 Appendix • デプロイする環境数が多いことが要因の一つでもあったため、リアーキテクトの観点でも見るべき • 品質調査の自動化など課題点も見つかったので、継続してDevOpsの推進を図っている
29. / ご視聴、ありがとうございました