Git 未経験者 が GitHub Actions で CICD できるようになるまで / 20221127-JJUGCCC-2022-Fall-Git-beginner-built-CICD-pipeline-with-GitHubActions

Transcript

1. Git 未経験者が GitHub Actions で CI/CD できるようになるまで Git 未経験者が GitHub Actions で CI/CD できるようになるまで 2022-11-27 JJUG CCC 2022 Fall BABYJOB 株式会社　浅野正貴（@mackey0225）
2. Git 未経験者が GitHub Actions で CI/CD できるようになるまで このセッションについて 【内容】 Git 未経験者が GitHub Actions を用いた CI/CD を実現していく中で 得られた成果や苦労、学び・気づきについてお話します Javaについては、ほとんど登場しないです。。。スミマセン。。。
3. Git 未経験者が GitHub Actions で CI/CD できるようになるまで 目次 • 自己紹介 • 実施前の状態 ◦ 構成や改善点 ◦ GitHub Actions について • 実施したこと • 実施後の状態 • 実施したうえでの学び・気づき
4. Git 未経験者が GitHub Actions で CI/CD できるようになるまで 自己紹介 名前: 浅野　正貴 所属: BABY JOB 株式会社（2022-06 入社） 役割: Javaエンジニア Twitter: @mackey0225 GitHub: @mackey0225 経歴: - 前職: カタログ通販会社 社内SE を 8年ほど 趣味: -　2歳の息子と遊ぶこと
5. Git 未経験者が GitHub Actions で CI/CD できるようになるまで 前提の説明 【前提について】 言語 ： Java フレームワーク ： Spring Boot ビルドツール ： Gradle 環境 ： AWS Elastic Beanstalk 本番環境と検証環境の2環境 リリース周期 ： 基本として1週間 【着手前の状態】 • テストとビルドまでは自動化済み ◦ ビルド後は、人力・手動でデプロイ実施 →今回は検証環境へのデプロイのみを自動化 ◦ →テストのみで、静的解析・フォーマッターなどは未適用 • 私自身が Git / GitHub を使ったチーム開発が初
6. Git 未経験者が GitHub Actions で CI/CD できるようになるまで GitHub Actions について 概要レベルですが • GitHub が提供している CI/CD プラットフォーム • YAML で定義 • GitHub 上の様々なイベントをトリガーにすることが可能 ◦ 手動実行 や スケジュール（cron）も可能 • 利用料金は ◦ パブリックリポジトリは無料（標準ランナー） ◦ プライベートリポジトリはプランに応じた月単位の無料枠がある ▪ GitHub Free ： 2,000分 ▪ GitHub Pro ： 3,000分
7. Git 未経験者が GitHub Actions で CI/CD できるようになるまで 取り組んだこと 大きくは以下の２つ 1. AWS Elastic Beanstalk へのデプロイ処理の実装 2. 静的解析ツール・コードフォーマッターの選定と適用
8. Git 未経験者が GitHub Actions で CI/CD できるようになるまで AWS Elastic Beanstalk へのデプロイ実装 【結論】 今回、einaregilsson/beanstalk-deploy を使用した 【選んだ理由】 Elastic Beanstalk を操作する Action で 公式なものは無かった 現状の運用に沿っているもので、利用例が多いものを選んだ （コンテナであれば、docker や AWS が提供している Action はある） 【利用方法】 次ページにて簡単に紹介 【einaregilsson/beanstalk-deploy】 https://github.com/marketplace/actions/beanstalk-deploy https://github.com/einaregilsson/beanstalk-deploy
9. Git 未経験者が GitHub Actions で CI/CD できるようになるまで Elastic Beanstalk へのデプロイ実装 ＜略：検証環境向けの .war ビルドを実行＞ - name: Build zip uses: gradle/gradle-build-action@v2.3.3 with: arguments: | buildZip - name: Deploy to Elastic Beanstalk uses: einaregilsson/beanstalk-deploy@v20 with: aws_access_key: ${{ secrets.AWS_ACCESS_KEY_ID }} aws_secret_key: ${{ secrets.AWS_SECRET_ACCESS_KEY }} application_name: application_name environment_name: environment_name version_label: ${{ env.VERSION_LABEL_NAME }} region: ap-northeast-1 deployment_package: build/distributions/release.zip ＜略＞
10. Git 未経験者が GitHub Actions で CI/CD できるようになるまで Elastic Beanstalk へのデプロイ実装 ＜略：検証環境向けの .war ビルドを実行＞ - name: Build zip uses: gradle/gradle-build-action@v2.3.3 with: arguments: | buildZip - name: Deploy to Elastic Beanstalk uses: einaregilsson/beanstalk-deploy@v20 with: aws_access_key: ${{ secrets.AWS_ACCESS_KEY_ID }} aws_secret_key: ${{ secrets.AWS_SECRET_ACCESS_KEY }} application_name: application_name environment_name: environment_name version_label: ${{ env.VERSION_LABEL_NAME }} region: ap-northeast-1 deployment_package: build/distributions/release.zip ＜略＞ 実行前に、デプロイする資源をビルドし Zip化 している。 その際、プロジェクトの build.gradle に定義したタスクを呼び出している。
11. Git 未経験者が GitHub Actions で CI/CD できるようになるまで Elastic Beanstalk へのデプロイ実装 ＜略：検証環境向けの .war ビルドを実行＞ - name: Build zip uses: gradle/gradle-build-action@v2.3.3 with: arguments: | buildZip - name: Deploy to Elastic Beanstalk uses: einaregilsson/beanstalk-deploy@v20 with: aws_access_key: ${{ secrets.AWS_ACCESS_KEY_ID }} aws_secret_key: ${{ secrets.AWS_SECRET_ACCESS_KEY }} application_name: application_name environment_name: environment_name version_label: ${{ env.VERSION_LABEL_NAME }} region: ap-northeast-1 deployment_package: build/distributions/release.zip ＜略＞ 先程の「beanstalk-deploy」を呼び出している。 また、AWS にアクセスするためのクレデンシャルは GitHub の「Settings > Secrets > Actions」で管理
12. Git 未経験者が GitHub Actions で CI/CD できるようになるまで 静的解析ツール・コードフォーマッターの適用 【結論】 • 静的解析ツール ： SpotBugs、　PMD • コードフォーマッター ： Spotless 【選んだ理由】 Gradle プラグインがサポートされているかどうかで選定 ひとまずのスモールスタートを行うため、代表的なツールを導入 【利用方法】 次ページにて簡単に紹介 【SpotBugs】 https://spotbugs.github.io/ 【PMD】 https://pmd.github.io/ 【Spotless】 https://github.com/diffplug/spotless
13. Git 未経験者が GitHub Actions で CI/CD できるようになるまで 静的解析・コードフォーマッターの適用 【静的解析】 ＜略＞ - name: PmdMain run: ./gradlew pmdMain - name: PmdTest run: ./gradlew pmdTest - name: SpotbugsMain run: ./gradlew spotbugsMain - name: SpotbugsTest run: ./gradlew spotbugsTest
14. Git 未経験者が GitHub Actions で CI/CD できるようになるまで 静的解析・コードフォーマッターの適用 【静的解析】 ＜略＞ - name: PmdMain run: ./gradlew pmdMain - name: PmdTest run: ./gradlew pmdTest - name: SpotbugsMain run: ./gradlew spotbugsMain - name: SpotbugsTest run: ./gradlew spotbugsTest build.gradle に定義した各ツールのタスクを Gradle Wrapper スクリプトで呼び出す。 ※各ツールの Gradle の設定については割愛。
15. Git 未経験者が GitHub Actions で CI/CD できるようになるまで 静的解析・コードフォーマッターの適用 【静的解析】 ＜略＞ - name: PmdMain run: ./gradlew pmdMain - name: PmdTest run: ./gradlew pmdTest - name: SpotbugsMain run: ./gradlew spotbugsMain - name: SpotbugsTest run: ./gradlew spotbugsTest 【参考情報】 PMD は GitHub Action に公式の Action があるので、手軽に利用することも可能 (各開発者端末でも同じルールセットでチェックさせたかったため、今回は使用していない) 【GitHub Action for PMD】 https://github.com/marketplace/actions/pmd
16. Git 未経験者が GitHub Actions で CI/CD できるようになるまで 静的解析・コードフォーマッターの適用 【コードフォーマッター】 ＜略＞ - name: Spotless Apply run: | ./gradlew spotlessApply - name: Check for modified files in Spotless id: git-check run: echo "MODIFIED_IN_SPOTLESS=$(if git diff-index --quiet HEAD --; then echo "false"; else echo "true"; fi)" >> $GITHUB_ENV - name: Push in Modified File with Spotless if: env.MODIFIED_IN_SPOTLESS == 'true' run: | git config user.name github-actions[bot] git config user.email 41898282+github-actions[bot]@users.noreply.github.com git status git add . git commit -m "Formatted Java source code." git push origin HEAD
17. Git 未経験者が GitHub Actions で CI/CD できるようになるまで 静的解析・コードフォーマッターの適用 【コードフォーマッター】 ＜略＞ - name: Spotless Apply run: | ./gradlew spotlessApply - name: Check for modified files in Spotless id: git-check run: echo "MODIFIED_IN_SPOTLESS=$(if git diff-index --quiet HEAD --; then echo "false"; else echo "true"; fi)" >> $GITHUB_ENV - name: Push in Modified File with Spotless if: env.MODIFIED_IN_SPOTLESS == 'true' run: | git config user.name github-actions[bot] git config user.email 41898282+github-actions[bot]@users.noreply.github.com git status git add . git commit -m "Formatted Java source code." git push origin HEAD build.gradle に定義した Spotless のタスクを呼び出す
18. Git 未経験者が GitHub Actions で CI/CD できるようになるまで 静的解析・コードフォーマッターの適用 【コードフォーマッター】 ＜略＞ - name: Spotless Apply run: | ./gradlew spotlessApply - name: Check for modified files in Spotless id: git-check run: echo "MODIFIED_IN_SPOTLESS=$(if git diff-index --quiet HEAD --; then echo "false"; else echo "true"; fi)" >> $GITHUB_ENV - name: Push in Modified File with Spotless if: env.MODIFIED_IN_SPOTLESS == 'true' run: | git config user.name github-actions[bot] git config user.email 41898282+github-actions[bot]@users.noreply.github.com git status git add . git commit -m "Formatted Java source code." git push origin HEAD Spotless を適用した結果をプッシュするため、 差分の有無を $GITHUB_ENV に変数 MODIFIED_IN_SPOTLESS を追加し設定する
19. Git 未経験者が GitHub Actions で CI/CD できるようになるまで 静的解析・コードフォーマッターの適用 【コードフォーマッター】 ＜略＞ - name: Spotless Apply run: | ./gradlew spotlessApply - name: Check for modified files in Spotless id: git-check run: echo "MODIFIED_IN_SPOTLESS=$(if git diff-index --quiet HEAD --; then echo "false"; else echo "true"; fi)" >> $GITHUB_ENV - name: Push in Modified File with Spotless if: env.MODIFIED_IN_SPOTLESS == 'true' run: | git config user.name github-actions[bot] git config user.email 41898282+github-actions[bot]@users.noreply.github.com git status git add . git commit -m "Formatted Java source code." git push origin HEAD 差分があれば、プッシュする プッシュ時は今回 GitHub Action でコミットしたように見せるため、 ユーザー情報を下記のように設定した
20. Git 未経験者が GitHub Actions で CI/CD できるようになるまで 効果 【デプロイ自動化】 • 週次でのデプロイ作業 ◦ 作業工数削減 週あたり 30分 〜 1時間 • 必要時の検証環境利用 ◦ 属人化解消 デザイナーメンバでも検証環境にデプロイが可能 【静的解析・コードフォーマッター】 • 静的解析結果の出力 ◦ 現状の課題や懸念点の創出 • コードの整形 ◦ 不要な import の削除 ◦ import の順番の統一化
21. Git 未経験者が GitHub Actions で CI/CD できるようになるまで 実施していく中での気付き・学び 大きくは以下の４点 • Git/GitHub の学習 • 実装・テストする上での注意 • レビュー時の観点 • 運用開始に向けて開発組織への周知
22. Git 未経験者が GitHub Actions で CI/CD できるようになるまで Git/GitHub の学習 【結論】 「習うより慣れろ」 【背景・理由】 • すべての機能を理解する必要はない ◦ 本当に必要なものは案外少ない • 開発からリリースまでの1サイクル で必要な機能を最低限押さえる ◦ 組織やプロダクト ごとに ブランチ戦略 や リリース手順 が違う ◦ 目的に立ち返ると「CI/CD の実現」 ◦ もし Git 未導入であれば ブランチ戦略の検討 から始める
23. Git 未経験者が GitHub Actions で CI/CD できるようになるまで 実装・テスト 【結論①】 本番環境 や 実開発作業に影響を与えないよう、 「ダミー の リポジトリ・ブランチ を作成」 する 【背景・理由】 • 開発への影響を与えず、自由に触れる環境が必要 ◦ 稼働中のワークフローが存在していた ◦ 意図せず動作した際のリスクを下げたかった ◦ 一方、いろんなパターンで挙動の確認は必要だった
24. Git 未経験者が GitHub Actions で CI/CD できるようになるまで 実装・テスト 【結論②】 月次の利用枠を枯渇しないよう、 「不要な JOB はコメントアウト」 して対応 【背景・理由】 • 上限に達し、開発で使用しているワークフローが実行できなくなった ◦ その際は必要な分を課金した 【参考】 課金は処理のトータル時間ではなく、ジョブ単位で切り上げられる →仮に 1ワークフロー で 1秒のジョブ を 50回 呼ぶ →ワークフローは1分以内に終了 →利用としては 1分 ではなく 50分 となる
25. Git 未経験者が GitHub Actions で CI/CD できるようになるまで レビュー 【結論】 最低限の観点として • セキュリティ上の問題の有無 • クレデンシャル情報はどのように保持しているか など • 使用した Action の妥当性 • Action が活きているか（定期的にバージョンアップの有無） • 適切なバージョンを指定しているか など 【背景・理由】 • 事故につながらない状態であれば良しとする • 時間の経過とともにゴールが変わることもあるので BEST を追い求めない ◦ 誰にとっても保守しやすいかどうかのほうが重要
26. Git 未経験者が GitHub Actions で CI/CD できるようになるまで 運用開始に向けて開発組織への周知 【結論】 • 「細かく」「事前に」「何度も」を心がける • 各メンバーの作業や業務がどう変わるかを意識する 【背景・理由】 • 大前提として 開発体験の劣化 は避ける ◦ 適用前に実環境でテストを行うため利用調整があった ◦ 適用後の運用がどう変わるかまで考える必要がある
27. Git 未経験者が GitHub Actions で CI/CD できるようになるまで まとめ • GitやGitHubの習熟は習うより慣れろ ◦ チームで必要な最低限必要な機能は限られている（はず） • ブランチ戦略とその運用が重要 ◦ トリガーの条件の決定に必要となる ◦ チームへの適用時の影響範囲確認が容易になる • 挙動の確認はダミー(ブランチ・リポジトリ)を作って実施 ◦ 本番への影響を避けるため、ダミーで壁打ち ▪ 壁打ちする際は、利用枠の枯渇に注意 • 稼働開始に際してはメンバとの緊密なコミュニケーションが必要 ◦ あくまでもチームの開発体験向上が目的 ◦ 無理に開始してコケると、次の一手が出しづらくなる
28. Git 未経験者が GitHub Actions で CI/CD できるようになるまで おしまい 28