Kubernetesの知識をなるべく持たずに使えるお手軽開発環境
こんにちは！マネーフォワードと共同でプロダクトを開発しているクラウドインボイスチームでテックリードをしている西之原です！
今日は私が所属している『マネーフォワード クラウドインボイス』における受領に関する開発を行うチーム(以下、インボイスチーム)で利用している共用開発環境(通称: ndev)について紹介しようと思います。
左がジェイド(男の子)で右がアロ(女の子)
西之原希（にしのはらのぞみ）通称のんちゃん(男の子)
株式会社クラビス invoice事業本部開発部所属。
『マネーフォワード クラウドインボイス』の開発を担当している。
ndevってなんだ？
さて、まずは今回のテーマであるndevってなに？ということからお伝えしていきたいと思います。ndev の誕生秘話を話す前に簡単に、ndevとは何かを一言で言うと 、作業ブランチに紐づく共用の開発環境のことです。
(よくdev環境と呼ばれているような環境と同じです)
※ 元々は stay と呼ばれていたのですが、nonchan dev と名付けられ、それを文字って ndev と呼ばれています
この環境が生まれた背景
弊社でndev を導入した経緯についてお話ししたいと思います。ndevが採用された理由は大きく分けて2点あります。
インボイスチームのブランチ戦略
メンバー全員がk8sに熟知しているわけではない
インボイスチームのブランチ戦略は
feature ブランチ → develop ブランチ → mainブランチ
となっていて、develop ブランチと main ブランチがあり、それぞれステージングと本番に対応しています。
feature ブランチでは開発者同士の動作確認やデザイナーとのUI/UXの確認をおこなったり、ビジネスサイドによる確認を行えると理想的です。ですが以前はそのための環境がありませんでした。
実は共同で開発しているマネーフォワード側には idev と呼ばれている共用開発環境が存在します。マネーフォワード クラウドインボイス[受領]はステージングと本番は Service platform（マネーフォワードのサービス基盤組織）の環境を利用しているため、idev を利用すること自体は可能な状態ではありました(利用しようと準備は進めていました)が、 idev では開発者が k8s をある程度理解して利用していることが前提にありました。
しかし、当時はプロダクトが本番稼働に入る直前であり、開発者全員が k8s に詳しい状態ではなく学習している余裕はありませんでした。
そのため、 idev には乗らずチーム内で融通が効きやすく、開発者は k8s を詳しくなくても良い環境を手に入れるためにndev の構築をするところから始めたという訳です。(idev の思想自体好きで環境についても良く出来ているなと思っていて ndev を構築する際に参考にした部分も多くあります)
環境を構築するにあたっての大まかな方向性について
1.デプロイ手段
ndev のゴールは「開発者がk8sに詳しくなくても利用出来る環境」であったため限りなく人の手を使わずにデプロイ出来る様になっている必要がありました。
k8s のデプロイにはpull型とpush型のデプロイパターンが世の中には存在します。
pull型の場合は主に ArgoCD が多い（マネーフォワードの環境もこちら）
push型の場合は Helm chart や Manifest を kubectl 等でデプロイする
ndevについては今回、push型である Helm charts を利用しています。
ArgoCDを利用することも検討はしましたが、ArgoCDでの環境構築をするにあたって Application manifestの仕様を理解する必要があり、idevと変わらないため見送りました。
2.開発者が実際に利用する方法
開発者が詳しくなくても利用出来る環境にするためにはもう少し抽象化しておく必要があります。
インボイスチーム内での利用方法については
開発者が `feature/ndev/xxx` と ブランチを Github へ push することで
`xxx` の部分を Namespace や Ingress のドメインとして設定
BE/FEのイメージ作成
アプリケーションのHelm charts を Github packages からダウンロード
これらの Github actionsが動き出し、デプロイが自動で行われます。
これにより「開発者がk8sに詳しくなくても利用出来る環境」のゴールが達成されました！（やったね🎉）
デプロイ完了の通知や、デプロイ途中でのエラー発生などは別途デプロイを監視する仕組みを開発し、Slackチャンネルへ通知することで開発者が気付ける様になっています。
エラー時のログやコマンドを実行したい時などはKubernetes dashboard を構築し、ブラウザ上から確認や実行を出来る様にし、ツールの使い方を知れば良い様にし、開発者の負担を軽減する様にしています。
具体的にはこちらの図を参考にしてみてください。
まとめ
ndev を構築したことによって開発者がk8sに詳しくなくても利用できるようになっていて、新規参画された方にもすぐに利用してもらえる様になったり、長期間滞留する機能の開発でも外部サービスに依存しない機能においては、 ndev で動作確認や検証を行いながら開発出来ています。
副産物としては、依存モジュールのアップデートに Renovate を採用しているのですが、Renovateが作成するブランチを ndev にデプロイ出来るブランチ名にすることで、CI上でのユニットテスト以外に動作確認を利用することが可能となっていて開発体験も良く利用出来ています。
さいごに
「開発者がk8sに詳しくなくても利用出来る環境」を作るのに k8s の構築からするってどう言うこと？？？となると思いますが、当時の私のポジションがインフラ担当だったため構築から始めることにしました。
私自身は k8s の構築/本番運用を前職で行っていたのでこの決断に踏み切れたのと、転職して未だ日が浅かったのにそれを良しとしてくれた上長やメンバーには感謝しています。
ndevについては話したいことがたくさんあるので次回私に担当が回ってきた際には続きを書きたいと思います！（笑）
この記事が気に入ったらサポートをしてみませんか？