わたしたちはアジャイル開発の手法のひとつであるスクラムを取り入れて、1週間のスプリントで開発をしています。1週間というサイクルの中でスピード感のある開発をするためには、作ると捨てるが簡単にできる開発環境の構築がかかせません。
アジャイルを始めて10年たちましたが、この10年で学んだことの一つとして「複雑なしくみはスケールをしない」というのがあります。
開発チームにはいろいろなスキルやバックグラウンドを持ったメンバーが集まります。開発ツールをそろえておく、Homebrewを活用する、Gitの操作をGUIだけでできる運用にしておく、MavenやDockerのよく使うコマンド群はシェルスクリプト化して1クリックで実行できるようにするなどシンプルなしくみにするための取り組みをしています。
開発ツールをはじめとした開発環境の構築だけでなくローカルでの実行環境もシンプルになるように改善を進めてきました。以前は各自のマシンに直接実行環境を構築していました。しかしさまざまな問題があったため、現在はDockerを導入して同じ環境を作れるようになっています。
目次
初期の開発スタイル
最初の頃は各自の開発マシンに直接TomcatやMySQLをインストールしてもらっていました。
しかしこの方法では次のような課題を抱えていました。
- 新しいメンバーが入った際に開発環境構築に時間がかかる。
- エンジニアごとに開発環境が微妙に異なり、問題が起きたときの切り分けがしづらい。
- ミドルウェアのバージョン切り替えがしづらい。
新しいメンバーが入った際に開発環境構築に時間がかかる
インフラ構成が管理されていないため、新しいメンバーが入ったときにはTomcatやMySQLのインストールをおこなった後、設定ファイルを手作業で書き換えてもらう必要がありました。設定の写し間違えがあると起動しなくなるため、どこが間違っているかエラーログなどを調べながら調整する必要がありました。
エンジニアごとに開発環境が微妙に異なり、問題が起きたときの切り分けがしづらい
入社時期によってミドルウェアのマイナーバージョンが少しずつ違っていて、特定のバージョン以降でエラーが起きたり、設定ファイルの書き方をバージョンにあわせて変えないといけなかったりしました。
設定ファイルに変更が入ったときもメンバー間で適用状態に差が出て、少しずつ異なる設定ファイルで開発している状態になっていました。誰かの環境で問題が起きたときに設定ファイルの問題なのかバージョンの問題なのか切り分けがしづらくなっていました。
ミドルウェアのバージョン切り替えがしづらい
ミドルウェアのバージョンを上げる基本的な流れとしては、開発環境のバージョンを上げて問題ないことを確認できたら本番環境のバージョンを上げるという流れかと思います。
しかし開発環境のバージョンを上げる、下げるといったことが気軽に行えず、バージョンを上げて問題が起きた場合、そのエンジニアは問題を解決するまで他の開発ができなくなってしまいます。他のメンバーのレビューをするにも手元の環境が起動しないのでコードレベルでの確認となり動作確認ができない、本番環境で不具合があった場合もローカル環境ですぐに確認できない、という非常に動きの取りづらい状況がうまれます。
過渡期
その後Socket通信やLambdaによる定期実行処理など対応するサービスが増え、すべてのエンジニアで同じ開発環境を0から構築することが現実的ではなくなってきました。
このエンジニアの開発環境ではsocket通信がまだうまく動いていないので、そこの機能追加をお願いできない。開発したコードに問題があっても、もともと動いてない部分があったので影響が出たことに気づくことができない、という問題が出てきました。
すべてのエンジニアで同じ開発環境を構築できるようにHomebrewやDockerの導入をすすめ、今はこのような構成になっています。
現在の開発スタイル
ミドルウェア
Java, Node.js, Maven, Docker, GitなどはすべてHomebrewによる管理にしました。バージョンの管理などエンジニア間で足なみをそろえやすくなりました。
統合開発環境（IDE）
わたしたちのプロダクトではサーバーサイドをJavaで、フロントエンドをVue.jsで書いています。統合開発環境（IDE）としてJavaの開発にはEclipseを、フロントエンドの開発にはVisual Studio Codeを使って開発をしています。
Eclipse
Eclipseではプラグインをインストールする手間をへらすため、Pleiades All in Oneを使っています。そこに以下のプラグインを Eclipse Marketplace 経由でインストールしています。
EclipseからAWSのリソースを確認するためのツール。
EclipseでVelocityを編集するためのエディタ。
新しいメンバーがEclipseの環境を構築するときに「エラーが出てこのプラグインがインストールできません」や「Eclipseのバージョンが変わってプラグインのUpdate SiteのURLが変わったみたいです」みたいなことが発生し、Eclipseの環境を整えるだけでも時間がかかってしまうことがたびたびありました。しかもこういった問題は自分で解消すべきか聞いてしまったほうが早いか、入社してすぐだと判断が難しくなかなか質問しづらい内容です。
そういった手間をなくすため、同じバージョンの Pleiades All in One を使ってプラグインはMarketplace 経由にすることで構築がスムーズに完了できるようにしています。
Visual Studio Code
Visual Studio CodeはAtomのサポート終了がアナウンスされてから移行したため、使い始めてからまだ間もないです。そのためプラグインもいろいろなものを試して検証しながら使っている段階です。入れているプラグインは2つだけになっています。
Vue.jsを扱いやすくするためのプラグイン。
Vue.jsの構文をチェックするためのプラグイン。
データベース管理ツール
開発環境でのデータベースの管理にはMySQL Workbench と phpMyAdmin を併用しています。
基本的にはMySQL Workbenchを使ってデータやindexの確認などを行っています。phpMyAdminはパフォーマンス計測として接続数やSQL発行数、Slow Queryの確認に使用しています。phpMyAdminは時系列の推移がグラフで表示され、そこからSlow Queryの確認がしやすいため導入しています。
phpMyAdminはDockerコンテナとして起動するようにしています。
実行環境
Docker Compose を使って構成管理をしています。いまは8個のコンテナが起動しています。
ビルド自体もDockerコンテナ上で行うようにすれば、JavaやNode.jsのバージョンの切り替えがもっと簡単になりますが、バージョン切り替えが必要になる頻度と日々のビルドにかかる時間を考えてMacOS側でビルドしています。
AWSのサービスについてはDynamoDB ローカルを使うなどしてコスト削減をしています。
コマンド群
Dockerの導入に合わせてよく使うコマンドもシェルスクリプト化しました。開発環境がMacなので拡張子が .command のファイルにしてダブルクリックで起動するようにしています。
MavenでビルドしてDocker上のTomcatを再起動する。こういった一連の操作を1コマンドで実行できるようにしています。
コマンド完了時にはプッシュ通知で知らせるなど、かゆいところに手が届くようにこまかな改善を重ねています。
まとめ
15年以上開発しているプロダクトですが、つねに開発環境を見直して新しいメンバーでもすぐに開発に参加できるとりくみをしています。開発環境を改善したことでエンジニアは開発作業そのものに集中し、安定した開発スピードを出せるようになりました。
一緒に働く仲間を募集しています。
新卒採用・中途採用を問わず、年間を通して、さまざまな職種を募集しています。「すぐに仕事がしたい」「話を聞いてみたい」「オフィスを訪問してみたい」など、ご応募をお待ちしています。共に未来をカタチにする仲間を待っています。
