天の月

ソフトウェア開発をしていく上での悩み, 考えたこと, 学びを書いてきます(たまに関係ない雑記も)

GitHub CI/CD実践ガイド~ Forkwell Library#67に参加してきた

forkwell.connpass.com

こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。

会の概要

以下、イベントページから引用です。

第67回目では『GitHub CI/CD実践ガイド ――持続可能なソフトウェア開発を支えるGitHub Actionsの設計と運用』を取り上げます。
GitHub Actionsの基本構文から，テスト・静的解析・リリース・コンテナデプロイなどを実際に自動化する方法をハンズオンで学べるこの本。あわせてDependabot・OpenID Connect・継続的なセキュリティ改善・GitHub Appsのような，実運用に欠かせないプラクティスも多数習得できる一冊です。これまでもアンケートでリクエストの多かった本書を今回イベントとして取り扱いします。

会の様子

講演

CI/CDとは？

ソフトウェア開発はソフトウェアを通してユーザーに価値を届けることが目的であり、試行錯誤を繰り返す必要があるため、そこに役立つのがCI/CDだと考えているということでした。

そのうえで、CIはコードの変更を頻繁にコードベースに統合して正しく動作するか繰り返し検証する行為であり、CDはいつでも安全にリリースできる状態を保ちソフトウェアを繰り返し改善する行為であるという定義の説明があり、現場だとCIはCDに包含されることも多いという話がありました。

GItHub ActionsをCI/CDで実践する理由

GItHub ActionsはCI/CDを実践する上で、YAMLをリポジトリに追加すればすぐ動く手軽さが魅力的だという話がありました。
また、YAMLをキャッチアップさえすれば大体書くことができるしPublic Repository上であれば無料で実験がし放題なため、学習コストとしても低いと考えているということでした。
ただし、見様見真似で書きやすく動いたことがゴールになってしまうことも多いため、場当たり的かつ雑に扱われるのは課題だと思っているということです。

書籍の構成

まず一部で使い方を重点的かつ体系的に学習することを目的としているそうで、その上で第二部ではリリースに関する話題や長期運用で重要になってくる話を取り上げているということでした。

最後の第三部は玄人向けに、セキュリティや持続可能性に関する話を取り上げているということです。

GitHub Actionsのコンテキスト

時間の関係もあってコンテキストだけ具体的な機能としての紹介がありました。

データへのアクセスに利用するため利用頻度が高いそうですが、公式ドキュメントも含めてシェルコマンドに直接コンテキストを埋め込んでしまうアンチパターンをよく見かけるそうで、スクリプトインジェクションの脆弱性が発生しがちだという話がありました。

外部から入ってくるユーザー入力値は信頼してはいけないというソフトウェアの原則を考えると、コンテキストはいろいろなプロパティ(ブランチ名やラベル...)を含むため、コードレビューでもほぼ確実に見落とされてしまうということです。

そのため、中間環境変数を使用することが望ましいということで、環境変数を必ずクォートしてほしいという話がありました。

他のグッドプラクティスやアンチパターン

コンテキスト以外にも、グッドプラクティスやアンチパターンは存在するということで、グッドプラクティスの例としては

  • タイムアウトの明示的指定
  • パイプエラーが拾えるようにデフォルトシェルを記載
  • Concurrencyでワークフローを自動キャンセル
  • ログをグループ化してログの読みやすさを向上

が挙げられていました。また、アンチパターンの例としては、

が挙がっていました。
基本機能に関しては、使うのは簡単ですがうまく使うのには時間がかかるため、少し時間をつけて応用力を身につけるための基礎力を本書で身につけてほしいということでした。

持続可能性を高める習慣

ソフトウェアの想定稼働期間中に依存関係・技術・製品要件における変化に反応できるために、依存関係のバージョンアップを習慣とする必要があるということでした。

依存関係のバージョンアップは面倒*1な仕事になるため、Dependabotを利用するのがおすすめだという話がありました。

他にも、クレデンシャルをソースコードへ平文で保存しないようにしたりレビューやCIを必須にしたりリリースで適切なバージョニングやアナウンスを実施したりすることも重要な習慣だということですが、率直に言ってしまえば面倒くさい話なことがおおいため、なるべく既存ソリューションを使うことを大切にしてほしいということです。

意図的脅威に対する防衛

GitHub Actionsはソフトウェアサプライチェーンの中心的存在ではあるものの、攻撃される件数は増加傾向にあり、意図的脅威として第三者が実装したアクションの話が説明としてありました。

具体的な事例としてはCodecovの侵害によってクレデンシャルが流出してしまったりした話があり、アクション提供者を信頼するかは常に意識的に決断しないといけないということです。

とはいえ開発効率の観点を考えるとアクションを一切使わないことは難しいので、0にはできないもののVerified Creatorsを信頼性の目安にするなどといったリスク低減策が重要だという話がありました。

執筆中に心がけたこと

経験をとおして学ぶコトの言語化に注力したのと、最高の読書体験が提供できるようにめちゃくちゃチューニングをしたという話がありました。

Q&A

講演の後はQ&Aがありました。以下、質問と回答を一問一答形式かつ常体で記載していきます。

GitHub Actionsの実行時間を短縮するための工夫は？

キャッシュを使う、Larger Runner、テストの並列実行、ジョブの分割...があるということでした。

Webアプリかつデプロイ先がクラウドの場合、CI/CDはクラウドの仕組みを使うのかGitHub Actionsどちらを使うべきか？

デプロイ部分はセンシティブなのでクラウドに寄せたりするほうがいいという考え方もあるが、楽さはGitHub Actions。カナリアデプロイみたいな小難しいデプロイをするときにはクラウドの方が早い。

セルフホステッドランナーはどのサービスを使うのがおすすめか？

EC2よりマネージドなECSのほうが楽ではあると思う。ネットワーク制限がないならLarger Runnerを使うとよりよいとは思う。

terraform applyをGitHub Actionsで自動化するとき、.tfstateはどのように管理するのか？

オブジェクトストレージを使うのがいいと思う。AWSならS3とか。

なお、SaaSをカジュアルに入れるのが難しい会社にいたことが多いので、terraform applyを実行するサービスを使わずにGitHub Actionsで実装しちゃうことが多い。

スキルをどのように身につけてきたか？

アプリケーション開発→EM→SREとキャリアチェンジをしてきた。チームを変えながらスペシャリティを磨いてきた。

執筆依頼はどういう経緯でくるのか？

雑誌寄稿の縁。そこから2年かけて完成した。

複合アクションや再利用ワークフローは一つずつリポジトリを作成するべきか？一つのリポジトリでファイルやディレクトリで分けるべきか？

アクションについては一個のリポジトリで分けて作成することが多い。Public Repositoryの公開基準にそろえている。
再利用ワークフローは一つのリポジトリに入れちゃうことが多い。再利用ワークフローは一部の人に使ってもらうようなユースケースが多いので、利用者のことを考えて分けないようにしている。

CI/CDはなぜ浸透していないのか？(IPAの報告によるもの)

普通に利益は出ていて機会がないとかはあるのかもしれない。あとはベテランの人たちが慣れ親しんでいるツールを使いたがるとかはあるかもしれない。
他にも同じ人が同じ現場をずっと見ているとか。

CI/CDを使うためにどう説得するのか？コスト的なメリットとか

開発が楽になっちゃうのであんまり許可を取ることなく始めることが多いのだが、ミニマムにスタートするとかはあるかもしれない。

会全体を通した感想

信頼できる知り合いの方がおすすめしていた本だったのでまだ読んでいない中でも参加してみたのですが、豊富な経験と幅広い範囲の領域を勉強してきていることがよく分かる内容で、ぜひ読んでみようと思いました。

特にグッドプラクティス周りは知っている知らないで大きく差が出るところなので重点的にチェックしてみようと思います。

*1:検知・把握・実装・テストをすべてするのが大変