2018の7日目の投稿です。昨日は、Androidエンジニアのkenzoが「Androidにいい感じの動きをさせていく話(ViewPagerとその他Viewとの連動)」というタイトルで投稿しました。Android開発を行っている方はぜひチェックしてみてください。今回は、delyが運営しているレシピ動画サービス「kurashiru(クラシル)」のiOSアプリがどのようなフローを経てストアに公開されているかをざっくりとご紹介したいと思います。この内容が、同じようなチーム規模の会社の方やこれからリリースフローなどを確立していくフェーズの方々などの参考になれば幸いです。dely開発部のチーム体制クラシルは現在アプリダウンロード数が両OSで1400万を超える規模のサービスですが、iOSチームは現在2人体制で開発を行っています。この人数だと当然リソースが潤沢と言える状況ではないため、何をどのように行うかがとても重要です。delyの開発チームにとって最も重要なことはユーザに本質的な価値を提供するサービスを作ることです。そのためにはスピード感をもって開発を進めることや施策の最適な優先順位決め、プロダクトの品質を保つための仕組みづくりなどの点に特に考慮する必要があると思っています。スクラム開発クラシルの開発チームは半年ほど前から1週間を1スプリントとしたスクラム開発を行っています。施策立案からリリースまでの全体の流れスプリント計画会まず、スプリントの始まりには計画会を開いています。ここで、今デザインフェーズにあるものと実装フェーズにある施策をそれぞれ確認し、そのスプリントで必要な要件定義・デザイン・実装のタスクの洗い出しと担当の割り振り、工数見積もりを行います。デザインフェーズUIデザイン、プロトタイピング実装、インタビューなどのサイクルを回します。PM奥原のこちらのスライドをご覧いただくと分かりやすいと思いますが、ここで重視しているのはきちんとユーザーに使われるものをリリースするための仕組みです。実装フェーズデザインフェーズが完了すると、プロトタイピングを行ったエンジニアやデザイナーが開発仕様書を作成します。弊社ではドキュメントの共有にQiita:Teamを活用しているため、仕様書もQiita:Teamを使って書きます。Sketchで作成されたUIもZeplinで共有されます。実装フェーズの実装者は「開発仕様書」「Zeplin上のUIデザイン」「プロトタイプ」を確認しながら、アプリの実装を進めます。デザインフェーズで実装されたプロトタイプは基本的にはリリースするアプリには含まない方針で作られているものなので、ここではプロトタイプのコードは使用せずに新しくコードを書いていきます。(プロトタイピング段階でプロダクトコードレベルで作り込まれたUIコンポーネントなどはそのまま使用することがあります。月:リリースiOSチームは1スプリント(1週間)をざっくりとこのような形で動いています。スプリントの開始が水曜日になっているのは、iOSの審査のタイミングを考慮してこの形が理想だろうと考えた結果です。ここまできっちりとスケジュールを決めている理由は、実装後のデバッグや修正の時間をきちんと確保し、少ないリソースでもプロダクトの品質を確保できるような仕組みづくりが必要だったからです。スケジュールを固定にしていなかった頃は、少し無理な実装スケジュールでも直前に割り込みで対応したりなどして、リリース前の検証が疎かになったり審査提出予定日のギリギリまでエンジニアが頑張るなどという問題が起きていました。Gitのブランチ運用/masterAppStoreで配信しているアプリと同じ状態/develop次のリリースで配信されるもの/feature何らかの新しい機能を実装をするためのブランチ(developから派生)/improvement新機能ではないがユーザが見て分かる改善を行うためのブランチ(developから派生)/fixバグ・不具合の修正を行うためのブランチ(developから派生)/refactorリファクタリングを行うためのブランチ(developから派生)/otherCI/CDやライブラリなどのツールに関する修正やアップデートを行うためのブランチ(developから派生)/release/v.◯.◯.◯スプリントが終わった段階で次のアップデートでリリースされるバージョン/hotfixreleaseブランチを作成してから不具合などの緊急度の高い修正必要になった場合に修正を行うためのブランチ(releaseから派生)Gitのブランチは現在上記のような運用を行っています。flowに近いと思います。開発作業用のブランチを5種類に分けているのは、ブランチの名前だけでどういう変更が含まれたものかはっきりさせるために分けています。この名称と同じタグをプルリクに設定してそこからCHANGELOGに追記されるようにしているため、その部分とも連動しています。それぞれマージこの運用方式にしてから半年以上が経過していますが、今は特に問題なく運用ができています。以前は様々なタイミングで緊急の修正を行った際などのフローが不明確だったことなどがあり、何度かコミュニケーションが発生したりコンフリクトの修正が必要になったりと無駄な時間が発生してしまうことがありました。デバッグreleaseブランチを作成したら、社内のメンバーにデバッグをしてもらうためにDeployGateでアプリの配布を行います。DeployGateでの配布にはSlack、fastlane、Bitriseなどを活用して作業を自動化してあります。ここでは次にリリースをするバージョンの変更箇所を中心に確認します。バグや不具合などの問題以外でも少し気になったことなどもよく報告されることがあります。リリースデバッグとhotfixの修正が全て完了したら、審査に提出します。審査通過後は、プロモーションコードをSlackで配布し、社内のメンバーにも最終確認を行ってもらいます。ここで問題が見つからなければそのままリリースを行います。リリース後リリースした後は、まずはログの確認やデバッグ時に見つからなかったクラッシュ、バグの確認を行います。必要に応じてiOSエンジニアもSQLを書いてデータ分析を行い、分析結果をもとにさらなる改善をしていきます。おわりに以上がクラシルのiOS開発からリリースまでの大まかな流れです。この記事で紹介した仕組みは全てこの1年以内に確立したものです。弊社の開発チームはまだまだ歴史も浅く、メンバーも少ない少数精鋭チームですが、プロダクトを第一に考えて柔軟に仕組み作りを行っています。機会があれば、もう少し深掘りした説明もどこかでしようかと思います。弊社では、プロダクト志向でクラシルの開発ができるiOSエンジニアを募集しています。「jQueryへの依存を外す方法」というタイトルで投稿します。dely株式会社サーバーサイドチームの安尾です。Inc.でプロダクトマネージャー兼開発部ジェ...2018-12-06Androidにいい感じの動きをさせていく話(ViewPagerとその他Viewとの連動)こんにちは。delyでAndroidのエンジニアをしているkenzoです。CI環...こんにちは。Androidエンジニアのうめもりです。月別アーカイブはてなブログをはじめよう!delyjpさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。