ソフトウェアの開発では手動でテストを回したり、デプロイしたり、といった作業が発生すると思うのですが、毎回それらを手で行うのは本当に非効率的です。

毎回することは決まっているので、機械ができることはできるだけ機械に任せ、人は人ができることをするべきだと思います。エンジニアはエンジニアにしか出来ないことに集中する環境を作るために、自動化ツールを最大限に活用しています。

「言った言わない問題」を未然に防ぐ。プロセス自動化の効果

具体的な開発体制はどのように自動化されているかというと、GitHubを中心にTravis CI、Coveralls、HipChatなどを連携させています。gitのブランチモデルは基本的にGitHub Flowに則っていて、そのフローの重要なポイントに自動化の仕組みを取り入れています。

例えばプルリクを投げたらチャットに通知が飛んできたり、gitのリリース用タグをpushするとTravis CIがバイナリをデプロイしたりという形です。バイナリのデプロイ先はGitHub ReleasesとAmazon S3に多重化していて、GitHubが落ちてもリリースが行えるような体制にしているのもポイントです。

このフローを導入する前は手動でデプロイスクリプトを回して、完了したことを目視で確認してチャットに投稿する、という流れでした。

この場合だと連絡することを忘れてしまうこともあって、「もうステージング環境に上げた？」「あ、すみません、終わっています。チャットに書くの忘れていました」「もっと早く言ってよ！」というやり取りが度々あって（笑）。こういうのって本当にくだらないですよね…。

それまでは人間の目で確認していたことをチャットツールのBotが自動で行うことで、デプロイされた瞬間にちゃんと全員に共有されるので「言い忘れ」による無駄がなくなりました。

Travis CIを中心に、「人がやるべきことをやる」仕組みを作る

開発フローを自動化していく上で、今やTravis CIのようなCIツールは欠かせません。Travis CIやCircle CIなど色々と種類があるのですが、導入当時に唯一iOS/Android双方のビルドに対応していたTravis CIを選択しました。

それ以前はリポジトリ管理にGitHub Enterpriseを使っていたので、内部にJenkinsを立ててJenkins職人をしていました（笑）。GitHubに移行してからは外部のサービスの連携が非常に楽になりましたね。

Travis CIが動作するタイミングはいくつか設定していて、「Pull Requestを投げたとき」「Pull Requestをマージした時」「リリース用タグをpushしたとき」の3つです。どのタイミングでもコードの静的解析とテスト、ビルドは走らせています。

それに加えて、Pull Requestマージのタイミングでは開発環境へも自動でデプロイされます。そこで実機で動作確認をして、最終的にリリース用タグをpushするとGitHub ReleasesとS3にデプロイされる、というのが全体像です。ちなみに静的解析ツールはGo言語用のgo vetとgolintを使っています。

GitHubとTravis CIを連携させるとテストやビルドの結果を表示させることができます。ビルドがコケるとPull Requestに「☓」マークが出るようになっていて。「☓」マークが消えるまではレビューをしない方針にしています。

テストを通らないレベルのものを人間がチェックする意味って無いですよね。機械がやるべき仕事が全部できている状態にあれば、エンジニアが設計や書き方の意識合わせを目的にレビューができるようになります。人のパフォーマンスを最大化できるような環境ができていると思いますね。

新しいツールは積極的に取り入れる組織文化

Travis CIは他にもCrashlyticsやCoverallsと連携させて使っています。Crashlyticsはクラッシュレポート解析ツールなのですが、その中のBetaという機能を利用してリリース前のiOS/Androidアプリケーションを自動的にテスターに配布しています。

Coverallsはテストのカバレッジ計測ツールです。カバレッジは100％を目指すものでもありませんが、サーバーサイドのコードは80%以上をキープしようという気概でやっています。

機能追加でコード量がどんどん増えていくので日に日に難しくなっていきますが（笑）。でもそういった高い目標への意識を常に持つことでテストしやすい設計になるし、コード量を増やしたくないのでコピペすることも減り保守性が格段に上がります。

このように新しいものを積極的に取り入れていますが、意識しているのはしっかりとドキュメントとして記録を残すことです。

導入するツールの中にはマッチせずに全然使えないものもあるのですが、そういったこともドキュメント化すると組織としての資産になります。後で誰かがそのツールを使ってみたいと思った時に参考にできるような資料をできるだけ残すようにしています。

あくまでも「良いサービスを作る」ためのテスト

外に出すプロダクトを開発している以上、テストは絶対に書くべきだと考えています。「良いプロダクト作りました！テストは書いていませんが 」というのは恥ずかしいですよね。

そもそも自分がユーザーだとしたら、テストしていないものはバグが怖くて使えませんし。ソースを公開する場合にも同様で、他のエンジニアに安心して再利用してもらうためにもテストは必要なプロセスだと思います。

ただ、エンジニアの1番のミッションはテストではなく「コードを書いて良いサービスを作ること」です。あくまでもサービスとしてのアウトプットを担保するためのテストなので、機械でできる部分はしっかりと取り入れて自動化・効率化することが重要です。

「餅は餅屋に」という考え方ですね。今後もこのように、エンジニアの能力がしっかりと発揮されるような環境づくりを意識していきたいと思っています。(了)