Travis CIに代わるCIサービスをお探しですか。TravisからBitriseへ既存のプロジェクトを移行する方法がTheSwiftDevのTibor Bödecsさんによって執筆されましたのでご紹介いたします。
Travis vs Bitrise
Travisとは、GitHubでホストされたオープンソースプロジェクトをテストするサービスです。ほぼ全ての開発プラットフォームや言語に対応し、GitHubとの統合性も兼ね備えているので、自動化されたPRコメントシステムによるコードレビュー過程を高速化します。
一方で、Bitriseは万能なCI/CDサービスです。モバイル開発プロジェクト用に最高のサポート体制を敷いているほかにも、デスクトップアプリを始めサーバサイドプロジェクトに至るまでいかなるものでも自動化してくれるのが特徴です。
主な違いはTravisはGitHubだけに動作するのに対し、Bitriseはほぼすべてのgitホスティングプロバイダに対応しています。自分専用のgitレポジトリも使用することができます。
Travisにある、job lifecycleというものはBitriseには存在しません。その代わり、Bitriseではステップを活用します。すべてのビルド作業一つ一つがステップと呼ばれます。そのステップ同士がワークフロー内において順序よく組み合わさっているのです。Bitriseにはたくさんのステップが存在しており、文書化もされているので非常にパワフルなものとなっています。
TravisにはGitHubとの深い互換性があるので、すぐにアプリのCI環境を構築することができます。TravisからBitriseに移行するには少々努力を要しますが、基本的なセットアップについての記事や動画チュートリアルを活用すれば問題なく移行することができます。
Bitriseのセットアップは超簡単！
ここではセットアップについての簡単なクイックガイドを紹介します。Bitriseは主要なgitサービスプロバイダやアプリテンプレートをサポートしているので簡単に使用することができます。
まず最初に、Bitriseにログインします（もしくは無料アカウントに登録します）。新規にアプリを作成するには、Add Appメニューをクリックしてください。ウィザードがステップごとに丁寧に順を追って説明してくれます。
最初のステップとして、オーナーの選択とアクセスレベル（非公開もしくは公開）を設定する必要があります。次に、ご自身のgitレポジトリ（GitHub、Bitbucket、GitLabもしくはマニュアル接続）に接続して必要な証明書（credential）を入力します。そうすることにより、CIプロセスがブランチからソースコードを認識します。
その後、Bitriseはすべてをバリデートします。ここでは、プロジェクトのスキャンを行い、レポジトリ内にある（検出された）コードに基づいて最初のワークフローが表示されます。iOS、Android、Xamarin、fastlane、macOS、Cordova、Ionic、React Native、Flutterはビルトイン（組み込み）ですが、これら以外を使用する場合、完全にユニークなワークフローを作成することもできます。
iOSアプリを例に挙げて話を進めましょう。
最後のステップにおいては、Project Path（プロジェクトパス）やScheme Name（スキーム名）、Export Method（エクスポート法）、Build Stack（macOS & Xcodeバージョンのビルドスタック）といった項目のカスタマイズを行うことができます。オプションでwebhookの登録を行えば、レポ内で”何か”が発生すると自動的にビルドがスタートします。
構成ファイルはもはや不要
.travis.ymlファイルが必要ないのであれば、レポジトリから安全に消去することが可能です。Bitrise内では、すべての構成がサービスの一部として保存されるので、CI関連物が本来のコードベースと一緒くたになることはありません。
私はこれが、ほかのプロバイダと比較してBitriseの一番の強みだと思っています。なぜなら、gitの履歴を使い道のない ’changed CI file again’ コミットで汚す必要がないからです。Squash＆Rebaseも可能ではありますが、私はBitriseがそれをサービスインフラの一部として扱っていることに感銘を受けました。ほんの小さな事かもしれませんが、それはDXにおいて非常に大きなインパクトを持っています。🤓
クイックノート：ローカルでBitriseを作動したい場合、Brewを通じてBitrise CLIツールのインストールが行なえます。ただ、それを作動させるには、ご自身でローカルのbitrise.ymlファイルの構成ファイルを作成する必要があります。
ここでは、ワークフローのセットアップに関する詳細についての情報は割愛させていただきます。というのも、セットアップ法や正しいチューン法についてはすでに素晴らしいチュートリアルがあるのでそちらをご覧ください。ビルトインのWorkflow Editorを使うことで、全てを安全に構成することができます。
GitHubプルリクエストの自動ステータスチェック
GitHubプルリクエストのチェックはTravis CIにおいて素晴らしい機能の一つです。Bitriseでも、適切なwebhookとトリガーのメカニズムを設定しておけば、同様のことが可能になります。Create New App（新しいアプリを作成する）スクリーン上で自動webhookセットアップをスキップしていても、Codeタブにてそれを有効化することができます。 🔨
Webhookは、Account設定ページにてGitHub・Bitbucket・Gitlabといったサービスプロバイダにアクセスを許可すれば自動的に登録されます。以下のツールにマニュアルでWebhookに接続することも可能です：
- GitHub (Code Push, Pull Request, Tag Push)
- Bitbucket Webhooks (Code Push, Pull Request, Tag Push)
- Bitbucket Server Webhooks (Code Push, Pull Request, Tag Push)
- GitLab (Code Push, Merge Request, Tag Push)
- Visual Studio Online / Visual Studio Team Services (Code Push, Tag Push)
- Slack (Outgoing Webhook & Slash Command)
- Gogs (Code Push)
- Deveo (Code Push, Tag Push)
- Assembla (Code Push)
Webhookの接続が完了すると、上でリスト化されているカッコ内で示されたイベントに基づいたビルドをトリガーする事ができるようになります。GitHubを使用しているのであれば、自動ステータスチェックレポートをプルリクエストページにて直接確認することができます。
全ての利用可能なイベントをビルドアクションへ結びつけることができます。例えば、dev sourceブランチからmaster targetブランチへのプルリクエストが特定のテストワークフローのトリガーが可能です。gitレポジトリイベント用のこのようなトリガーマップは、Triggersタブの下にあるWorkflow Editor内で構成されます。🔫
結論
以上が、TravisからBitriseへiOSプロジェクトの基本的な移行方法になります。お分かりの通り、移行する手順の中で最も手のかかる部分は最初のプロジェクトのセットアップになりますが、CIプロバイダの変更時には避けて通ることはできません。BitriseはGitHubへインテグレートされるので同様にチェックも行います。
Travisに代わるCIを模索しているのであれば、Bitriseを使用することをおすすめします。ステップをベースにしたワークフローのセットアップは非常に魅力的です。Bitriseはフレキシブルで、たくさんの機能があり、サポート体制も万全です。何より素晴らしいのが、簡単に習得できることだと思います！Bitriseをお試しあれ！😉
