iOSアプリ自動リリース：証明書編
どうもこんにちは.
VoicyのiOSエンジニア, mishima(@tihimsm)です.
前回投稿したfastlane/Bitrise編はBitriseJPN様に↓のようなリプライをいただきました.
しかもリツイートまでしていただき, 本当にありがたい限りでございます.
また更に, 前回と前々回の記事をBitriseJPN様の公式ブログに掲載していただきました!
前置きが長い男はモテないらしいので, そろそろ本題へ.
今回はiOS開発の中で鬼門と言える証明書について綴りたいと思います.
ちなみにみなさんはiOSの証明書について理解してますか?
ぜんぜんわからない
俺たちは雰囲気で証明書を使っている
と言う方けっこういると思うんです.
かく言う私はというと
完全に理解できたと言っていいのかわからない
という感じです.
要するに雰囲気で証明書を使っているわけですが, 本記事執筆以前の私よりは確実に詳しくなっているので, 数週間前の私に向けて書き綴っていこうと思います.
本記事では
・証明書とは?
・matchを使って証明書をチームで上手く管理する
ざっくりこんなお話をさせていただきます.
対象読者
- iOS証明書? 何それ美味しいの? って人
- iOS証明書を雰囲気で使っている人
- 開発チームで証明書を上手く管理したい人
- 証明書の煩雑な管理が辛すぎて夜も眠れない人
- この記事の不備やイケてない部分にFBをくれる人 ← 最重要
目次
- iOS証明書とは?
- 弊社が抱えていた証明書周りの問題点は?
- matchとは?
- 弊社の証明書環境
- 弊社のデプロイ環境
- matchによる証明書管理の効能
iOS証明書とは?
いきなりで非常に申し訳ありませんが, こちらに関しては参考リンクを貼るだけにさせていただきます笑
というのも, この記事にとてもよくまとまっております.
自分で書いたとしても, ほぼ同じ内容をコピペするだけみたいになってしまいそうなので, このような形にさせていただきました, ご容赦ください.
少しだけ簡単にまとめると証明書が3種類
- CSRファイル(CertificateSigningRequestファイル)
- 証明書ファイル(cerファイル)
- p12ファイル
そして, 上記証明書をまとめた
- ProvisioningProfile
この4種類でiOSの開発, 配信の権限を管理しているわけですね.
集団開発する時において, 何も考えずこいつらを管理し始めると大変なことになってしまうわけです.
弊社が抱えていた証明書周りの問題点は?
証明書周りにけっこう大きく問題抱えてて, このままでは今後立ち行かないなとずっと感じておりました.
- 開発チーム拡大に伴い, ディベロッパー登録がものすごく手間になることが予想された
開発規模拡大に伴い, iOSエンジニアリソースを一気に増やす必要がありました.
ここで問題になってくるのがディベロッパー登録です.
今後も開発者が新たに入ってくる度にディベロッパー登録するのは, 簡単ですがそこそこの手間です.
自分の精神が擦り減る可能性があると感じ, 早急に解決する必要がありました.
- AppStoreに配信する際, アプリのArchiveとストアプッシュを特定のAppleアカウントでのみ行なっていた
弊社では, AppStoreに配信する際, アプリケーションのArchive, ストアプッシュ(もしくはFabricへの配信)を特定のAppleアカウントのみで行なっていました.
なので, 自分のMacからストアプッシュを行う際には社用のAppleアカウントでログインすることを一々CTOにお願いしていました.
これらの問題を解決するのに使用するのが fastlane match です.
matchとは?
matchを使うと, 証明書やProvisioningProfileの作成, それらの暗号化をしてGithubリポジトリに保存, 復号化して取得を担ってくれる非常に優秀な子です.
matchの使い方を簡単に説明します
matchでの証明書管理はGithubの他に, GoogleCloudでもできるのですが, 今回はGithubの場合の説明をします.
ios-certificatesのような名前のprivateリポジトリをGithub上に作る.
※ 絶対にprivateで作ってください! 証明書は絶対に外に漏れてはなりません.- 証明書を管理したいアプリケーションのリポジトリで
$ fastlane match initする - GitリポジトリのURLを求められるので
ios-certificatesのURLを入力 $ fastlane match developmentで, リポジトリに証明書を保存$ fastlane match development --readonlyで証明書を取得
ざっくりこんな感じです.$ fastlane match developmentのdevelopment部分をappstoreや adhoc にすることで, 証明書の種類を指定できます.
弊社の証明書環境
先に完成図からお見せします.
Admin権限のある人がmatchを使って全社で使用する共通の開発証明書の作成, およびGithubへのpushを $fastlane match developmentで行います.
あとは, 他の開発者が $fastlane match development --readonlyでその証明書を手元に取り込んで, 笑いあり涙ありの開発ライフを楽しんでいただきます.
ちなみにmatchを使わなくても, p12ファイルを手動で共有すればディベロッパー登録の手間自体は回避できるのですが, 一々渡すの超めんどくさいので嫌ですよね笑
え? それじゃあ --readonly 付け忘れたら勝手に証明書更新されるのでは?
はい, その通りですね…
なので弊社では「絶対に --readonly つけてね!」と言い聞かせることで解決しております.
いやいや, そんなわけありませんね.
何よりも自分自身の鶏並みの記憶力を信じられておりませんので, そんな危険な橋を渡るようなことはできません笑
こちらはGithubTeamを用いてios-certificates リポジトリへの権限を管理することで解決しています.
iOS-Developer-AdminチームにはReadおよびWrite権限を,
iOS-DeveloperチームにはRead権限のみを付与することで --readonly を付け忘れてもAdmin以外はコミットされません.
弊社のデプロイ環境
デプロイ環境に関しては前回の記事でも紹介しましたが, Bitrise上でデプロイが行われるようになっています.
その際, Workflowの中でfastlaneを使っていて, Fastfileの中にmatchの記述をしています.
AppStoreへアップロードするレーンはこんな感じで記述しています
こうすることで, AppStoreへのアップロードを簡単に行えて, 証明書をBitrise上で管理などする必要が一切なくなります.
証明書の動きとしてはこんな感じで, 開発者の環境と大きく変わりません.
証明書をこのように管理しておくことで, アプリケーションリポジトリのmasterへpushする権限を持っている開発者は, 誰でも簡単にAdhoc配信とStore申請を行えるようになります.
matchによる証明書管理の効能
matchを導入したことによる効果はあったのか, 検証していきましょう.
開発チーム拡大に伴い, ディベロッパー登録がものすごく手間になることが予想された
- -> 新たなディベロッパー登録が不要になりました.
全社で使用する共通の開発証明書が作成されたこと, そしてp12ファイルを手動で手渡しして回るという不毛な作業が消えたことで, 精神の疲弊削減に多大なる貢献をしました.
AppStoreに配信する際, アプリのArchiveとストアプッシュを特定のAppleアカウントでのみ行なっていた
弊社では, AppStoreに配信する際, アプリケーションのArchive, ストアプッシュ(もしくはFabricへの配信)を特定のAppleアカウントのみで行なっていました.
なので, 自分のMacからストアプッシュを行う際には社用のAppleアカウントでログインすることを一々CTOにお願いしていました.
- -> Store配信証明書の取得がBitrise上で完結するので, AppStoreへの配信がスムーズに!
これで, リリースの際にCTOに「Appleストアのアカウント入力してくださー(泣)」と毎度お願いしに行く必要がなくなりました.
開発者も嬉しいし, 話しかけてしまうことでCTOの集中が切れてしまう問題も解決されました.
次回予告
シリーズは一旦これで完結です.
しかし, これ以外にも実はBitriseでできることってけっこう色々あるんです.
- PRが上がってきたときにSwiftLintを元に自動でコードレビュー
- dSYMの自動アップロード
- podの更新 -> PR の自動化
などなど, Bitriseを使い倒すことで幸福感溢れる生活を遅れます.
ということで次回は
Bitrise使い倒してますか? 幸せな生活, 送れてますか?
といった内容で書いてみようかと思いますので, ぜひまた見にきてください.
