CI/CD Test Night 参加レポート #cicd_test_night
はじめに
Bitriseを利用する機会が増えもっと理解を深めていきたいと考えていた矢先に、Bitrise社の方々が来日されお話をされるという事でその勉強会に参加してきました。
勉強会からだいぶ経過していますが、せっかくなので参加レポートを書きます。
1日目トーク
Keynote
@ViktorBeneiさん(Bitrise CTO)
- Bitriseの紹介
- 以前はアプリ開発を沢山やっていた
- 社内の問題解決のために作った
- Bitfallという名前からBitriseという名前となった
- 現在の社員数は40名程度
- Bitrise利用者を国別で順位付けすると日本は第3位。2019年初頭には世界第2位になる見込み
-
steps-project-scannerリポジトリ
- iOS,Android,ReactNativeのプロジェクトをスキャンするOSS
- ワークフロー
- 何をするかを定義するもの
- ビルド、テスト、デプロイ等
- ステップの組み合わせによって構築される
-
bitrise-workflow-editorリポジトリ
- GUIでステップ処理とその順番を定義することができる
- ステップはライブラリから追加することが可能
- ステップ例
- Bitriseのキャッシュを取得するステップ
- 独自のスクリプトを叩くことができるステップ
- Bitriseに成果物をデプロイするステップ
- コードサイン
- KeyStoreやプロビジョニングプロファイルをアップロード可能
- その他にも５MBまでならファイルをアップロード可能
- EnvVars
- 環境変数をキーバリュー形式で保存可能
- Secrets
- 機密情報をキーバリュー形式で保存可能
- Triggers
- プッシュやタグ作成、PRベースで特定のワークフローを自動実行することができる
- 作成したトリガー順に判定し、最初に合致したトリガーに対応するワークフローを実行する
- 任意の文字列に合致させたい部分は
*で表現できる
- Stack
- ビルドする環境を選択することができる
- XcodeやmacOSのバージョンをワークフロー毎に設定することができる
- 約２年半分の環境がある
- bitrise.yml
- 設定ファイルの実態はymlファイルで管理できる
- ymlファイル上でワークフローやTriggers、EnvVarsの修正を行うことも可能
- ymlファイルのチェックを行い正しくない変更が入っている場合は保存できない
- YAML diff
- ビルド毎のymlファイルと現在のymlファイルの差異を閲覧することができる
- 何をするかを定義するもの
- ステップと統合
- コミュニティにより作られたステップも数多く存在する
- 自分自身のステップを作成することができる
- トラブルシューティング
- iOSアプリのCodeSigningの事例
- 自分はfastlaneに任せているので気にしたことない
- Android Firebase Test Lab
- 複数クリックで設定ができる
- iOSアプリのCodeSigningの事例
- アナウンス、Q&A
- Bitriseのドキュメントを日本語訳をヘルプ募って作った
- https://github.com/bitrise-io/devcenter/tree/master/_articles/translations
- Contribute用のSlackチームを作る予定
- 日本での採用開始
- Budapest or Tokyo
- イベントのスポンサーとしても日本でやっていきたい
- アプリ周辺ツールのサポートは？
- Swaggerのコード生成とか
- スクリプト書くことで対応することが可能
- 成果物もダウンロード可能
- デバイステストはβ版だが将来有料になるか？
- 今のところは無料だが、将来はわからない
- 処理の並列実行
- 特定のステップ使えば実現可能
Bitriseの社内提供へ ~Github Enterpriseとの連携~
- 自動テストのサポートチームに所属されている方
- Bitriseの導入経緯
- CircleCI Enterpriseを元々利用していた
- Linux／iOS版を契約していた
- Xcodeの最新バージョン提供スピードが遅い
- iOS VMイメージ切り替えのメンテが大変
- ビルド停止時間が数日できてしまう
- 運用負荷・有効に使えない
- 一方でBitriseはモバイル向けで注目されていた
- Xcodeのバージョンアップ対応も早い
- Enterprise版ではないので、運用コストが低い
- VPNを利用して連携している
- AWSにVPNを貼っている
- VPN証明書を担当チームが発行している
- CLIツールを作り、VPN証明書やGithubAPITokenとかもで対話的に設定できるようにしている
- CircleCI Enterpriseを元々利用していた
bitcode を有効にしたアプリでも dSYM のアップロードを自動化する
- iOSアプリエンジニアを対象に、bitcode対応している人のアンケートを取ったら半分くらいだった
- 意外と少ない
- fastlane
- download_symbols
- upload_symbols_to_crashlytics
- Bitriseでワークフロー作る
- さきほどのfastlaneのレーンを指定
- 自動化
- AppStoreConnectの処理が完了したメールが届いたら
- Google Apps Scriptを利用している
- メールをフックする仕組みはなさそうなので、スケジューリングしている
- Build Trigger APIを使っている
- Google Apps Scriptを利用している
- AppStoreConnectの処理が完了したメールが届いたら
- このトークの最中にTwitter上では、【GASを使ってAppStoreレビューを監視しているよ】という方もいて気になった
ゼロからはじめない方がいい iOSアプリのビルドシステム構築
- 前職でMonacaというサービスを開発していた時の裏側をお話されていた。
- サービス自体知らなかったので、詳細はあまり理解できなかったがビルドをMacMiniで捌いていたというのはちょっと驚いた。
Track Everything -すべてをGitHub/Bitriseで追跡可能にする-
@k_katsumiさん
資料
- FOLIOの利用例
- ユニットテスト
- プロダクション版の生成・配布
- ベータ版の生成・配布
- ライブラリアップデート
- fastlaneの更新があれば、勝手にPR作ってくれる
- スケジューリングジョブで毎日実行
- ライセンス情報の更新も↑の感じで
- lintチェック
- dsymのアップロード
- CI導入メリット
- 再現性 記録 可視化
- 手元のビルド以外はすべてCIで
- PRを起点に発火する
- ワークフローを構成管理する
- 個人の作業を再現可能にする
- 可視化
- 再現性
- 分業可能
- 初見に優しい
- 手作業でやると
- コンフィグレーション間違い
- コミット漏れ
- どのブランチから実行したか曖昧
- PR作成はSlackのボットで
- https://github.com/kishikawakatsumi/deliverbot
- 誰かが作業を始めたの可視化できる
- ワークフローのジョブ失敗も可視化できる
- 前回のタグから入ったコミットログをタグにすべて記載するように合わせて対応している
- バージョン番号はSlack botが勝手に上げてくれている
- FOLIOは数字だけみたい
- リリースノートの更新もここで自動で行えるように
- PRつくったときにコミットログも記載していて、release_noteのログはdeliverでmeta dataの差分をとってます
- Tips
- Auto Provisionが便利
- ワークフローでビルド環境を変更することができる
Workflow、どう組んでいますか？
@Horie1024さん
資料
- どう組んでいるか？
- 高品質なアプリを迅速に届ける
- 十分なテストが必要
- テスト戦略
- The Testing Pyramid
- ユニットテストのような小さなテストを頻繁に実行
- テスト戦略
- ワークフロー
- ユニットテストは頻繁に実行
- UIテストは段階的に実行
- 指針が必要
- デプロイメントパイプラインの概念導入
- モデル化
- コミットステージ
- 受け入れテストステージ
- 手動テストステージ
- リリースステージ
サイボウズの CI/CD 事情 ～Jenkins おじさんは CircleCI おじさんにしんかした！～
- Jenkinsなんでもできる
- Circle CI
- Performance Pricing Plan
- 重量課金
- コンテナー数ほぼ無限
- リソース可変
- ver2.1
- 構文増えて、ステップの再利用も
- https://www.kaizenprogrammer.com/entry/2018/10/01/035657
- Performance Pricing Plan
Wantedly Peopleのアプリのリリースワークフロー
- リリースブランチ作成時にやっていること
- APKのアップロード
- アーキテクチャ別（arm64, armeabi）に作成している
- マッピングファイルのアップロード
- ビルドURLを表示
- 差分のURLを表示
- 差分が多いと大変なので、どのPR一覧出すとかの方がよさそう
- Github Releaseを作る
- Slack bot
- Outgoing Webhooksを利用して、apkをGithub Releasesからダウンロードし、GooglePlayへアップロードできるようにしている
-
Download from Github Releases
- Github Releasesから該当のタグのアセットファイルを全てダウンロードできるBitriseのステップ
- APKのアップロード
2日目トーク
Keynote
@ViktorBeneiさん(Bitrise CTO)
- Automate Everything
- CLI
- ローカル実行も可能
- init, runアクションがある
- Sourcery
- メタプロ
- bitrise.ymlをリポジトリで保存することもできる
- ローカルでデバッグも可能
-
Danger
- Bitrise上でも利用可能
- コードチェックに何をチェックするのかを指定できる
- PRのチェック、ユニットテストの実行
- Auto Provision
- Bitrise.io API
- CLI
-
Flank
- テストの並列実行、時間削減
- テスト分割
- レポート作成
- テストシャーディング
- Roadmap
- Firebaseのアカウントなしでテストを行えるようにできる
- DashboardのUI改善
- ローディング時間の改善
- Organizationの管理
- オープンソースサポート
- チーム管理
- ２FAの強制
- SAML SSO
- New Build System
- linuxはもう使っていて、1,2分の短縮できている
- for Enterprise
- Hosting
- Performance
- Support
- ２４時間３６５日
- 英語以外のサポートも・日本語も
- Security
- アナウンス・Q&A
- プライベートクラウド 日本のデータセンターを東京の置く検討も
- Github Checks対応も予定している
- Firebase TestはBitrise経由だと無料で使える。ただし、時間の制限はある
CI/CD Test on ReRep
@Spring_MTさん
資料
- 開発ポリシー
- 存在する便利なツール・サービスは利用する
- Fastly, CircleCI, Bitrise, Sentry, Firebase とかを使っている
- API Spec Driven Development
- Swaggerを使っている
- 環境の同一性
- ストーレス、かつ、変更不可能なビルド成果物
- 存在する便利なツール・サービスは利用する
- 成果物の管理
- リポジトリへのpushをトリガに全ての成果物を保持している(ipa, apk)
- CI
- 成果物の作成
- テストの実行
- 成果物の保持
- テスト
- クライアント側のユニットテストはまだできていない
- CD
- まだできていない
私とBitriseとCircleCI - 私がAndroid CI/CDを移行して得られたもの -
- Bitriseに任せていること
- ビルド
- Play Storeへのアップロード
- 目的
- コスト削減
- オペミス防止
- BitriseからさらにCircle CI 2.0へ移行
- BitriseはGUIでさくっとワークフローが作れるので、プロジェクト初期は素早くCI/CD導入できる
- ただ、GUIに頼りすぎるの辛い部分もでてくる
- ローカルで実行できない
- fastlaneを使いながら、徐々にコード化していこう
- Circle CIだとジョブの並列実行もより柔軟に行えるので、チーム・組織に合わせて柔軟に選択できるとよい
アプリの検証がどのくらい行われているか調べてみた
- DeployGateのデータを元にどのくらいアプリの検証が行われているかを推測
- ストアの上位アプリだと、1日100回以上もインストールが行われている
- その分、検証が行われていると推測
- 全体アプリだと、1日2回も満たない
- ストアの上位アプリだと、1日100回以上もインストールが行われている
- 品質を高めるために、フィードバックをもらう機会を増やしましょう
React NativeアプリをBitriseでCDする
- Bitriseでやってること
- PRマージでDeployGateへのデプロイ実施
- タグ作成をトリガーに
- GooglePlayへのアルファ版アップロード
- AppStoreConnectへのモジュールアップロード
- Circle CIでやっていること
- プッシュをトリガーにテスト実施
- 手動でやっていること
- 審査ボタンをクリック
- テストは大事
- テストを書く時間がないので はなく、テストを書かないから時間がなくなるのです
社内ライブラリの更新を自動化する話
2日連続での登壇！
- DesignSystemというライブラリを開発中
- デザインの共通化
- Color, TextStyle, Buttonとか
- Atomic Designを用いる
- Atom, Moleculeまで対応
- UIに関する共通言語
- Multi Platform
- iOS,Android,ReactNative,React
- デザインの共通化
- 考える必要のあること
- Repository
- どこにライブラリを配信するか？
- AWS S3を使っている
- GradleもS3対応している
- 社内ネットワークからのみアクセスできるようにしている
- 社外からはVPNを経由
- CIからはクレデンシャルをSecretsから取得
- Update
- 常に安全に最新版を使いたい
- 更新に気づける
- UIテストを実行できる
- CHANGELOGも把握したい
- 常に安全に最新版を使いたい
- Repository
- 今後やっていきたい
- iOS側にも展開
- DesignSystem自体の更新を自動化
CI/CD専用モニタと心理的安全性
- CIの価値のうち、あまり意識されていないもの
- プロジェクトの可視性改善
- ソフトウェア製品に対する開発チームの自信を深める
- CI/CD用モニタ
- チーム全員が状況を一目で把握できる
- タスクが動いていることで、前に進んでいることが分かり自信が持てる
- タスクが正常終了すると安心できる
- 問題が発生した場合に、誰かがすぐ気づける
- コミュニケーションも生まれる
- チームの心理的安全性が高まる
まとめ
他社でどのようなワークフローを作成して自動化しているのかという事例を聞くことができ大変参考になりました。
ローカルでの実行・別CIサービスへの移行も念頭において、fastlaneを利用してビルドやアーカイブをし、Bitriseにしかできないこと(Bitrise Cacheとか)はBitriseに任せるという方針で自分は考えていましたが、他社さんも比較的同じ考えをされているようでした。
GASを利用したdSYMのFabricアップロードはとても参考になったので自分も導入してみようと思います。
素晴らしい発表ありがとうございました。
Author And Source
この問題について(CI/CD Test Night 参加レポート #cicd_test_night), 我々は、より多くの情報をここで見つけました https://qiita.com/maguhiro/items/c050fb9fa2a8dc5c389d著者帰属：元の著者の情報は、元のURLに含まれています。著作権は原作者に属する。
Content is automatically searched and collected through network algorithms . If there is a violation . Please contact us . We will adjust (correct author information ,or delete content ) as soon as possible .