こんにちは！TECH Street編集部です！
今回は2020年1月26日（火）に開催した、【BASE BANK／はてな／POST URBAN／パーソルキャリア】CI/CD活用事例＆TIPS発表会のイベントレポートお届けいたします！
各社のCI/CDってどうなってるの？というメンバーの興味関心から企画した今回のイベント。CI/CD関する知識や経験・気付きなどを事業会社のエンジニアが集まり発表し学びあう場となりました◎
今回の登壇者はこちらの皆様♪
・吉次 洋毅 さん／パーソルキャリア株式会社
・小林 佳史 さん／パーソルキャリア株式会社
・永野 峻輔 さん／BASE BANK株式会社
・難波 啓司 さん／株式会社 POST URBAN
・papix さん／株式会社はてな
（※登壇順に記載）
それでは早速ご紹介していきます。
「Pull RequestとGitHub Actionsのworkflow_dispatchを活用した承認・リリースフロー」（吉次 洋毅／パーソルキャリア株式会社）
現在、パーソルキャリアの2019年に新設された部署で「Salaries（サラリーズ）」というプロダクトの開発を担当している吉次さん。
吉次さんの所属部署は、新設部署ということもあり本番リリースの運用に関する要件についても、手探り状態から始まったのだとか。そのような環境の中で、本番リリースの際の承認やリリース・切り戻しにおける課題が見えてきたそうです。
吉次さんからは、これからCI/CDの構築・見直しをしようとしている人が、GitHub Actions workflow_dispatchの使い方を知り、各プロジェクトでの承認・リリースフローの構築に活用できるようなTIPSをご紹介いただきました！
GitHub Actions workflow_dispatch
2020年6月にGitHub Actionsにおいて、ワークフローを手動で実行するためのトリガは発表されました。
これまで、GitLab CIをよく使っていたという吉次さん。GitLab CIにおいてはmanualを指定すると手動に切り替わるのだとか。GitHubでもこれがしたい！ということでワークフローを活用したそうです。
ワークフローは下記のようなトリガとなっています。
※ワークフローファイルがデフォルトブランチにマージされていないと、「Run workflow」のボタンが出てこないので、ご注意ください！
続きまして、トリガの設定は下記の通り。
workflowのトリガ部分でworkflow_dispatchを指定します。例えばタグ等の、任意の入力値を定義することも可能です。
例として、今回は下記のようなかたちで設定しているのだとか。
また、Pull Requestを活用した承認をすることで、だれが承認したかのログが残すことができ、当初想定していた承認フローの課題をクリアすることもできたとのこと。
そして、リリースノート・タグを作成し、リリースを実行します。
通知と切り戻し
現在吉次さんが担当されているプロジェクトにおいては、Slackに誰がどのリポジトリのどのバージョンをデプロイしたのかが通知されるようになっているそうです！
GitHub Actionsにおいては、現状トリガの制御がリポジトリの権限に基づいているため、チームメンバーが誰でもできてしまう状況なのだとか。そのため、何か異常があったときもあとから気づけるように、Slackに通知がされるようにしているとのこと。
その他には、スマートではないものの、「実行権限を持つ人だけが知っている認証用コード」を使って制御するという対応方法もあるそうです。
まとめ
吉次さんからは、まとめとして下記の3つのポイントをあげていただきました。
・手動トリガを活用してリリースと切り戻しをよりシンプルにしよう
・Pull Requestを承認に活用し、承認フローにおける人為的ミスを減らそう
・Slack通知を活用してより機敏に動けるようにしよう
吉次さんからは、非常に具体的に操作方法から課題の解決方法までシェアしていただきました◎是非、皆様もご活用ください！
参加者からの質問
（Q1）GitHub Actionsは触れたことがないのですが、強いて言うならここを改善してほしいとか、やりにくいとかあったりしますか？
（A）workflow_dispatchが出てくる以前は困っていましたが、現状特に使いにくいような点はないかなと思います。（他のCI/CDサービスに並んだかなという感覚です）。workflow_dispatchに関しては、デフォルトブランチへのマージが必要なので最初に試したりするときは割り切ってマージしたり、一時的に別のデフォルトブランチにするなどの対応が必要なのが若干煩わしい部分かも知れません。
（Q2）吉次さんのチームは何名くらいの体制ですか？
（A）適宜プロジェクトを移動したり、兼任したりがあったりしますが、大体5〜6名の体制でやっています。
（Q3）社内の開発環境がオンプレミスに依存している場合、Githubに代わるCI/CDツールについて推奨するものはありますか？
（A）推奨と言えるほどいろいろ試してはいないのですが、過去に似たような環境でやっていたときは、コード管理を含め、GitLabをオンプレ内でセルフホストしてビルトインのGitLab CIを使っていました。（吉次さん回答）
（A）CI/CDのみであれば弊社での採用事例はありませんが、個人で利用したことがあるものだとDrone IOなどがオススメです。（小林さん回答）
「KubernetesとCI/CDの活用について」（小林 佳史／パーソルキャリア株式会社）
続きまして、Vtuber姿での登壇！めっちゃかわいい！！w
所属部署全体のインフラ・セキュリティに対するアドバイス及び業務環境改善を担当されている小林さんに、Kubernetesを中心にご共有いただきます◎
これまで、パーソルキャリアが運営する「CAREER POCKET（キャリアポケット）」というサービスにおいて、サイボウズのKintoneを使用していたのだとか。
しかしながら、セキュリティ等の社内規定により、使用継続が難しくなり、その代替として別のデータベースを使用することに。今回代替として使うデータベースのプロジェクト名はCandicom（Candidate+Communication=Candicom）。
Candicomの利用イメージ
Candicomは、「CAREER POCKET」内の、「転職トーク」というサービスにおいて使用されています。転職希望者のサポートを行うキャリアアドバイザーが利用記録をCandicomの中に登録して管理しているのだそう。
機能としては、簡易的なフィルタを使用したリストや、非エンジニアの方が使えるようなCSVのインポート・エクスポート機能など。
Kubernetesの活用
Kubernetes（k8s）とは、Googleが設計したコンテナオーケストレーションシステム。コンテナをクラスタ内で横断してデプロイ、スケーリングするためのプラットフォームです。
こちらを活用して良かった点としては、下記などが挙げられるとか。
・特定のコンポーネントのみ更新の場合、影響範囲が限られる
・スケーリング、オートヒーリング、ロギング、メトリクス取得の恩恵がKubernetesによって得られる（主にマネージドなKubernetesの場合）
一方で、辛かった点も。
・Kubernetes単体での運用ははっきりいって辛い
・特にステートを持つリソース（データベース・キャッシュなど）をクラスタに混ぜると厄介にな存在になる
他にも、下記のような検討事項あったようです。
最新のイメージを常に使いたい、という問題についてはCI/CD上にSkaffold（※）を組み込んで使用することで解決できたのだとか。
※Skaffoldとは
Googleで作られたKubernetesへのデプロイを便利にするツールで、kubectl, Kustomize, helmなどを実行してくれます。
環境ごとに値を切り替えたい、という課題に関しては、上記図、左側にファイルのツリーが出ていますが基本的にベースディレクトリに全ての設定を記述し、オーバーレイディレクトリのなかに、起動したいコンテナの数等の上書きをしたい設定を書いておきます。
また、パスワード等の秘匿情報を持ちたい、という課題については標準機能ではクラスタへの管理権限があると誰でもデータにアクセスが出来る等のリスクがあるため、セキュアコース（データの暗号化/復号化などもできる）で対応したそうです。
ただし、クラスタのなかに侵入されると、いくらIAMを絞っていても難しい部分があるのだとか。これに関しては、RBACの使用で多少カバーできる部分もあるそうなのですが、RBAC自体の導入もハードルが低くはなく、導入には二の足を踏んでいるような状況なのだそうです…！
プログラム側もメモリに認証情報などを持つことになるので、リードオンリーコンテナにしつつ、シェルアクセスをはく奪するなどして秘匿情報を管理したほうがよさそうとのこと。
今後について
開発当時の課題点である、コンテナの軽量化は改善できているようですが、今後の課題点としては、リードオンリーコンテナにするなどして、コンテナ自体をもっとセキュアにしていくことが必要なのでは、と考えているそうです。このあたりは、担当の方が少しずつメンテナンスしているそうなので、今後に期待とのこと！
小林さんからも非常に具体的なお話、ありがとうございました◎
参加者からの質問
（Q1）パーソルさんはGitHub Actions推し？比較検討対象とかは他にあったのでしょうか。
（A）弊社のセキュリティポリシー上、新規に使用するWebサービスは審査が必要なため、既に利用しているGitHubに組み込まれているGitHub Actionsを利用する方が、拘束されずに高速に開発出来ると考えたためです。
（Q2）Skaffoldを採用された経緯はありますか？
（A）Kustomizeを利用していましたが、不満を感じ色々探していたところSkaffoldを見つけ、求めていることが出来ることから使用を始めました。
（Q3）docker-composeではなくk8sを利用した理由を教えてください。
（A）Linuxインスタンスのメンテナンスを避けたいというのがk8s(GKE)を採用した理由です。
（Q4）Kubernetes はデータベースやキャッシュをもたせるとつらいという話がありましたが、これはコンテナの安定性の問題ですか？データベースやキャッシュ等のデータを保持しないシステムではコンテナが不安定になってもautohealやautoscale等で対応が可能という意味ですか？
（A）概ねそうです。ステートを持つPodだとスケールやAutohealで結構考慮することが多かったりするので、極力パブリッククラウドで提供されている他のリソースにステートを持たせた方が良いと感じました。
「Code Build・ECSを使ったAWS構成のDocker環境CI/CD」（難波 啓司／株式会社 POST URBAN）
POST URBAN社で開発している「ONLY FIVE」について
主にアイドルや、モデル、タレントの方が写真を投稿。それを購入した方に、上記右図のような手書きのメッセージなどのオリジナルメッセージ付きの写真が返ってくるようなサービスです。一番の特徴としては、名前の通り、「先着5名」だけが購入券を買うことが出来る、というような仕組みなのだそうです。
先着順がゆえに、購入権を手にするのは非常に狭き門。ものすごい競争率で、5名の枠を取り合うのだとか…！1000名近くのファンの方が同時にブラウザをリロードしまくり待機するような状況になるので、アクセス集中必至。運用が難しいサービスであると、難波さんは語ります。
この「ONLY FIVE」のインフラは基本的にすべてAWSで運用しており、CI/CDを含めてAWSでそれぞれラッピングしているそうです。今回は、この運用についてお話しいただきました！
DockerのCI/CD
全体図は下記の通り。基本的にはコードパイプラインを中心に動いていくような形になります。コードパイプラインには、ソースフェーズ、ビルドフェーズ、デプロイフェーズ3つのフェーズがあります。
ソースフェーズはGitHub integrationと連携しており、GitHub上の任意のブランチに新しいプッシュもしくはマージがされた際に、イベントのトリガーとしてこのパイプラインが走るような駆動をするというような役割を持っているそうです。
ソースフェーズで新しいイベントをトリガした際に、次のビルドフェーズにその新しいコードを投げます。ビルドフェーズではコードパイプラインとは別の、AWS CodeBuildというAWS上のサービスが動くような形となります。
最後にECSですが、もともとパイプラインは最後のデプロイフェーズでECSを直接指定することが出来なかったそうなのですが、最近ECSを指定することが出来るようになったそう。直接最後のデプロイフェーズとしてECSを指定することでAWS CodeBuildフェーズでECRにプッシュしたイメージを使うような形でタスク定義をアップデートし、ECSのクラスタサービスに新しいタスク定義を使うように変更をかけるということを自動で行われるようにするそうです。
コードパイプラインの構造については以下の通り。
ソースフェーズではGitHubの任意のコミットIDを参照するような形となっており、ビルドフェーズでは、AWS CodeBuildが走っています。そしてデプロイフェーズではECSが走っているような形となっています。
ちなみに、コードパイプラインはこの各フェーズごとに複数のアクションを作ることもできるので、一つのソースのトリガに対して二つのビルドを走らせる、といったような運用も可能なのだとか◎
ちなみに、このビルドフェーズにおいてCircleCIなどを用いることもできるそうですが、このビルドをつかうことで基本的にはIAMで一元的な権限管理が出来るのでお得なのだとか…！
AWS CodeBuildは、プロジェクトのルートのところに、buildspec.ymlのファイルをおいておくと、それの通りにビルドを実行してくれるそうです。基本的には、プレビルド、ビルド、ポストビルドの3つのフェーズを置くことが出来ます。やっていることはとてもシンプルで、下記形なのだとか。
①プレビューなどのフェーズでAWSのCLIにログインをして変数などをセットアップ
②ビルドフェーズでDockerのイメージを実際にビルドしテストを実行
③ポストビルドフェーズでECRのレポジトリにプッシュ
最後にデプロイフェーズのECSについて。基本的な構造は以下の通り。下記図は一例ですが、実際にはここに4つくらいのコンテナが動いているような状態だそうです。
ECSのタスク定義のコンソール上での表示は以下の通り。コードベース上のポストップのビルドフェーズでプッシュされた新しいイメージを参照するような形で、新しいタスク定義が作られます。
このタスク定義を使う形でアップデートが入り、各コンテナにデプロイが実行されていきます。この実行については、プレースメントポリシーというものを設定することができて、より詳細に設定することが可能です。
DevOpsという考え方とCI/CDの必要性
一番の目的は、とにかく早いサイクルでリリースをすること。サイクルを早めるにはこれまで手動でテストしていたり、ローカルでしていたようなテストを自動化し、一定の品質を担保できるような仕組みが必要であり、CI/CDによってそれを実現できるのが大きなメリットです。
一言でまとめると、CI/CDの導入は「今後の“時間”に投資する」ことに繋がるのだとか。
単純にレビュアーの時間が減るから楽、というだけではなく、CI/CDの導入による時間の投資は、潜在的なビジネスリスクの回避やビジネスチャンスの獲得まで含めた意味があると難波さんは語ります。より早く、市場にフィットするプロダクトをリリースしていくことができる体制を作るためにも、時間を創出するためにも。CI/CDについて改めて考えてみる必要があるのだとか◎
スピード感と安定感を担保した開発を行っていくうえで、CI/CDは重要な鍵になりそうですね…！難波さん、ご共有有難うございます！
参加者からの質問
（Q1）POST URBANさんCI/CDのハードルの高さ、社内に飲み込んでもらうには？
（A）チームの認識を合わせる際には、一緒に勉強会を開いて導入部分だけ触ってみたり、外部の技術顧問に相談するのが良いと思います。導入されているチームとそうでないチームで割と中長期で差が出てくると思うので、ちゃんと将来投資してく必要はあると思います。
（Q2）Code BuildベースのシステムをJenkinsベースと比較したときのPros/Consを差し支えない範囲で教えてください。
（A）IAMによる権限の一元管理とセットアップ・その他の導入のハードルの低さはCode Buildがかなり優秀かなとは感じました。基本的にフルマネージドでスケーリングもしてくれるので、ボトルネックを感じることはあまりなくなります。Consとしては、細かなインスタンスタイプの選択がまだできなかったり、OSがAmazon Linux2とUbuntuしか選べないのがPJTによっては使えない可能性もあります。
（Q3）Code BuildはAWS専用？OSS？
（A）Code BuildはAWS専用のサービスです。他のリソースをAWSで運用してる場合に導入を考えるという認識で良いと思います。
（Q4）ECSに対するCI/CDパイプラインを構築するにあたって、Fargateでも同様にパイプラインを構築することはできるのでしょうか？
（A）Fargateでも特に大きく差異なく同様に作ることが可能です。是非お試しください。
（Q5）CI/CDパイプラインは構築するまでが大変ということでしたが、そのコストを上層部に説明するときにリターンとして強調したほうがいいものにどんなことがありますか？
（A）具体的に「リリース頻度をn倍にする」「レビュー工数を1/nにする」などの目標を掲げることが大切だと思います。
その上で、同様のことを実現できた競合サービスなどがあった場合に中長期で大きな差になってくることも含めて説明しましょう。
「CI/CDで始まるチーム文化作り」（永野 峻輔／BASE BANK株式会社）
CI/CDの自動化を行うことの重要性
改めて、CI/CDの定義から。CI/CDはテストの実行や静的解析を繰り返し行うため、煩雑なフローを自動化し、迅速なデプロイ、迅速な価値提供を行うための仕組み。これらを実現する代表的なツールとしては、CircleCI、GitHub Actionsなどが有名です。BASE BANKさんにおいては、CircleCIやGutHub Actions、AWS CodeBuildなどを併用しているそうです。
CI/CDがある開発システムは、まず、Pull Requestのコードを修正、CIから失敗通知を受け取り、また開発する、といった繰り返しを行います。最後に、マスターブランチ、もしくはメインブランチにマージしてデプロイする、といったプロセスがCI/CDがある一般的な開発サイクルといえます。
では、なぜ、CI/CDが大事なのでしょうか。CI/CDの自動化が機能していない世界を考えてみましょう。
先ほどCI/CDが担っていた役割を「先輩」としておいてみるとします。行動をプッシュして、そこから先輩がコードプレイをし、そのあとにレビューをする、というようなイメージ。最終的に問題がないと判断されたら、先輩の判断でまたでデプロイが暗黙的に行われる、というような世界観です。
このような組織構造だと、他責的になりがちだと、永野さんは語ります。
リリースがよくわからない状態なので、本当にこれで動くのかというイメージが分かりづらかったり、指摘をもらったら直す、という体制になると自責的にコード修正をしなかったり。
一方で、CI/CDが機能しているときは、自分がマージして自分がデプロイすることになるので、責任をもって自分で決断する必要があります。アラートが鳴った際も、自分で急いで対応しようという意識が生まれますし、「あえて今回はそうする」「時間の都合上リリースを早くする」などといった判断も自分で決めることができるようになります。
基本的には自動テストも動いているという前提のもとなので、最低限の動作保証が出来て、新人さんにとっても、優しい世界になるのだとか…！
【CI/CDの重要性まとめ】
・自動テストで最低限の動作保証が出来るので新人にも優しい。但し自動テスト≠品質なので注意が必要
・yamlファイルでワークフローを作ることになり、リリースフローが形式知となるので他サービスへ横展開しやすい
・lintなどによって規約が作られるので自分たちの抱えているリスクをコントロールできる
・開発のリズムが作られ、見積の精度が上がる
【CI/CDの自動化で気をつけるべきポイント】
・自動テストをメンテナンスし続ける必要性
・初期導入コスト（CDにともなう認証周りは要検討）
CI/CDはあくまで手段であり目的ではないという意識が必要なのですね…！
自動化することがゴールになってしまい、その後のメンテナンスがおろそかになってしまっては意味がありません…！月一回、年一回のリリースであれば、自動化しないというのも選択肢にはなるそうです。
CI/CDの基本の柱
・品質チェックを生産工程に組み込む
・作業を小さく分割する
・反復作業はコンピューターに任せる
・改善努力を徹底的にする
・全員が責任を負う
（継続的デリバリーについての基本原則 LeanとDevOps 4章より抜粋）
ここからは、実際にBASE BANKさんで取り組まれていることについて。
機械的なコードチェックも仕組化することで、本当にレビュー議論をしたいことに専念することが出来るようになったり、
自分たちがどのようなリスクを抱えているのかということが分かるような仕組みでセキュリティ意識も向上します。
また、絵文字付きでSlackにリリースを通知することで、リリースと仲良くなれるのも◎逆に失敗したときも、Slackでカジュアルにスタンプで共有。メンバーそれぞれが一定の責任のもとで、自由に業務に取り組むことが出来る環境となっているそうです。
またTrivyを使った日時コンテナの脆弱性チェックなど、定期的にセキュリティチェックも実施しており、インシデント通知があるとSlackに上がるような仕組みとしているそうです。
さて、CI/CDの導入については、「GitHub Actions」から始めることがおススメとのこと。（他のCIサービスはアカウント認証の必要があるなど少し最初は手間がかかるので、GitHub Actionsが良いらしいです…！）
・特定のディレクトリにyamlを書けばよい
・言語別などの公式テンプレートもある
・まずはlintからがおススメ（最初はignoreして少しずつ始めてみよう）
・awesome-actionsを眺めていると楽しい！
まとめ
・CI/CDの自動化は大事：リリースフローの形式知化と最低限の動作保証を
・CI/CDから文化が生まれる：全員が責任をもって継続的に改善をする
・GitHub Actionsで明日から始めてみよう
CI/CDが担う役割を先輩とおいてみる、すごくわかりやすい例えでしたね....！他責的にならない、これは組織文化としてめちゃくちゃ大事だなと思いました。
参加者からの質問
（Q1）Terraformとか強権のCI/CDとかでAWS CodeBuildつかってるのでしょうか？
（A）TerraformのみCodeBuildを使っています！
（Q2）CI/CDのメンテについて 誰がどのタイミングで行うといった割り振りはされているのでしょうか？
（A）必要と思ったときに必要と思った人がやったり、朝会で出来る人を探したり、メンバー同士でナレッジを共有したり、属人化しないようにしています。
「はてなでのGitHub Actions活用事例」（papix／株式会社はてな）
株式会社はてなでWebアプリケーションエンジニアをされているpapixさんからは、はてなにおけるGitHub Actionsの活用事例をご共有いただきました。
従来のCI環境は、EC2上に構築したJenkinsを使用していましたが、開発に気を取られてしまい、どうしても保守管理が後回しにされがちだったのだとか。また、歴史的経緯によって同時にテストが実行出来ないこともあったそうです。
はてなでは、 GitHub.comを活用していたので、GitHub Actionsが登場した際にこれまで最大のネックだったテストのGitHub Actions化に取り組むこととなったそう。
ワークフローの構築
GitHub Actions化の肝はワークフローの構築です。
開発環境のDocker化が完了していれば、難しくはないはず...！イメージをビルドして、Dockerでテストを実行します。そのなかで、テストの時間をなるべく短くする、コストの試算、Jenkinsからの置き換えなどを考えながら進めていきます。
Dockerのイメージは都度ビルドせず、開発環境のDocker ImageをECRに登録し、テストするごとに都度pullする、という作戦がつかえるのだとか！
そもそも、テストそのものにも時間がかかります。アプリケーションの規模にもよりますが 、普通にテストを回すと1時間経過しても終わらないことも…！そこで、self-hosted runnerを使う、AWS CodeBuildを使うという作戦を考えたそうです！
self-hosted runnerは自分が作った環境でGitHub Actionsの処理を実行出来る仕組みで、必要な環境を構築してGitHubに登録すると利用することが出来ます。しかし、例えばself-hosted runnerの動作環境としてEC2を使う場合、処理をしていなくても起動し続ける必要がありコストがかかってしまうことや、self-hosted runner1台につき1つの処理しかできないというデメリットもあり、断念。
次に、AWS CodeBuildですが、vCPU32, メモリ144GBの環境があり、self-hosted runnerと異なり、都度実行・都度課金の形態なのだとか。ただ、「GitHub ActionsからAWS CodeBuildを起動」するのであれば「JenkinsからAWS CodeBuildを起動」、むしろ「AWS COdePipelineで良いのでは…？と思い断念…。
第三の選択肢としてでてきたのが「テストを分割実行する」というやりかたなのだとか。つまりどういうことかというと…
テストを16分割したそうです…！
GitHub Actionsには「ビルドマトリックス」という概念があります。こちらは本来はPerlの5.32系、5.30系、5.28系…のように複数の環境で同時にテストを実行するためのものだそうですが、これをつかってテストを16分割して実行してみたのだとか。コストは当然16倍となりますが、その分素早く終わるので十分にペイできたそうです！
まずは、ビルドマトリックスとして連番を指定、連番の数だけテス
トを分割して実行します。（例えば1から16までの連番なら、16分割。）その後、findを使ってテスト対象の一覧を取得し、splitで分割、実行の順に進めます。テストを分割する結果は冪等である必要がありますのでご注意を！
実際のワークフローの様子はこちら。
更なるテクニックとしては、下準備を行うprepareというジョブを別途用意したそうです。16分割したテストのそれぞれでライブラリのインストールなどの下準備を実行すると非効率なため、テストを実行するにあたって必要な処理はprepareジョブに押し込みます。また、テストはprepareフェーズ後に実行するようにします。あるジョブと別のジョブは別の環境で処理が実行されるため、prepareジョブで用意したファイルは、他のジョブでそのまま使えなく、prepareジョブでキャッシュして、それを利用する必要があるそうです。
また、キャッシュ周りに関しては、GitHubが公式で提供するキャッシュ機能（action/cache）という機能があるそうですが、16分割して同時にキャッシュを取得しようとしているためか、時折キャッシュの取得に失敗することも…！更に、その場合「16分割したうちの失敗した1つ」を実行することは不可能なため、16分割全て再実行が必要になるのだとか…
そのため、キャッシュの取得の失敗を防ぐために、S3を使ってキャッシュを実現するpapix/action-cache-s3の仕組みを作り、キャッシュ取得に失敗することが減ったそうです！
こうして、ブログのテストはpushしてから7-10分で終了するようになったのだとか！（凄いスピードアップですね◎）しかも、GitHub Actionsのジョブはスケールするので、複数のpushがあっても常に同時に走ってくれるそう！
ほぼメンテナンスフリーで開発が出来る環境となり、環境が大幅に向上。Jenkins時代と比較すると、試算ではコストも約2/3になったのだとか！一方で、ワークフローのデバッグが難しいというデメリットもあったそうです。Jenkinsのように実際にサーバーに入って挙動を見るということが難しく、GitHub Actionsのログから調査をする必要があるのだとか。
メリットもあればデメリットもある、その繰り返しで改善が進んでいくのですね…！非常に参考になる事例の共有ですね◎
最後は、GitHub Actionsのおもしろテクとして、LinterやFormatterとreviewdogを組み合わせてコードに警告をする、misspellとreviewdogを組み合わせてミススペルを指摘したり、Pull Requestのラベルのチェックをすることも実現できると教えていただきました♪
papixさんからは、はてなにおけるGitHub Actionsの導入事例をメリット・デメリットの側面からも詳細にご共有いただきました！GitHub Actionsの様々なactionを使用することでコスト削減や効率化を実現することも可能とのこと◎
まとめ
今回のイベントでは、各社のCI/CD導入における課題や取り組み、解決策まで非常に具体的にシェアしていただきました！エンジニアの皆様にも参考になるお話が沢山あったのではないでしょうか◎
参加者の声
・発表者の方が全員丁寧に質問に回答されていたのでとても好印象でした。
・Kubernetes、GitHub、CI/CDについてあまり勉強していなかったので参考になった。 kubernetesについてはpro/conについてよく考えて使わなければいなければいけないという話も参考になった。
・登壇者の所属企業もいろいろで、様々なクラウドサービスの事例が含まれて、参考になりそうな部分がいっぱいあった。
登壇者と運営の集合写真
最後に、今回ご登壇いただきました皆様、ご参加くださった皆様ありがとうございました！今回のイベントレポートは以上になります♪次回もお楽しみに！
