Android対応から見つめるReact Native

モバイルエンジニアの@chiiia12です。

先日@m-sugawaraからReact Native開発全般についての記事が公開されましたが、今回はAndroid対応にフォーカスして紹介します。

QuipperではReact Nativeで書かれた業務用アプリがあり、iOSでのみ提供していました。対象ユーザーは内部のスタッフに限られていたため、会社から配布している業務用iOS端末のみで正しく動作すれば十分だったためです。しかし私用端末でも使える方が業務上効率が良いこと・業務用の端末を用意するコストの観点から、会社からの端末配布をやめ、iOS/Android両プラットフォームでアプリを提供し私用端末で利用してもらうことになりました。

今回は私達のチームが遭遇したReact NativeアプリでのAndroid対応をサプライズ度(★★★)と一緒に紹介します。React Nativeのマルチプラットフォーム対応にはどんなものがあるのか、参考のひとつになればうれしいです。 なお、執筆時点でReact Nativeのversionは0.49.0を使用しています。

続きを読む

Quipper の Monorepo な Web アプリ開発における Git 戦略

Rails Developers Meetup 2019 の自社スポンサーセッションはいっそ休憩室にすればいいのでは? と言い出した Web dev の @mtsmfm です。お弁当や神授業、そして Quipper からは 3 名が登壇しましたが、発表は楽しんでいただけましたでしょうか。

僕は自分の発表@jeremy さんが聞いてくださったり、キーノートでは Rails 6 で入ったパッチを紹介してもらったりして感無量です。 この場を借りて Rails DM の開催に尽力された @yhirano55 さん他みなさまには感謝を述べたいと思います。本当にありがとうございました。

今日は、Quipper における Git ブランチ と Kubernetes を組み合わせた、開発から本番デプロイまでの流れを紹介したいと思います。

流れ

ざっくりとした概要としては Git flow をアレンジしたものを使っています。

f:id:quipper-ja:20190329191854p:plain

まず、開発のベースとなるものは develop ブランチです。ここから機能追加ブランチを切り、PR を develop に向けて出すのが基本です。PR 毎に Heroku で言うところの Review app のように、PR 毎に Kubernetes の namespace が作られます。

Quipper では先日、monorepo への移行をしました。これにより、一つの機能を実装するために API とフロントの両方に PR を出さないといけなかったり、場合によってはそれに加え社内 gem にも別途修正が必要だったものが、1 つの PR を出すだけで済むようになりました。また、PR 毎のステージング環境も Kubernetes でまるごと起動するようにしたため、動作確認のために個別のステージング環境を環境変数を切り替えて繋がるようにする必要がなくなりました。便利ですね。

次に、release ブランチです。release ブランチは毎回リリーステスト環境にデプロイされます。Quipper では現在概ね週に1回、QA の会社に手動テストをお願いし、テスト通過後に本番デプロイをしています。リリーステスト中に発覚した問題は release ブランチへ PR を出します。Git flow では release ブランチは新しい release-xxx ブランチを作ることになっていますが、Quipper では簡便化のために release ブランチは毎回リリース後に削除し、 develop ブランチを release ブランチとする流れです。

本番へのデプロイは master ブランチへのマージによって行います。早めに出したほうがいい修正は hotfix 用に master ブランチから派生させて PR を出しますが、週次本番デプロイでは release ブランチから master ブランチへのマージをします。Git flow ではこのとき Tag を打つことになっていますが、Web アプリケーション開発において Tag を打つメリットがなさそうなので打っていません。

最後に、修正の backport です。このままでは、図の bugfix-xxx や hotfix-xxx が develop に反映されていないため、本番やリリーステスト環境で直されている問題が、開発用環境だと発生するようになってしまいます。そのため、master から develop への PR を出し、backport を行っています。

Quipper ではこのように、Git flow を多少簡便化したような Git 戦略によって開発を行っています。

思わぬ落とし穴

概ねこのフローで問題なく回せていたのですが、先日、リリーステスト環境のコードがリリース予定のものになっていないことがありました。これについて説明します。 Quipper では monorepo に移行したのですが、非常に多くのサービスがあり、毎回すべてのサービスをビルド、デプロイするのは時間がかかります。そこで、k8s の deployment に前回リリースした Git のコミットハッシュ値をもたせ、その値と今回の内容の差分に当該サービスに関係ある変更が含まれているかを検出し、必要がないときにはデプロイをスキップしています。この差分検出の仕組みにバグがあり、前回のリビジョンが参照不能な際には差分がないものとして扱われてしまい、そのサービスのデプロイが行われない状態になっていました。

f:id:quipper-ja:20190329191909p:plain

通常のフローでは参照不能にはならないのですが、リリーステスト環境でしか試せない操作があり、本番デプロイはしないが試したいというケースがありました。これは、一部 Quipper 外部の環境については PR 単位で用意することが困難だったためです。また、さらに偶然、リリーステスト環境に入れた後に手直しした内容が必要だったため、その変更を cherry pick して release ブランチに適用していました。これにより、その翌週リリーステスト環境の作成時に release ブランチを作り直した際、cherry pick した内容と同等の内容は develop ブランチに存在するもののコミットリビジョンが異なるものが最終デプロイリビジョンとして記録されていたため、差分の検出に失敗してデプロイがされない状態になってしまいました。

幸いにしてリリーステスト中に修正したはずの内容が入っていないことなどからこの問題が発覚し、取り急ぎデプロイスクリプトの修正を行いました。

本番には出さないがリリーステスト環境で試したいというケースは稀ではあるものの、現状の流れを踏まえると、release ブランチは develop ブランチをマージする、という流れでもいいかもしれません。

終わりに

ある程度時間をかけて全体に対して手動テストを挟むようなリリースの流れを取る場合には、コードフリーズが必要になるためこのような Git 戦略との相性がいいです。

ただ、週1デプロイしかできないのは都合が悪い点も多く1、可能なら頻度は上げたいものです。 分断されたモノリスを monorepo に寄せたことによって普通のモノリスとしてテストしやすくなっているので、アプリケーションを跨いだテストを足していって周期をもっと早めるのが今後の課題です。


  1. デプロイせずとも任意のタイミングでリリースする Darklaunch について Rails DM 2019 で @ujihisa が発表しています https://speakerdeck.com/ujihisa/almost-microservices

Quipper、外から見るか?中から見るか?

2018 年 10 月に入社した Web Engineer の @yskttm です。
今回は Quipper(東京オフィス) の文化について感じた事を正直に紹介したいと思います。

私にとって Quipper への入社は初めての転職でした。
前職も Quipper と同様 Web サービスを提供している会社にいました。
今回の記事は同じような境遇にいる転職を考えている人や、Quipper に興味はあるが社内の雰囲気はどうなっているんだろう…、と思っている方に読んでいただければ幸いです。

良いなと感じた点

まずは、こういう部分が良いな、働きやすいな、と感じた点について記載します。

組織のフラットさ

転職活動中に話題にあがりやすい事柄の一つに"組織のフラットさ"があると思います。
おおかたの会社は "フラットです" と説明を受けるが、知り合いでもいない限り本音を聞くことは難しいです。
Quipper では役職が上位の人間にも Slack や口頭でカジュアルに話し、冗談も言い合っている姿を見ると役職による壁を感じることが少ないです。
また、事業の方針にも全員が素直に意見を述べるなど、随所でフラットさを感じることができています。
Web業界なら一般的なことかもしれませんが私にとっては非常に新鮮な気持ちでした。
文字で伝えるのは難しいので、ぜひオフィスに遊びに来てほしいです。

心理的安全性

入社後、"心理的安全性" という言葉をよく耳にするようになりました。
組織のフラットさにもつながるが、「落ち着いて開発できる」この言葉に尽きると思います。
私から見ると技術レベルが高い組織に見えたため、 個人でタスクを集中的に進めていて、助けを求めるのが億劫になると思っていたが、全く逆でした。
発言に対して必ずリアクションが来るし、決して批判ではなく意見を話し合うことができています。
納期が短すぎて心に余裕が無いという状況も少ないです。緊張感がない組織も不健全ではあるが、そのバランスを上手く取れているように思います。

採用

試用期間が終わると、採用に関する情報が公開されます。
どういった方が受験されているのか、今後の採用方針をどうするか、皆で意見を出し合い一緒に働く仲間を探しています。
全員で組織を作っていこう、という気持ちが見える一面です。

リモート

リモート制度を導入していて、多くのメンバーが活用しています。
リモート制度の文化が浸透していることから、リモート者がいる前提の開発組織になっていると感じています。
オフィスでなくても問題なく作業が出来る工夫として、資料が外部から閲覧できる(無駄な制限が無い)、開発に必要な情報やツールもオフィス外から利用できるようにしています。

改善の余地があると感じた点

次に、これから改善できる余地があると感じた点について記載します。

時間に対する意識

ミーティングの終わりに対する時間の意識がすこし弱いと感じました。
決められた時間内で終わらすための準備や、ミーティング中の振る舞いに改善できる部分があると感じています。
決めた時間で終われる文化を作るため、改善点を探していきたいと思っています。

オンボーディング

自力で進めるには情報がやや少なく、新規入社者に対する案内やフローがあいまいな点が見られます。
事業が大きくなりメンバーが増えるにつれ、まとまったオンボーディングを準備しておくと新規入社者が迷子になりづらく、 なるべく早く本来のパフォーマンスを発揮できると考えています。

入社前後での違い

最後に入社前後で良い意味でも悪い意味でもギャップに感じた点を記載します。

グローバル感

入社前はグローバル色が濃いと感じていました。
しかし、日本向けのスタディサプリを開発する上では、あまりそれを感じることがありません。

GitHub や Slack 上で英語を使う場面はありますし、コード上でグローバルを意識して開発する必要はあります。
日本人以外のメンバーもたくさん所属しているため、英語で議論されていることを毎日見ています。
所属するチームや担当プロジェクトによって大きく異なりますが、私の立場では上記の印象です。

開発フロー

入社前は QCD が高い開発フローが固まっているのでではないか、と想像していました。
実際は、担当するプロジェクト、リソース状況によってフレキシブルに変えていると感じています。
前職ではウォーターフォール開発に近く、順序がきちんと決まったフローだったため、プロジェクトによる差分が小さく迷うことが少い状況でした。
事業の規模やフェーズ、チームによって変わるため、最適な手法を見極めていきたいと思いました。

最後に

今回は個人的な視点で感じたことを正直に書きました。
必ずしも正解があるものでも無いし、事業の成長とともにみんなで文化を作っている部分が楽しいと感じています。

最後に、"入社間もない人間が偉そうに改善点を声に出せる文化が最高です"、ということを伝えられればと思います。