オープンソースカンファレンス Nagoya 2015「クラウドサービスを活用した開発環境」 #oscnagoya

謎セッションだ講師: mzp/水野洋樹（ocaml-nagoya）司会：法林浩之（日本UNIXユーザ会） https://t.co/EeN5Noyr9U
— てるろー (@terurou) May 22, 2015

オープンソースカンファレンスNagoya 2015の日本UNIXユーザ会のゲストスピーカーとして発表を行なった。

当日の発表資料および原稿は以下の通り。ただし、資料を作る際に構成を調整しているので、一部内容に食い違いがある。

導入

あいさつ

みなさん、こんにちは。みずぴーと申します。今回は御縁があってJUSのセッションに立たせてもらっています。

OSCは何度かブースに立ったりしたんですが、こちらに立つのは初めてです。さすがに緊張しますね。

アジェンダ

OSCはマルチトラックですし、ブースがでてて忙しいですね。みなさん、スタンプラリーやりました?

というわけでまずはこのあと話すことのアジェンダを紹介しておきたいと思います。

SIerからスタートアップに転職しましたら、環境開発がガラっと変わった。
どうかわったかや、どう開発フローに取り込んでいるかを話します。
使っているクラウドサービスはGithub, Slack, Google hangout, Qiita:team, Herokuなどです。

思ってたのと違うなー、って人は別のセッションを除きにいったりするといいんじゃないでしょうか。

自己紹介

まずはボクが普段何やってる人間かを話したいと思います。

名前はさっきもいいましたがmzpで、Twitter等にはmzpというアカウント名で登録してます。あと所属にあるocaml-nagoyaは、OCamlという関数型プログラミング言語の勉強会です。最近は動いてないですが、はじめてからもう6年くらいになります。ので、OCamlの紹介でもいいかなぁ、と思ったんですが、あんまりOSCっぽくなかったので、今日は開発環境の話をしたいと思っています。

OSS活動

オープンソースカンファレンスなのでまずはオープンソース活動の話からしたいと思います。

とはいても、大規模なオープンソースソフトウェアにコミットしてるようなことはなくて、小さいOSSのメンテナンスを引き継いだり、たまにパッチを送ったりしている程度です。

AquaSKK: MacOS Xでの日本語入力システム。根強いファンがいるものの更新が止まっていた、かつ最新のOSで動かなかったため、メンテナンスが止まっていたので更新引き継ぎ。
rubocop: 業務で使っているソースコード lint。ちょいちょい壊れるので、たまにパッチを送っている。
autodoc: 業務で使っているドキュメント生成ツール。機能が不足していたので、パッチを送った。

あとは、2〜3人で開発しているソフトウェアもクローズドにするメリットがないので、オープンソースにしてます。

FlickSKK: iPhone/iPadで動く日本語入力システム。
AsakusaSatellite: オンプレサーバで動かせるチャットシステム。
その他: http://github.com/codefirst/

経歴

で、仕事ですが、去年までは自動車部品メーカーの社内システムを開発する仕事をしていました。

で、去年の末ごろに転職して、今ははMisocaという請求書を郵送するWebサービスの開発をしています。これは弊社のスポンサーセッションというわけではないので、あまり深く紹介するつもりはないですが、簡単にまとめるとこんな感じです。

(スクリーンショット)

開発環境

で、作っているものの話はおいといて、このセッションの目的である開発環境の話をしたいと思います。

さて、その前に、ボク、ここに立つの初めてで、どういう方がいらっしゃるかを分かってないので、いくつか質問させてください。

いわゆる業務として開発にかかわっている方ですか? それとも、OSSなどの業務外の開発がメインですか? それともそれ以外ですか?
(業務外の人がおおければ)チーム開発ですか? 個人開発ですか?
どういった分野の開発ですか? Web系? ゲーム系? 組込み系? それ以外?
普段、クラウドサービスを開発に取り込んでいますか? バージョン管理? インフラ? それ以外?

なるほど、ありがとうございます。

ボクの前の開発環境

前職はいわゆる”SIer”というやつでした。なので、わりとよく聞く以下のような環境で開発してました。

やりとりは口頭・もしくはメール。まあボクのところはLotusNotesでしたが。えーっと、最新版からはLotus NotesじゃなくてIBM Notesという名称なんですが、これはまあ、そういうことです。最新版を使ってなかったってことです。スケジュール表や課題管理にはExcelを用いる。よくExcel方眼紙と揶揄されるやつですね。開発に必要な各種サーバは自社内にあるあと余談ですがスーツ着てました。

まあ、世の中にはスーツを着るのを異常に嫌がる人とかいたりするんですが、そういうのはおいといて、悪くない環境でした。

どう変わったか

そのあと今の会社に転職しました。

転職によって、ビジネスモデルや対象とするユーザの種類などは大きく変わりましたが、作業レベルですと「ソフトウェアを作ること」というのは変わっていません。

変わってはいないんですが、それを取り巻く開発環境は大きく変化しました。前職ではできる限り社内で完結させようとしていましたが、現職ではできる限りクラウドサービスを利用するようになりました。

今日はそのあたりの話をしたいと思います。

注意事項

あとでスライドを公開したりするので、このあたりで言い訳をいれておきます。

今回の発表は違いを紹介することであり、どちらかを批難する意図はありません。
また特定の企業、製品をお勧めする、もしくは批難する意図もありません。
今回の発表は開発者視点で解説したものとなります。実際に導入するにあたっては、それ以外にもセキュリティの観点、管理の観点、あるいは既存のインフラとの整合性などなどについても検討する必要がありますが、今回は省略しています。

ふう、じゃあ、本題にはいりましょうか。

ソースコード管理

ソフトウェアを作るにはソースコードを書く必要があります。えっと、正確には、モデル駆動開発とかビジュアルプログラミングとかあるんで、少なくとも、現時点において、大半の場合は、みたいな前提をつけないといけないんですが、まあ、それはおいておきましょう。

ソースコードを書いたら、どこかに保存しないといけません。日付ごとにフォルダをつくってそこにいれとくわけにもいかないので、なんらかのバージョン管理システムを使う必要がでてきます。

なので、まずはバージョン管理システムの話からはじめていきます。

社内サーバでの実現方法

さて前職ではどのようにしていたかと言うと

バージョン管理は社内のSubversionサーバ
チケット管理はRedmineだったりTracだったり、Eexcelだったり。この辺は、プロジェクトによって違いますね。
といった感じでした。まあ、いくつかのプロジェクトがあって、それぞれ歴史的経緯でそれぞれちょっとづつ違ってました。プロジェクトによってはかの有名なMicrosoft VSSを使っているところもありました。

Subversionはブランチのマージが非常に大変なので、運用は

全員がtrunkにコミットしていく
1人あたり1つづつブランチをもっていて、リーダがOKと思ったタイミングでtrunkにマージする

のいずれかでした。いずれもレビューがやりづらく結構大変でした。

Githubの基本機能

さて、現職もしくはOSSでは基本的にGithubを使っています。

GithubはGitレポジトリをホスティングするサービスです。レポジトリのホスティング以外にもIssues管理やWikiなどなどを持っています。

イメージキャラクターはoctocatという猫とタコを合体させた謎生物です。

Gitの特徴

Gitの話を詳しく話すと時間が足りなくなるんで、簡単に特徴を紹介すると

分散バージョン管理システムであり、中央レポジトリが不要。とはいっても現実的な運用だと中央レポジトリを作ることが多いです。たとえば、Githubがダウンすると、仕事がほぼ止まります。
ブランチの作成、マージが高速です。Subversionも作成はそこそこ早いんですが、マージが大変なのでブランチを作りづらいですが、gitはマージが楽なのでがしがしブランチを作れます。
コマンドが豊富。よくいえば使いこなすと便利、悪く言うとバ使いこなすまでが大変です。

といった感じです。

プルリクエスト

Gitの特徴はそんな感じなんですが、Githubの特徴的な機能として「プルリクエスト」というものがあります。

これは「とあるブランチから、別のブランチへのマージを依頼するための仕組み」なんですが、それだけ言っても分かりづらいと思うんで、具体的な作業の流れを元に見ていきましょう。

ある朝、ボクは元気に出社しました。すると、あわてて対応しないといけないタスクが発生していました。今回はとあるページの誤字を見つけてしまったことにしましょうか。まずはレポジトリの最新の内容を取得して、どう直すかをざっと検討します。直し方がきまったら、まずは今回の作業用のブランチを作成します。ブランチ名はfix_typoとかですかね。
そのブランチにばしばしコミットしていきます。ただひたすら誤字を直していきます。Gitは分散バージョン管理システムなので、外部に公開することなく、ローカルでコミットを積み重ねれるので、ファイルを保存するぐらいの気軽さで保存していきます。
さて修正作業がおわりました。コミットの内容を確認して、間違いがないかや、不要な変更をしてないかを確認したり、必要に応じてコミットをくっつけたり、分割したりします。
コミットに問題がないことを確認できたら、Githubにpushします。まあ、内容を他の人に公開する感じです。
あとは今回作ったfix_typoから、メインとなってるブランチであるmasterへのPull requestを作成します。
Pull requestのURLを他の人に渡してレビューを依頼します。
レビューの結果、問題なければマージされ、しかるべきタイミングで本番サーバへとデプロイされます。

※フィクションです。実際の業務・システムとは無関係です。

利点

Subversionで全員がtrunkにコミットしていくスタイルと比較して、プルリクエストを活用した開発フローには以下のメリットがあります。

作業の単位が明確になる。 1つのタスクが1つのプルリクエストに対応するようになるので、作業の単位が明確になります。これは他の人がレビューするときも便利ですし、あとから変更の意図を調べたりするときにも便利です。
必ずレビューがはさまる。誰かがマージボタンを押さないといけないので、必ずレビューがはさまります。適当にレビューOKだす人がいると破綻するので常に安全とは限らないんですが、少なくとも意図しないレビュー漏れは防げます。
レビュー支援機能が充実している。プルリクエストはGithubのメインの機能の1つなので、様々なレビュー支援機能があります。例えばdiffの各行ごとにコメントを付与できたり、画像のdiffも表示できます。
他のサービスと連携しやすい。Githubはエコシステムの一部に組込まれつつあるので、他サービスとの連携も容易です。例えばTravisCIというCIサービスと連携すると、各プルリクエストに対して自動でテストを走らせれます。またHerokuというインフラを提供するサービスのGithub sync機能を使うと各プルリクエストの内容を自動でデプロイして動かすこともできます。

OSSにおけるGithubの利用方法

さてオープンソースカンファレンスなので、業務の話だけでなくオープンソースの話もしておきましょう。Githubは業務にだけ使うわけでなく、OSSの開発にもよく使われます。

OSSを公開するほうは手元のソースコードをGithubで公開するだけですが、OSSにパッチを送る側のやることが変化します。これも具体的な作業の流れを見ていきましょう。

ある日、ボクは不幸にもOSSの不具合を踏んでしまいました。ざっと調べたところなんとか直せそうです。
直すために最新のソースコードを取得して、修正するためのコミットを行ないました。ここまでは先ほどとほぼ同じです。
OSSのレポジトリに直接コードをpushできないので、まずはメインのレポジトリを自分のアカウント以下にforkしてきます。これは同じ内容のレポジトリをコピーしてくるのとほぼ同じです。
自分のアカウント以下のレポジトリにはpushできるので、こちらに修正するためのコミットを含むブランチをpushします。
あとは今回作った自分のレポジトリから、メインとなってるレポジトリのmasterへのPull requestを作成します。
あとはしかるべきレビューがはいって、マージされるかリジェクトされるかのいずれかが行なわれます。

ポイントは自分がコミット権を持っていないレポジトリであっても、レポジトリをforkしてpull requestを作成できることです。

利点

これによる利点は、さきほどのものに加えて以下のものがあります。

自分にコミット権がないOSSであってもバージョン管理できる。簡単な不具合修正だと特にバージョン管理できなくてもいいんですが、ある程度の規模があるやつだと手元でもバージョン管理したいですよね。
普段とほぼ同じ作業の流れでOSSに参加できる。まあ、これは人によっては逆で、OSSに参加するのと同じ流れで業務ができる、って人もいると思います。というかボクはこっちですね。
publicなレポジトリなら無料で使える。

個人的には慣れた作業の流れがそのまま使えるのが最大のメリットだと思っています。

類似サービス

Githubが唯一無二のソースコード管理サービスというわけでなく、他にも類似のサービスがいくつか存在します。

Bitbucket: Githubの次に有名なのはBitbucketですね。Githubは有償プランに入らないと非公開レポジトリを持てないんですが、Bitbucketは非公開レポジトリを無料でいくつでも作成できます。(参加できる人数に制限がありますが)ほかにも、Githubにある機能はたいていBitbucketにもあります。ので、機能だけ比べるとBitbucketのほうがすごそうなんですが、なぜかメジャーになれていないですね。
Gitlab.com

また、GithubもBitbucketもいわゆるクラウド型のサービスですが、社内のサーバにインストールできるタイプのソースコード管理サービスもいくつかあります。

Github Enterprise: Githubから提供されている有償のソフトウェアです。Githubのほぼ同じ(一部、ちょと古かったりすることがあるらしい)を社内のサーバにインストールできます。
Githubクローンたち(Gitlab, bitbucket, ...): githubと同等の機能を提供しようとしているOSSがいくつかあります。

コミュニケーション

次はコミュニケーションの話です。だいたいソフトウェアはチームで作るので、コミュニケーションが重要となります。コミュニケーションといっても短時間で終わるやつから、数週間かけて合意を作っていくようなものまであります。

ここでは10分くらいで終わる雑談に近いようなコミュニケーションの話を対象とします。

社内システムでの実現方法

これタイトルをあわせるために「社内サーバ」にしたんですが、あんまり関係ないですね。

前職でのコミュニケーション手段といえばメールを出すか、電話をかけるか、あるいは直接話すかのいずれかでした。

「直接話す」というのは、おそらく今後もしばらくなくなることはないので、これは置いておきましょう。

メール: ある程度まとまった文書を送るのが一般的になので、簡単なコミュニケーションには使いづらい。
電話: 複数人で会話できない。映像は送れない。まあ、グループ通話やテレビ電話も存在するんですが、あまり一般的でないので、ここでは扱いません。

まあ、こんな感じに欠点をあげたんですが、メール、電話に利点がないわけではないです。最大の利点は「標準化されている」ことです。他社のサービスにメールを送ることもできますし、電話をかけることもできます。この相互運用性は、他の後発のサービスにはないメリットです。また、仕様も共通化されているので、新しい会社がメールサービスの提供を開始することもできます。電話は電波法とかインフラとかを準備しないといけないので結構大変ですが、仕様的には可能です。

ので、この後の話はメールや電話を置き換えようという話ではなく、社内のコミュニケーションを効率化するためのサービスの紹介です。

チャットツール: Slack

Slackはテキストチャットツールです。どういうことができるかの説明の前に画面を見てもらったほうが早いと思います。

[ここに画像をはる]

いわゆる普通のチャットツールで、全員が発言している
チャンネル(部屋)が分かれていて、そこで個別で話が進んでいきます。
直接メッセージを送ることもできます。
絵文字が使える && 自由に追加できるのでコミュニケーションが円滑になる

Webサービスだけでなく、iPhoneアプリやデスクトップアプリもあるので様々な環境でチャットすることができます。便利なんですけど、夜中にエラーメッセージが来るとちょっと微妙な気分になりますね。。

また、個人的には「IRC gatewayが準備されているので、既存のIRCクライアントが使える」というのを押したいです。ちなみに、IRCクライアント経由でつなぐとさきほどのカラフルな画面がこうなります。

[スクリーンショット]

メールと比較した時のメリットとして

短い文書でも気軽に送信できる。相手も気軽に返せるので、結果としてやりとりが早くなる。わりと感覚的なものなので人によっては違うかもしれない。
多数の人に同時にメッセージを送れる。
送られたメッセージをあとから検索できる。
各メッセージにpermlinkがつくので、他のサービスからリンクを貼れる

Google Hangout

Slack、すごく便利なのですが、やっぱり言葉を交わしたいこともあります。そういうときはGogleHangoutによるビデオ会議が使えます。

これも画面を見ていただいたほうが早いですね。

[スクリーンショット]

こんな感じで全員のカメラが写っていて話をすることができます。人によってカメラをオフにしてアイコンを写したり、あるいはモノクロ加工をしたりできます。

使い方の例

具体的な使い方を見て行きましょう。

朝出社すると朝会がはじまります。だいたい毎日、何人かリモートで勤務するので、常にGoogle Hangoutで行なわれます。
そのため、オフィスには集音マイクとカメラが常に起動しています。
朝会がおわったので、作業をはじめていきます。質問等は適宜Slackで聞いたり、答えたりしていきます。
作業が一段落したあたりで社外の人と打合せです。東京にいる人たちなので、今日はリモートで打合せです。社内用とは別のHangoutをたちあげて、そちらで打合せをしていきます。
打合せが終わったので、作業をはじめていきます。質問等は適宜Slackで聞いたり、答えたりしていきます。

類似サービス

Githubにも類似サービスがあったように、こちらも類似サービスがいくつかあります。まずSlackのようなチャットサービスですと、次のような類似サービスがあります。それほど使ったことないものばかりので、簡単な紹介だけさしていただきます。

HipChat
ChatWorks
idobata

ビデオ会議ですと、ちょっと変わったアプローチとしてSqwiggleというのがあります。起動するとカメラが数分おきにスナップショットを取って送られていきます。で話したいときは各メンバーの写真をタップするといきなり通話がはじまります。常時カメラで相手の状況が映し出されてるので、相手がいる/いないの確認がいらない Hangout を始める時の招待とか url のやりとりとかそういうのも一切必要ない。会話の途中で、その会話にもう一人追加したいとおもったらその人もタップすれば3人での会話になる。といった特徴があり、直接会話する感じをうまく再現しています。

弊社でも一時期使っていたんですが、常にHangoutにはいっていても同じようなことができる点などがあり、結局使うのをやめてしまいました。

文書管理

チーム開発にはチャットやビデオ会議によるコミュニケーションだけでなく、決ったことやノウハウなどを文書にしてまとめておく必要もあります。

文書として管理しないといけないものは以下のものがあります。

TODO: このあとにやることです。例えば追加したい機能であったり、修正しないといけない不具合だったりです。
日報: 日々の作業の結果です。他の人がなにをやってるか知ったり、自分が困ってることを書くと誰かが答えてくれたりして便利です。
ノウハウ: 日々の作業の結果、その2です。調べた技術の情報のまとめであったり、今後どうシステムを変えていきたいかの展望であったりと、そういう文書です。
議事録: 打合せの結果です。特に外部との打合せの結果は残しておこないといろいろ大変ですよね…。
外部から受け取ったドキュメント: 文書化とは違うんですが、もらったAPIドキュメントとかも管理する必要があります。まあ、「foo_最新版.xls」ってのが3つくらい来たりしてつらかったりします。

社内システムでの実現方法

前職での実現方法はExcelに書いた文書を共有フォルダに置くことで実現してました。あと、LotusNotesにまとめられていることもありました。

これが今、どう変わったかという話をしていくんですが、文書の種類によって管理の方法が違うので、1つづつ見ていきましょう。

TODO: Trello

まずはTODO管理です。これはTrelloというサービスを利用しています。

[スクリーンショット]

これは1個のカードが1個のカードになっていて、それをどこかのリストにいれておきます。そしてステータスがわかるたびに、その間を移動させていきます。

リストの例としては * やるかどうかを検討する * やる * やっている * 誰かの連絡をまってる * おわったのでレビューしてほしい * おわったなどがあります。

イメージとしては、でかい紙にポストイットを貼りつけて、それを移動させていく感じです。

日報、ノウハウ: Qiita:team

次は日報やノウハウの共有です。これはQiita:teamというサービスを使っています。これはQiitaというプログラマのためのノウハウ共有サービスの社内版です。

まずは、Qiitaは「プログラミングに関する知識共有サービス」です。特徴として、

Markdownで書けて、シンタックスハイライトができる
タグ付けや全文検索など、検索オプションが豊富
Kobitoというクライアントがあるので、Webブラウザだけでなく、デスクトップアプリから書くこともできます。
ITエンジニア向けにつくられている。対象をITエンジニアに向けてしぼっているので、こまかい部分が合うように作り込まれてます。などがあります。

Qiita:teamはこれを社内向けにしたものです。

特定のメンバーしか投稿、閲覧できません。
テンプレートをあらかじめ設定できる。例えば、日報のテンプレートや、不具合レポートのテンプレートなどがあります。

あとはQiita本体とほぼ同じです

みなさん、想像できないかもしれないですが、テキストファイル以外は書きたくない、書けないプログラマも多いんですよ...。

Qiita:teamの例

具体的なQiita:teamにはこういうのが投稿されています。

日報。これは日々、投稿される日報ですね。
つぎにノウハウ。技術について調べたので、その簡単なまとめです。
あとは次の展望とかもあります。

GoogleDrive

文書管理の最後は、議事録や他からもらった文書の管理です。これはGoogleDocsあらためGoogleDriveを使います。

これの特徴としては * 文書、スプレッドシート、プレゼンテションというMS Officeで作れる文書はだいたい作れます。いや、Visio相当のやつとかはないですが。 * それ以外のファイルも編集できないだけで、管理できる。 * 設定によって、自分だけが見れる・編集できる、チーム内の人が見れる・編集できる、URLを知ってる人が見れる・編集できる、を切り替えれる。 * 複数人で同時に編集できる。これ結構すごくて、他の人がどこにカーソルキーをおいてるかとかも共有されてます。 * 若干UIが謎。個人的な感想ですが、GoogleのUIってわりと謎がおおいですよね…。などがあります。

これを使って議事録や他からもらった文書を管理しています。

議事録: 議事録、ものによっては先ほどのQiita:teamに書くのもあります。が、全員で話した結果をその場でまとめていきたい場合は、共同編集にした文書にまとめていくこともあります。ホワイトボードにみんなで書いてまとめていく感じににてますね。
他からもらった文書: GoogleDocsにつっこんでおく。xlsとかでも表示だけはできるので便利。それ以外のファイルは動画とかはダウンロードしないとみれないんですが、まあ数もないのでそれほど不便ではないです。

類似サービス

Qiita:teamに似たサービスとしてはesa.ioがあります。書きかけのやつも共有できるようになってたり、Qiita:teamよりカテゴリ分けの仕方がわかりやすかったり、キャラクターがかわいかったりでわりと好きです。のりかえるほどではないですけど。

あと使ったことはないですが、GoogleDriveの対抗馬としてはOffice365がなるんじゃないかなぁと思っていますが、詳しくはないです。

その他

メインで使うサービスはこんな感じですが、それ以外のサービスも簡単に紹介してきます。重要じゃないからというよりも、時間の都合です。主に資料作りのほうの時間が。

bot

1つめはbotです。ここまでで紹介してきたいくつかのサービスは、そのままで十分便利なんですが、残念ながらかならずしも相互連携してるわけではありません。

なので、 * 更新通知がそれぞれ別々の方法で届く * 何か操作したい場合は、それぞれのサービスにログインして操作する * 複数のサービスを連携させる場合は、間にいる人間ががんばるといった感じになります。面倒ですね。

そこでそれらの間をつなぐ、グルー(糊)となる何かが必要となってきます。それがbotです。

botとはチャットで動く自動応答プログラムで、定期的に何かの処理を実行したり、あるいは特定の語句に反応して何かをしたりします。

例えば、以下のような作業をします。 * 各サービスの更新通知をする。 * プルリクエストのタイトル、Trelloカードのタイトルを教えてくれる。SlackはURLを貼るとタイトルとかをつけて引用してくれるんですが、当然、認証が必要なやつは引用してくれないので、botに引用してもらいます。 * 今日の当番を確認する。ウチではユーザさんからの問い合わせ対応を持ち回りでやっています。その当番表がgoogle drive上のスプレッドシートにあるので、botが毎日それを確認しにいって、通知してくれます。 * デプロイを依頼する。Githubと後述のCircleCIを組合せて、デプロイの自動化を行なっています。行なってはいるんですが、そのための準備が結構面倒なのでbotによって自動化しました。結果として「@bot hoge(ブランチ)をデプロイして」と言うと、プルリクエストを作ってくれるので、そのマージボタンを押すとデプロイされるようになりました。

また連携とは関係ないですが、以下のようなこともやっています。

朝会のリマインダ。朝会の5分前になると、「そろそろはじまりますよー」とリマインドしてくれる。
毎晩、ユーザ数を通知してくれる。今のシステムの目安みたいなものです。

このbotはrubotyというbot フレームワークにslack adapterをいれて利用いています。プラグインはわりと自作しています。

この「テキストをうけとって動作する」「画面はつくらなくていい」「既存のサービスを組合せてやりたいことを実現する」という仕組み、シェルスクリプトっぽいなー、といつも思ってます。

ほかに話していないこと

それ以外にも話していない話題がいくつかありますが、それは駆け足で紹介していきます。

CircleCI: わりと高機能なCIサービス。特にビルド方法などをカスタムしなくても並列でビルドしてくれたり、サーバにsshでつないでトラブルシュートできたりして便利です。
Bugsnag: エラー管理サービス。アプリケーション内で発生した例外を管理できます。似たようなエラーをまとめてくれたり、エラーごとに解決済み等のステータスをつけれたりします。
Mixpanel: ユーザの動向を追跡できます。アクセス数であったり、あるページから別のベージへに遷移した割合などを追跡できます。