少人数チームでのGitOpsでの開発・運用

オンラインセミナー登壇

終わってから報告をするのもアレですが、先週、日頃からお世話になっているトレジャーデータ様のオンラインセミナーがあり、朝日放送グループとしてのデータ活用、という文脈でお話をする機会をいただきました。

Untitled

その中で、私は技術的な観点から、どのように組織を回していくべきか？ということに触れました。内容としては、かなり汎用的なものになっているかと思いますので、改めてその内容についてまとめてみようと思います。

少人数チームとサービス・システム運用

セミナーではCDP(Customer Data Platform: 顧客データ基盤)についての話として話を進めましたが、実際、どのようなサービス開発だとしても、 非IT企業には少人数での実施がつきものです。

もちろん理想的には人数を増やすことが一番だと思いますが、そんな権限を持たざる者からすれば、 声は上げられたとしても突然人が増えるなんてことはまずありません。

なので、継続的に声を上げ続けるとしても( ←これはこれで大事 )、それとは別に、 少人数でも回るような仕組み作りを考える必要があります。

20230310_TD対談

上の画像は発表でも使用したスライドそのものですが、このような少人数でグループ全体に亘るシステムを運用しようと思うと、スライドにもあるように

属人化 の回避
徹底した バージョン管理
レビュー 効率化

いずれも欠かせない要素になってきます。

そこで、リポジトリを真と見なす、GitOpsを活用します。

GitOpsとは

GitOpsとは何なのか？ GitLabの記事「GitOpsはインフラ管理の次の主流になるのか」によると、GitLabでの定義は

GitOpsは、バージョン管理、コラボレーション、コンプライアンス、CI/CDなど、アプリケーション開発で使われているDevOpsのベストプラクティスを、インフラの自動化に適用した運用フレームワークです。

となっていると記述があります。

同記事で

GitOps = IaC + MRs + CI/CD

というめちゃくちゃ分かりやすい数式もあります。(言語の限界を感じますね)

MR(Merge Request)はGitHubでいうところのPR(Pull Request)に該当するわけですが、GitHubで運用する場合も同様かと思います。

今回はSaaSでの事例ということで、 IaC (Infrastructure as Code) 、つまり、インフラ管理部分はないので、実質的には PRs(MRs) と CI/CDs で構成されます。

GitOps運用イメージ

実際のGitOpsでの運用イメージは、下記画像の通りです。

fig1

WFと記載しているのはWorkflowと呼ばれるデータ処理パターンのようなものですが、そこを除くとどんなシステムでも同じような形で開発が出来るのではないかと思います。

GitOpsを実践する上で重要なポイントとしては、

レビュー出来る人間 をなんとか確保する
とにかく CI/CDを最初に組み上げる

といったところでしょうか。

レビュー出来る人間を確保できていなければ、コードの善悪が判断できずうまく回らないですし、CI/CDは一番最初に組み上げたほうが間違いなく大局的に見たときの開発効率は上がります。(面倒くさがらず最初に必要なものは組み上げておきましょう…)

GitOps採用の恩恵

下記はこのようなフローで回すことで、気付いた恩恵についてのスライドです。

fig2

順に見ていきます。

リポジトリが真であることによる属人化の回避
- いわゆる 「single source of truth(SSOT)」 ですが、とにかく今何が本番環境にデプロイされているのかを正しく把握できることは間違いなく大きく保守性を上げますし、変更の追跡もできます。
他のワークフローのコード流用やまとめての変更も容易に
- これは今回のSaaS特有のところの話でもありますが、より汎用的な内容に落とし込むのであれば、他のサービスで使っているインフラ構成の流用なども簡単になる、ということです。
- 最近のインフラサービスはGUIベースで色々できてしまうのですが、可能な限りGUIは触らないほうが保守性・再現性という観点では間違いなく上がると思います。
差分管理による事故防止
- プルリクエストをレビューする際に、差分を確認できることで、不要なコードが入っていないか等の 確認が容易になります。
- また、Revertすればいいわけなので、問題が起きたときの 切り戻しも簡単になります。
レビューによる品質向上、メンバーの力量もUP
- そして、非IT企業で一番大きく役立つのはここだと思います。メンバーのコードのレビューの中で改善点を指摘することができ、それを踏まえて直してもらう、というプロセスは 間違いなくメンバーの力量を上げます。
- ちなみに、 レビュワー自身も色々考えているうちにより力が付きます。

これらは実際に参加しているメンバーから寄せられた意見であり、非エンジニア含めてうまく機能していると思います。

よくある 「SQL書けないマーケターは許されるのか？」 という問題もこういったフローでトレーニングすれば必ず書けるようになる…はずです 🙄 (本人のやる気次第なのには変わりませんが…)

まとめ

このようにして朝日放送グループホールディングスでは少人数でも回っていけるようGitOpsを実践しています。

実際、 エンジニアという括りでないメンバーにも明確に力がついた ことで、その有効性も実感しています。

幸いにも現在は各種ツールが充実しているので、昔に比べて大規模なサービスを少人数でも回せるような仕組み作りは決して不可能ではありません。例えば最近だと、ChatGPTをアシスタントとして使えばより効率的に働ける実感があります。

まあ、もちろん、メンバーが増えるのが一番…ではありますが、メンバーが増えたときにスムーズに開発に加わってもらうためにもGitOpsは役に立つと思います。