はじめまして、LINE技術戦略室のhayaishiです。
趣味は自転車と言っていますが最近は全く乗っていません。
この記事では、LINEのiOSアプリ開発に関することをいくつかご紹介させていただこうと思います。

LINEのiOSアプリ開発環境

ソースコード管理

ソースコードはgitで管理しています。gitのリポジトリブラウザとしてGithub Enterpriseを利用しており、Githubでお馴染みのPull Requestなどを活用して開発を進めています。
また、LINEのiOSアプリのタスクについてはGithub Enterpriseとは別のチケット管理システムを利用しておりそちらのステータスと連携して開発者、QA、プランナー間の開発状況の共有を行っています。

Gitでの開発フローについて

LINEのiOSアプリはgithub-flowの様に一つの常にdeploy可能なmasterを持つというよりは
常にdeploy可能なバージョン毎のmasterを持っているという形で運用しています。

それぞれがリリース可能なブランチで、開発状況によっては下位のバージョンのコミットが上位のバージョンのコミットよりも新しい場合があります。
LINEのiOSアプリではバージョン毎に提供する機能や修正を決めていて、QA対象の切り分けがしやすいなどのメリットもあり、一つのmasterにcommitを繋げていく形では運用していません。
現在開発中の最も下位のバージョンの修正がリリースされたら、そのブランチを上位のブランチにマージして下位のブランチを消していきます。
上位のバージョンの機能を下位のバージョンに取り込むなどの作業を行うこともありますが今のところ問題なく運用できています。
元々はgit-flowで開発していたのですが現在はこの方法に落ち着いています。

開発時の環境について

アプリが利用するAPIについては以下の名称で開発環境を切り分けています。

環境	説明
Dev/BETA	本番とは異なる開発用のDBを参照する環境
RC	本番と同じDBを参照するリリース前の確認用の環境

開発時は本番と異なる環境にアクセスすることで思わぬ事故が起こらないようにしています。

iOSのライブラリ管理

ライブラリは主に2つの方法で管理しています。

CocoaPods

CocoaPodsによるiOSアプリのライブラリ管理は現在のiOSアプリ開発の主流になっているのではないでしょうか。
我々も内製ライブラリや、外部ライブラリの管理をCocoaPodsを使って行っています。
内製ライブラリについては社内のgitリポジトリで管理しておりそちらを参照しています。

.gitmodule

LINEアプリではgitのsubmoduleも利用しています。
以前はpod updateがgit submodule updateに比べて遅く、こちらを利用していました。
また、submoduleを修正した際に差分の確認も容易というメリットもあります。
内製のライブラリでLINEアプリの開発と平行しているものもありこちらの方が便利だったりします。

Configuration & Scheme

LINEアプリでは開発時の環境とリリース時の環境を分けておりそれぞれ異なる設定をしています。
APP_IDENTIFIER、BUNDLE_DISPLAYNAME、GCC_PREPROCESSOR_DEFINITIONSといったものです。
LINEアプリではこれらの設定をxcconfigファイルを用いて管理しています。

複数のxcconfigファイル

複数のConfigurations設定

Base.xcconfig ファイルに共通の設定を記述し、環境毎のファイルで必要な項目を上書きしています。Xcode上のプロジェクト設定に比べて可読性も高いためこの方法を採用しています。

LINEアプリではこれらの環境に応じたSchemeを用意してビルド時に切り替えています。

Archive Post actions

LINE株式会社の開発者は、アプリを実機に転送したい場合に社内向けのテストアプリ配布サービスを利用することができます。
LINEのiOSアプリも社内向けアプリ配布サービスを利用しており、この配布サービスへのアップロードを簡略化するためにArchive時のPost-actionsでアップロード用のスクリプトを設定しています。

このスクリプトではビルドを実行している環境から、ビルドしたユーザの名前、ブランチ名、commit、tagなどを取得しビルドに関する情報をファイルとして作成します。
ipaファイルもこのタイミングで作成し合わせてアップロードしています。

次は開発の流れについて紹介したいと思います。

---

LINE iOSアプリのワークフロー

開発開始

各エンジニアは中央リポジトリをforkして自分のローカルにcloneします。
開発用のfeatureブランチを自分が機能を追加するバージョンのブランチからcheckoutします。

Pull Requestを出す

開発を進めて確認して欲しい段階まで進んだらPull Requestを出します。
WIP(work in progress)で出すことももちろん可能です。
他のユーザに、mergeしてもらう為のレビューをしてもらいたくなったタイミングで
チケットのステータスを ALPHA Deployed に変更します。
これで、このチケットの修正がレビューに出されたことが分かります。

Pull Requestがmergeされる

レビューが終わり、Pull Requestがマージされたらチケットのステータスを
ALPHA Confirmed に変更します。
これで、この修正がBETAアプリとしてリリース可能な状態になりました。

BETA環境で開発した機能が利用可能になる

BETAビルドがリリースされ開発者、テスター、企画者がダウンロード可能な状態になったら
チケットのステータスを BETA Deployed に変更します。
これでこの修正がすでにBETAビルドとして利用可能なことがQAや企画者に伝わります。

QAチェックを経てRC環境で開発した機能が利用可能になる

BETAビルドのQAチェックが完了し、本番と同じDBを参照したRC環境のアプリがダウンロード可能になるとチケットのステータスが BETA Confirmed に変更されます。
この修正がすでにRC環境にあることがわかるようになります。

チケットのフローについて

このように新機能や修正を管理するチケットは開発状況に応じてステータスが変わっていきます。
こうすることで細かい開発状況を伝えなくても現在の状況を共有することが可能になっています。

ステータス	説明
Open	開発開始
Alpha Deployed	コードレビューを依頼した
Alpha Confirmed	コードレビューが完了しmergeされた
Beta Deployed	対象の修正が反映されたビルドがBETA環境で利用できるようになった
Beta Confirmed	対象の修正がQAチェックを経てRC環境で利用できるようになった
Closed	対象の修正がストアなどでリリースされた

---

LINE SCV BOT

LINEのアプリは基本的にJenkinsでビルドしたものを社内のアプリ配布ツールにアップロードし
その配布ツールからテスターや開発者がダウンロードするという流れになっています。
しかし、Jenkinsはアプリビルド用の証明書等が置いてある等の関係でLINEのクライアント開発者以外がアクセスすることは出来なくなっています。

しかし、BETA環境リリース待ちのアプリのQA等を行いたい場合にテスターはわざわざ開発者にJenkinsでのビルドをお願いする必要はありません。
LINEのクライアントアプリは LINE SCV と呼ばれるビルドBotを利用することで非開発者でも
LINEアプリ上から対話的にJenkinsでビルドを行うことが可能になっています。
(もちろんビルドが失敗した時は開発者が対応します)

この LINE SCV BOT のおかげでチケットのステータスを確認するだけでテスターは最新の修正をいつでもBuildしダウンロードすることが可能になります。

LINE公式アカウント

余談ですが、LINE SCVはLINEの公式アカウントの自動返信に利用する仕組みを利用しています。
ユーザからの入力を公式アカウントのWeb hookを使って取得し、その内容に応じたコマンドを実行します。

Jenkinsは $ curl -v {$JENKINS_URL}/job/{$JOB_NAME}/build?token={$TOKEN} のような形での
リモートビルドが可能なのでLINE SCVはユーザのリクエストを元に上記の様なリクエストを送っています。

ビルドBOTで使えるコマンド

LINE SCVでは以下のコマンドが利用できます。
コマンドはLINEのトークでメッセージとして送信するだけです。

コマンド	説明
help	ヘルプを表示します
jobs	ビルド可能なJobの名前一覧を表示します
build (job name)	指定したJobをビルドします
queue	現在ビルド待ちのJobの一覧を表示します

build (job name) というメッセージをLINE SCVに送るだけで対応するbranchの最新のコードがビルドされアプリダウンロード用の社内向けテストアプリ配布ツールにuploadされます。
その後、LINE SCVを登録しているすべての開発者、テスターにLINE上のメッセージとしてアップロードされたことが通知されます。

Jenkinsでビルドされたバイナリはそのまま社内向のアプリ配布ツールにアップロードされているので、通知内容にあるURLから直接ダウンロードページへ遷移することが可能です。
このようなフローになっている為、テスターは開発者に頼まなくてもチケットの解決状況などを見ながら最新のビルドを取得することができるようになっています。

おわり

いかがでしたでしょうか。LINEは2011年にリリースされた歴史の長いアプリです。
試行錯誤して現在はこのような形に落ち着いていますが、まだまだ変化していくと思います。

Link

CocoaPods : http://cocoapods.org/
git flow : http://nvie.com/posts/a-successful-git-branching-model/
github flow : http://scottchacon.com/2011/08/31/github-flow.html

Click here to read in English

LINE株式会社ではスマートフォン開発エンジニアを募集しています。私たちと一緒にプラットフォーム・グローバル展開を発展させていきたい方は是非ご応募ください。エントリーはこちら