はじめに
はじめまして。モバイルチームリーダーのAndroidエンジニアの齊藤です。
2019年10月にPhotoructionに入社し、現在で2年4ヶ月経ちました。
元々はSES会社に勤めていて、様々な企業に常駐でAndroidを中心にWebやサーバサイド等の開発をしていました。
Photoructionに入社した時点ではAndroidエンジニアが自分一人でした。
当初Android版Photoructionの開発は開発未経験の方が行い、その後業務委託やオフショアの方が機能開発・不具合修正・リリースを担当していました。そのため、開発基盤に特にルールが存在しない状態で、入社後に行ったのは開発環境や運用の変更でした。
今回はその時のことを振り返っていきたいと思います。
git-flowの導入
入社前の運用と問題点
Photoructionではバージョン管理にGitを使用していましたが、Androidチームでは特にgitの運用方法が決まっていたわけではありませんでした。
master, devブランチの他、エンジニアの名前ブランチフォルダだったり、バージョン別のブランチだったりと自由な運用がされていたため、どのブランチがどの内容なのか判断しづらい状況でした。
改善内容
そのため以下のようなgit-flowで管理することで、それぞれのブランチの役目を決めました。
master : プロジェクトの親ブランチで、リリース済みの最新ソースとなる。
develop : 開発用ブランチ。プロテクト対象で直Pushはできない。featureブランチのbaseとなり、featureの機能をマージすることで更新する。
feature : 機能開発用ブランチ。developからの作成が中心で、developに対して、機能を追加していくためのブランチ。「feature/xxxx」という形で、xxxxには機能に対する意味あるIDで管理する。
release : リリース用ブランチ。通常のリリースフローのためのブランチで、リリース可能な段階になったdevelopから作成される。「release/1.2.3」とリリースするバージョン名で管理する。
hotfix : 緊急不具合対応ブランチ。問題のあるリリース中のソースが存在するmasterブランチから作成される。「hotfix/1.2.4」とリリースするバージョン名で管理する。
社内だけではなく、業務委託の方やオフショアに対しても説明を行い、運用の徹底をしました。
featureブランチ名は、当時Trelloでタスク管理をしていたので、feature/dev-{カードID}で運用をするようにしました。
※現在はタスク管理をBacklogやgithub issueで行っているためそれぞれのissueIDをブランチ名として利用しています。
deploygate対応
入社前の運用と問題点
元々社内の開発中及びリリース対象アプリの社内配布(テスト用)は、GoogleDriveにアップロードし、Android端末でダウンロードを行い、APKファイルからインストールする方法を取っていたため、端末によってインストールまでの操作が異なっているなど、手間が掛かり社内配信のハードルを感じました。
また、productFlavorsは接続先環境を切り替えるためにproduction, dev, alphaの3件存在しましたが、applicationIdSuffixが特に設定されていなかったため、一つの端末にインストールできるアプリが一つのみで、そのアプリがリリース用なのか開発中のものなのかを判断することが難しい状態でした。
改善内容
deploygateへの移行をしました。配布も簡単で、アプリさえ入れておけば社内端末で好きなバージョンのアプリを入れることができるためです。
テスターさんとのやりとりも、「dev#123で確認お願いします」と伝え易くなり、テスターさん以外の社内のメンバーにも気軽に開発中のアプリを触ってもらえるようになったと思います。
また、applicationIdSuffixが特に設定されていなかったのでdevとalphaに対して設定しました。
applicationIdSuffixを設定したことにより、それぞれが別のpackageNameになり、deploygateで同じアプリを環境違いでアップすることができ、一つの端末に環境別のアプリをインストールすることができるようになりました。
また、端末に環境別アプリがインストールできるようになったことで、どのアプリがリリース用・開発用かをわかりやすくするため、アプリのアイコンの色を変更しました。
現在は会社やプロダクトのロゴが変更になったことにより、新アイコンになっています。
アプリケーションのビルド
入社前の運用と問題点
アプリのビルドは、Android開発者がいなかったためオフショア側でビルドしたものを受け取り、それを配信する形を取っていたようです。社内にAndroidエンジニアがいなかったため、社内でビルドができていませんでした。
改善内容
配信方法がdeploygateになったこともあり、社内でアプリビルドが簡単にできるようにshellを作りました。
現在では、fastlaneで現在の開発ブランチのアプリを作成しdeploygateへアップロードしたり、github actionsで特定のPRコメントによってアプリをビルドしてdeploygateへアップロードする方法も運用しています。PRコメントでビルドする方法は、エンジニアだけでなく開発環境のないQAエンジニアも任意のタイミングでビルドしてアップすることができるので非常に便利になりました。
公開範囲の拡大と多言語対応
Photoructionは海外の建設現場での使用を考慮することが必要で、特にAndroid端末はiOSよりも海外でのシェアが高いので、重要なアプリとなります。
入社前の運用と問題点
公開範囲設定が2-3カ国しか設定されておらず、実際に利用される予定の地域が入っていなかったりと適切ではありませんでした。
また、海外での利用を考慮すると多言語対応も必要になりますが、アプリは日本語文言が全てstrings.xmlで管理されておらず、ソースコード内にハードコーディングされているものも多々ありました。
改善内容
公開範囲の拡大を行い、ハードコーディングされた日本語文言のstrings.xmlへの移行と多言語対応用のリストアップも行いました。
現在対応している言語は、日本語・英語・インドネシア語・ベトナム語・中国語（繁体・簡体）です。
まとめ
入社直後は、Android版の開発環境がとても良いとは言えない状態だったため、最低限の形に直していきました。
Photoruction入社前に担当していた大手企業のアプリでも同じような状態だったこともあったので、Android版のリポジトリを見た時は特にガッカリしたとかはなく、そんなものだよね。という感じでした。
その後、メンバーが増えたり、豊富な知識を持った業務委託の方のご協力のもと徐々にAndroidの開発環境も良くなってきています。
他にも初期の頃にまともに動作しない不具合もありましたが、その話は次回以降お話したいと思います。今回はこのような記事でしたが、今後はもう少し技術寄りの記事にしたいです。
最後に
2021年のアドベントカレンダーにAndroidチームの現在、そして今後のアーキテクチャについての記事がありますので、よろしければご覧ください。
株式会社フォトラクションでは一緒に働く仲間を募集しています
