ぱと隊長日誌

ブログ運用もエンジニアとしての生き方も模索中

デブサミ2018「【16-C-3】Gitで安定マスターブランチを手に入れる」聴講メモ

はじめに

Developers Summit 2018 (Developers Summit 2018)
【16-C-3】Gitで安定マスターブランチを手に入れる
スピーカー:井上 誠一郎 さん [ワークスアプリケーションズ] / 三宅 泰裕 さん [ワークスアプリケーションズ])
の聴講メモです。

メモは口頭説明を中心にまとめています。資料を併せてご参照ください。

Twitterのつぶやきがtogetterでまとめられています。併せてご参照ください。
【デブサミ2018】16-C-3「Gitで安定マスターブランチを手に入れる」 #devsumiC #devsumi - Togetter

【参考】としている個所は私が挿入しています(補足や参考資料など)。登壇者の講演内容ではありませんので、その旨ご了承ください。

聴講メモ

用語

このセッションでの用語の定義として、マスターブランチとデベロッパーブランチを同じ意味で用いており、開発している最新のコードを指す。

マイクロサービス

既存のモノリスなシステムのマイクロサービス化を図ると、機能によってはライブラリの重複する物が発生する。だが、それを無理に切り分けると無駄が発生する。

マイクロサービス化したことにより、ビルド時間やデプロイ時間が短くなった。ビルドに37時間かかっていたのが5時間へ減った。

マイクロサービスの定義と現実のギャップでエンジニアから不満の声(こんなのはマイクロサービスといえない!)が上がることもあるが、ビルド時間の短縮をターゲットにして、できる範囲で進めている。

業務ドメインをきれいに分けたくても、重複はどうしても発生する。

開発拠点が世界各地かつ様々なコミュニケーションチャネルを持つ中で、後方互換性を保つことに対するコンセンサスを取るのが大変だった。
例えば、以下のようなことを考慮しなければいけない。

  • ライブラリやサービス間のAPIの互換性
  • データベースのスキーマ変更への対応
  • メッセージキューの内容の変更

後方互換性を確保する標準的な方法もあるにはあるが、大規模な人数だと必ずしも徹底できない。

業務ドメインの境目はあいまいで、エリックがいうほどきれいにはできなかった。

【参考】
エリックは言わずと知れたエリック・エヴァンスのことです。

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

テストと開発環境

テスト環境に存在しているライブラリと業務ドメインのバージョンがばらばらだとしたら、果たして本質的なテストが実施できるのだろうか?

開発環境の競合が問題となった。DBを共有すると、スキーマ変更の度に環境の利用者全員が待たされることになる。
マイクロサービスなら共有のAPも必要となる。モックを用意すればよい、という意見もあるかもしれないが、実際にはうまくいかなかった。
そこで、最終的には実物を用意することにした。

開発環境をクラウドでいくつも作ろうとすると、台数が多いだけに意外とお金がかかる(クラウドだから安いというのは幻想)。社内に空きサーバが転がっていたため、Openstack + Kubernetes (k8s) で構築することにした。

開発環境はチームもしくはドメイン単位で切り分けた。

開発環境が共有だったころ、環境を壊すと世界中の開発拠点から怒られた。
手元に開発環境が用意されたことで、環境を触ろうという意欲が出てきた。例えばCIに取り組むとか。

開発環境の分離とサーバリソースの効率化はトレードオフの関係にあり、そのバランスが肝になる。

開発者もQE(Quality Engineer)も同じ物を見てテストしたい。ユニットテストでカバーできないこと、例えばUI/UXのように人手で見るしかテストできないことを早くテストしたい。

だが、QEのテスト環境を壊すと怒られる。これをユニットテストで防ぐというのは簡単なことではない。だから、壊さないのではなく壊れても良い環境を用意する。

OpenStackのCinder。AWSのEBSに相当する。

【参考】
Cinderについては以下の記事が参考になります。
OpenStack 2012.2で追加された新機能「Cinder」を使う | さくらのナレッジ

業務アプリのバグはロジックと言うよりデータのバリエーションが多いことに起因することが多い。この種のバグをどう防ぐかが今後の課題となっている。