ウェブ CI プロジェクト入門

Bitriseはモバイルに焦点を当てたDevOpsプラットフォームです。しかし、だからといってBitriseでモバイル以外のプロジェクトを構築できないというわけではありません。インテグレーション、デフォルトのワークフローとパイプライン、専用のキャッシュソリューションにより、モバイル以外のプロジェクトタイプをサポートしています

Web CIにBitriseを使用すると、モバイルやその他のすべてのプロジェクトをBitrise上で統合することができます。Bitriseは複雑な分野であるモバイルCI/CDに優れていますが、統合はモバイル向けの汎用CIよりもWebにBitriseを採用する方が簡単なため、運用が簡単になります

ウェブ CI プロジェクトの追加

Web CI プロジェクトには特定の要件はありません。ガイドの説明に従って Web CI プロジェクトを追加します。最初のアプリを追加する.

プロジェクトスキャナーは Web CI プロジェクトタイプを検出し、デフォルト設定を作成できます。リポジトリブランチを選択したら、以下を選択します。はい、構成を自動検出します。

プロジェクトスキャナーはプロジェクトファイルをスキャンします。モバイルプロジェクトと同様に、リポジトリ内の主要ファイルに基づいてプロジェクトを識別します。今のところ、Bitriseは3つのタイプを自動的に検出できます

Node.js: スキャナーはあなたのものを探します package.json ファイル。Bitriseはコンテンツに基づいてデフォルトのワークフローとパイプラインを作成します。
Kotlin マルチプラットフォーム: スキャナーは以下を探します gradlew ファイルを作成してチェックし、Kotlin プロジェクトかどうかを判断します。
Java: スキャナはビルドツールに基づいて Java プロジェクトを認識できます。次の 2 つのビルドツールがサポートされています。
- Gradle: スキャナーは以下を検索します gradlew ファイル。
- Maven: スキャナーは以下を検索します pom.xml ファイル。

依存関係の管理

Bitriseは、依存関係の処理を容易にする専用のステップを備えた複数の依存関係マネージャーをサポートしています。Web CI プロジェクトで最も重要なのは以下のとおりです。

npm コマンドを実行する: Node.js のデフォルトワークフローには npm 実行するステップ npm install。このコマンドは、で定義されている必要なパッケージをすべてインストールします package.json ファイル。フラグを指定して、要件に合わせてインストール手順を設定できます。

でコマンドを設定します実行する引数を指定した npm コマンド入力。既定の入力値はインストール。設定 YAML ファイルで、以下を探してください。 command 入力:
```
- npm:
    inputs:
    - command: install -g
```
yarn コマンドを実行する: Yarn は npm と同様に、以下で依存関係を探します。 package.json ファイル。このステップでは、以下を指定できます。 yarn 実行したいコマンドとその他の引数

コマンドをに追加実行する yarn コマンド入力。設定 YAML ファイルでは、入力は呼び出されます command。依存関係をインストールするには空のままにしておきます。
```
- yarn:   
    inputs:
    - command: 
```
yarnコマンドの引数を以下で指定します yarn コマンドを実行するための引数入力。設定 YAML ファイルでは、入力は呼び出されます args。複数の引数をスペース文字で区切って追加できます。
```
- yarn:      
    inputs:        
    - args: "-dev"
```
グラドルランナー: プロジェクトが Gradle でビルドされている場合は、このステップを使用してプロセス中に依存関係をインストールできます。そのためには、以下が必要です
- グラドルラッパー。
- 正しく設定されている Gradle タスク。
- ビルドスクリプトで宣言された依存関係。
このステップには 2 つの入力が必要です。実行する Gradle タスク入力はビルド中に実行される Gradle タスクを定義します。は Gradle ラッパーパス入力はへのパスを定義します。 gradlew プロジェクト内のファイル。設定 YAML ファイルでは、これらの入力は gradle_task そして gradlew_path。
```
- gradle-runner:
    inputs:
    - gradlew_path: ./cool_project/
    - gradle_task: install
```

テストを実行中

すべてのBitriseプロジェクトには、というデフォルトのテストワークフローがあります run_tests。ワークフローの内容は、正確なプロジェクトタイプによって異なります。

Java と Kotlin 用 Gradle を使ったテスト

Gradle で構築された Java および Kotlin プロジェクトの場合、テストは次の点を中心に展開されます。 test グラドルタスク。Bitriseにはこのための専用のステップがあります Gradle テストを実行する これはデフォルトのワークフローの一部です。

ステップにはグラドルラッパープロジェクトで。ラッパーには、正しく設定されたテストタスクが少なくとも 1 つ含まれている必要があります
使用テストタスク実行したい Gradle タスクを設定するための入力。デフォルトでは、ステップは以下を実行します test タスクですが、任意の Gradle タスクを設定できます。
を使うその他のフラグ入力すると、gradlew コマンドをさらにカスタマイズできます。たとえば、特定のテストクラスを実行するフラグを設定できます

Java 版 Maven によるテスト

Maven でビルドされた Java プロジェクトでは、以下を実行するスクリプトステップを使用してテストが実行されます。 Maven ラッパーのテストコマンド: ./mvnw test。

スクリプトステップは完全にカスタマイズ可能で、必要な Maven 設定を作成できます。デフォルト設定は、目的に合わせていつでも自由に変更できます。Maven でテストを実行する方法の詳細については、以下をご覧くださいシュアファイア。

Node.js プロジェクトのテスト

Node.js プロジェクトの場合、Bitrise のデフォルトワークフローは次の 2 つのことを行います。

Node.js を経由してインストールします スクリプト ステップ:スクリプトステップなので、自分のニーズに合わせて設定を完全に変更したりカスタマイズしたりできます。デフォルトのソリューションでは、以下のようにして Node.js をインストールするだけです asdf:

ヒント

Bitriseスタックには以下が付属しています .sdf さまざまなソフトウェアバージョン間の自動切り替えに役立つプリインストール asdf 以下のファイルから Node.js のバージョンを探します。 .tool-versions、 .nvmrc、 .node-version そのため、プロジェクトが別の Node.js マネージャーを使用しても、すぐに使用できるはずです。
```
set -euxo pipefail

export ASDF_NODEJS_LEGACY_FILE_DYNAMIC_STRATEGY=latest_installed
envman add --key ASDF_NODEJS_LEGACY_FILE_DYNAMIC_STRATEGY --value latest_installed

pushd "${NODEJS_PROJECT_DIR:-.}" > /dev/null

asdf install nodejs

popd > /dev/null
```
走る npm run lint と npm ステップ: lint コマンドはコードを分析して潜在的なエラーがないか調べます。

ザ・ npm ステップではテストも実行できます。実行できるのは test で定義されたテストを実行するコマンド package.json ファイル。

キャッシュ

Bitriseは2つの異なるキャッシュソリューションを提供しています。

ビットライズビルドキャッシュ: Bazel や Gradle でプロジェクトをビルドする場合、Bitrise Build Cache はビルドとテストの出力をキャッシュして、それ以降のビルドで行われる作業量を最小限に抑えます。どの CI ツールとも互換性があり、キャッシュインフラストラクチャーを管理しなくてもビルドサイクルを短縮できます
キーベースのキャッシュ: キーベースのキャッシュは、キャッシュアーカイブをキーに関連付けることで機能します。ワークフローはキーを参照してキャッシュアーカイブを復元できます。ワークフローの最後に、ビルドファイルをキーが示すキャッシュアーカイブに保存できます。これにより、キャッシュアーカイブが上書きされます。

ビットライズビルドキャッシュ

Bitrise Build Cacheへの新しい接続の追加は以下の手順で行います。

CIプロバイダーの選択:Bitriseまたは別のCIプロバイダーを使用できます。
ビルドツールの選択:現在、Bazel と Gradle がサポートされています。
CIプロバイダーとしてBitriseを使用している場合は、Bitriseプロジェクトを選択してください。
別の CI プロバイダーを使用する場合は、以下を追加します個人アクセストークン Bitrise ビルドキャッシュがお客様の CI にアクセスできるようにします。
CI プロセスにキャッシュアクティベーションスクリプトを追加します。Bitriseでは、専用のアプリを用意していますステップこのため。ワークフローとパイプライン

キーベースのキャッシュ

キーベースのキャッシュを使用するには、主に次の 2 つの方法があります。

専用のキャッシュステップを使用する。これらは依存関係に必要なキャッシュキーを自動的に設定するので、設定は不要です。専用ステップには、npm、Yarn、Gradle の依存関係をキャッシュするステップが含まれます依存関係マネージャーの専用キャッシュ手順.
を使う スクリプト キャッシュアーカイブのキーを設定する手順。これにより、キャッシュ設定を完全に制御できますビルドでキーベースのキャッシュを使用する.

ドッカーコンテナのサポート

BitriseではDockerコンテナを使うことができます ワークフロー と パイプライン。コンテナサポートによりバックグラウンドサービスも可能になります。コンテナーでビルドを実行すると、ビルド環境を完全に制御でき、ビルド中に依存関係をインストールする必要はありません。

Docker イメージを構築する

コンテナを使用するには、Docker イメージが必要です。を使用して独自の Docker イメージをビルドしてプッシュできます Docker ビルド & プッシュステップ。このステップでは、ビルドしたイメージに適用するイメージタグのリストが必要です。以下も指定できます

ビルドコンテキスト。
ドッカーファイルパス。

ザ・ Docker ビルド & プッシュ Step には以下のサポートが組み込まれています。キーベースのキャッシュ。つまり、Stepはプリセットのキャッシュキーを使用して、ビルドしたDockerイメージを自動的にキャッシュします。詳細については、ビットライズで自分だけのDockerイメージを構築しよう。

コンテナを使う

ビルドでコンテナを使用するには、以下を行う必要があります。

コンテナを定義します。コンテナ ID と Docker イメージの名前とバージョンが必要です
ワークフローまたはパイプライン内では、コンテナを ID で参照します。同じワークフローのさまざまな部分をさまざまなコンテナで実行できます。

また、Docker コンテナを高度な統合テスト用のサービスとして実行できるサービスコンテナを定義することもできます。

詳しくはチェックアウト Bitriseワークフローでのコンテナの使用。

デプロイ中

Web CI プロジェクトを次の 3 つの方法のいずれかでデプロイします。

ザ・ Bitrise.io にデプロイしてください ステップ:Bitriseにファイルをデプロイします。にデプロイしたいファイルへのパスを設定しますデプロイディレクトリまたはファイルパスステップの入力。ビルドが成功すると、以下で確認できますアーティファクト「」タブビルドページ。ここからファイルをダウンロードできます。

詳細については、以下をご覧くださいオンラインでアーティファクトを作成する。
カスタマイズされたスクリプトステップ: 独自のカスタムスクリプトを使用してプロジェクトをデプロイします。このステップは、一般的なスクリプト言語をすべてサポートしています。また、このステップでは独自の環境変数を作成してエクスポートし、後続のステップでアクセスすることもできます。スクリプトステップでは、すべてを完全に制御できます。
専用のデプロイステップ:これらのステップは、ウェブプロジェクトを特定のサービスにデプロイします。たとえば、 Amazon S3 バケット同期ステップローカルフォルダの内容を Amazon S3 バケットにアップロードします。 Heroku デプロイ Step は Heroku ツールベルトを使用してアプリを Heroku にデプロイします。

今後、できるだけ多くのユースケースに対応できるよう、新しいデプロイステップを積極的に追加する予定です。

このセクションの内容:

ワークフローパイプライン