DEV Community: Wataru Nishimoto

朝 6 時から働く超朝型エンジニアの一日 #Zaim

Wataru Nishimoto — Wed, 10 Oct 2018 23:44:59 +0000

おはようございます。Zaim で iOS アプリ開発をしている watura です。今日は私の一癖ある働き方について紹介していきたいと思います。

Zaim では、始業時間をある範囲で自由に決められる制度があります。 5 時から 10 時の間に業務を開始し、そこから 8 時間の勤務と 1 時間の休憩を入れる という勤務体系です。まるでフレックス制度のようですが、勤務時間自体は固定なのでフレックスではありません。

以下、よく聞かれる質問に回答していきます。

6 時から働いたら何時まで仕事なの？

15 時です。

仕事終わった後は何をしているの？

ジムに行って筋トレしたり、手ごねパンを焼いたりしています。

16 時台や 17 時台はジムが割と空いている時間なので、いつも非常に快適に筋トレに励むことができています。

ただ、スタジオ系はあまりないので、黙々と筋トレするか、トレッドミルとかで有酸素に励むということしかできていないです。まあ、筋トレが楽しいのでスタジオには参加しなくてもいいかなとも思っています。

いつも何時に寝ているの？

22 時には寝るようにしています。

いつも何時に起きているの？

4〜5 時台です。

飲み会とかどうしているの？15 時以降、暇じゃない？

多くの場合、ジムに行ってカロリーを消費してから飲み会に行きます。

会社の飲み会であれば渋谷近辺になることが多いので、会社近辺のジムに行って、筋トレをし、お風呂に入ってから、オフィスに戻り、飲み会の時間まで待機しています。勉強会とかに参加する場合も、ジムに行ってから参加するというのが多いですね。

飲み会の次の日はゆっくり出社するの？

基本的にしないです。制度的には、次の日にゆっくり出社するという選択は可能です。

それだと起きるの大変じゃないの？

超眠くて大変ですが、気合いと根性、カフェインの力で頑張っています。

そんなに早く帰ってミーティングとか大丈夫なの？

念のため、Google カレンダーで 15 時半以降は私は勤務時間外ですって出るように設定しています。ありがたいことに、ある程度まわりの方も考慮してくれるので助かります。

この早朝制度を利用すると、最大で 14 時に勤務終了となります。つまり、ほぼ半休をとったのと等しい時間に勤務が終了します。そこから旅行に行くと、夜から出発や有給を利用して出発に比べて圧倒的に効率よく時間が使えるようになります。

Bitrise と fastlane で作る高速 CI/CD 環境 #Zaim

Wataru Nishimoto — Tue, 02 Oct 2018 23:58:18 +0000

お元気ですか。Zaim の iOS エンジニアの watura です。

今日は、Zaim の iOS 版アプリの開発において CI（Continuous Integration：継続的インテグレーション）および CD（Continuous Delivery：継続的デリバリ）のシステムをどう構築し、活用しているのかを書いていきます。

まずは CI からです。現在、Zaim の iOS 開発では Bitrise と fastlane を中心に、一部 Jenkins を利用しています。

Bitrise - Mobile Continuous Integration and Delivery

かつての Jenkins CI 環境にあった三つの課題

Bitrise を採用する以前は、LAN 内にある MacBook Air にインストールした Jenkins だけで CI 環境を構築していました。しかしながら、これには以下のような課題がありました。

端末のメンテナンスが面倒
パフォーマンスが悪い
外部からアクセスできないため Github などから hook できない

Bitrise 採用の決め手はマルチプラットフォームの料金

これらを解決するには、SaaS として使える CI ツールが必要だと判断し、いくつかを比較したところ、Bitrise と CircleCI が最終候補に残りました。

機能や使いやすさはどちらも同じくらい充実していたものの、最後の決め手は料金体系でした。

Zaim は iOS 版以外にも Android 版や Web 版が存在します。このため、プラットフォームとしては、いずれ Mac 以外の CI ツールを使うことを想定していました。CircleCI は Mac と Linux で料金が分かれていて別々に契約が必要ですが、Bitrise は同一契約内で済むようになっています。コスト面や管理面でのメリットが大きいとして、Bitrise を選択しました。

今であれば、マイクロソフトが今年の春頃にリリースした Visual Studio App Center を採用するのも手かもしれません。

Bitrise＋fastlane（＋Jenkins）に任せている四つの作業

iOS の CI および CD 作業全体としては、上記のようにして採用した Bitrise を使っています。

Bitrise にはさまざまなアクションを自動化する公式ステップがあり、ほとんどすべての作業は公式ステップの組み合わせで実現できます。ですが、 Bitrise にロックインされ、今後よりよいサービスが出てきた時に乗り換えられないという事態を避けたいと考えているため、基本的にはこうしたフローの制御は fastlane を使って実現するようにしています。
そして実は、Jenkins で実行している箇所も一つだけまだ残っています。早く引退してほしいのですが、まだまだ現役です。

これらのツールを組み合わせて、以下の作業を自動化しています。

Danger の実行
テストの実行
DeployGate への配信
App Store へのアップロード

（１）Danger の実行

Pull Request の簡易チェックツールである Danger を使って、Pull Request の一次確認を実行しています。

Danger は旧 CI マシンである Jenkins から起動しています。 Jenkins である理由は、「Pull Request の本文やタイトルに変更があった場合、そのコメント欄に "danger please" と書き込むことで、Danger に再チェックしてもらいたい。これは、今のところ Bitrise ではできない」という事情があります。

例えば Zaim の iOS 版では「Pull Request のタイトルに必ず呼応する issue 番号を入れる」という内部ルールがあるものの、これは忘れてしまいがちです。やらかすと、Danger から以下のように怒られます。

タイトルを修正して即 Danger が再実行できればよいのですが、Bitrise でやろうとすると、空のコミットをプッシュする必要があります。Jenkins を使えば、コメント欄に「danger please」と記述するだけ。

Danger が動き出し、LGTM になります。明らかに便利です。

Github のコメントが Bitrise のトリガーになる方法があれば、Danger も Bitrise にしちゃいたいと思っています。

（２）テストの実行

次はテストです。Unit Test と UI Test を、Bitrise で実行しています。トリガーは Pull Request と develop ブランチの更新です。

これらのテストの実行には、fastlane scan を使っています。ちなみに、Bitrise のような、シミュレータの画面が見えない環境でも UI テストは動かせます。

（３）DeployGate への配信

ここからは CD の話です。まずは、本番にアップロードする前のテスト用アプリをどう社内に配布しているかについて説明します。Zaim では DeployGate を使っており、主に 3 種類のアプリを配信しています。

Hourly：develop ブランチを更新するごとに配信
Beta：1 日に 1 回 develop ブランチを配信
Inspect：引数などで指定した特定のブランチやコミットを配信

（４）App Store へのアップロード

社内テストだけではなく、本番用の申請作業も簡単にしたいですよね。Zaim で App Store へのアップロードをツール経由でできるようにしたのは、ごく最近の 2018 年の 9 月からです。全体のフローがシンプルになって、めちゃくちゃ楽になりました。

以前のリリース作業は、

Jenkins で App Store 用にビルドする
ローカルにビルドされたアーカイブをダウンロードする
Xcode でアーカイブを開き、App Store Connect にアップロードする
リリースノートなどの各種メタデータを手動で書き込む
iTunes Connect に申請する

という手順でした。それぞれは大変な作業ではありません。ただ、あいだに待ち時間があるため、途中までやって忘れてしまうことが多々ありました。

これを Bitrise 経由にすると、

リポジトリ内にある各種メタデータを更新する
Bitrise で App Store 用の Workflow を実行する
iTunes Connect に申請する

という作業でリリースできるようになりました。時間がかかるのは「Bitrise で Workflow を実行」の待ち時間のみで、あとはすぐに完了します。また、App Store へアップロードが終わると App Store Connect からメールが届くため、まだか、まだかと Bitrise の画面を見る必要もありません。

また、事前準備として、リリースノートやアプリの詳細といったメタデータも Github で管理できるようになるようになりました。

とはいえ、そもそも DeployGate への配信や、App Store へのアップロードの管理は、CI を使おうが直接 Xcode でやろうが全体で見ると面倒な作業が多くありますし、権限管理も複雑になります。例えば、証明書や Provisioning Profile は Xcode に任せるのか、開発メンバーや CI で共通のものを作成するのか、それともそれぞれが作って管理するのか。Developer Portal へのアクセス権限はどれくらい必要なのかなど、考えなければならないことが多々あります。

Zaim では、こうした部分も fastlane を使ってシンプルに管理できるようにしています。この詳細については別記事で、まとめていきたいと思います。

さらなる CI/CD 環境の改善を目指したい

一連の流れで、かなり CI/CD は充実してきましたが、まだまだよくしたいと考えています。例えば、以下のようなことです。

Bitrise の Workflow を Slack から楽に呼び出せるようにする
任意のブランチ、コミットを簡単にデプロイできるようにする
ライブラリを自動アップデートできるようにする

こうした改善により、開発作業にさらに多くの時間を割けるようにして、効率的かつメンバーにとって心地よい環境を作っていきたいと思います。

What I learned from 12/02 bug

Wataru Nishimoto — Tue, 05 Dec 2017 10:41:43 +0000

Does anybody know this bug? Date Bug in iOS 11.1.2 Causing Crash Loop on iPhones as December 2 Hits [Updated].

Because of timezone at Japan this bug heavily affected to many people. Our company affected, too. Perhaps our app could be the most affected app in the world.
Because there are about 7 million downloads and it uses notifications by the default.

The 🙌guy who made demo project of this bug is co-worker.

What I Did

At 6:30 am(UTC+9) I noticed that our app crashes a lot and become trend of twitter, but at crashlytics there aren't any new crashes caught. Off course firebase crash does not know any new crashes either.

So I started search on twitter and I found that there are a bug that somehow made by our app. It was unbelievable, how I could make iOS crash by a app which works with any problem until yesterday.

At first everybody saids that notification is problem, but there are push notification and local notification. Our app uses both notification methods so I try to find which notification causes this bug.

Check device token error logs.
stop taking device token

Still being this bug. Any clues founded.

There are few accounts I use for development. And there is a account does not cause this bug. I started to take diff of that account and other account.

In our app user can chose a day for repeat notification. That account was set to 25th. Other account was 1st.
So I changed it to 25th to 1st. I hit bug. This parameter makes bug and this parameter is used only in local notification. So the problem is in local notification or our code to use local notification.

Edit code, compile, run and test. Edit code, compile, run and test. Edit code, compile, run and test. I tried so many times.

If you are swift developer, probably knows that compile takes plenty of time and while compiling Xcode become stupid. It takes time and staminas.
The 🙌Guy made a small demo project that hit this bug. This project is very small and very fast compile. So we could debug very faster.

Here is one what I learned from this bug.

1. Make demo project

If 🙌Guy didn't make demo project we couldn't determine this bug at this quality (Japanese only).
In this post we tried to describe what happened to iOS. There are more detail and guesses which did not write in this post.
ex) this bug is not only for 2017. not only 12/2.
These results are found because of fast compile and debug.

2. Tell to the apple in English

Who made iOS? Apple.
Apple uses English for default language.
If we find a bug. We need to tell apple in English.
probably radder has many rubbish bug reports. So we need to take attention from apple. But how?

3. Tell the world (twitter) in English

So did we act well? No. We didn't tell the world in English. Only Japanese.

I believe there will not have these kind of huge bug. But if I hit the bug. I will make small demo project and announce it in English.

If you want know about this more deeply you could read this blog (Japanese).

Only Apple Could know truth. we could do only guess.