Skip to main content

パイプラインの構築[ベータ版]

Bitrise Pipelineは、CI/CD構成の最上位レベルです。パイプラインを使用して、CI / CDプロセス全体を整理し、複数の異なるタスクを並行しておよび/または順次実行する高度な構成をセットアップできます。

パイプラインの構成要素は次のとおりです。

  • 手順:スクリプト実行のブロック。それぞれがCI/CDプロセスで単一のタスクを定義します。

  • ワークフロー:ステップのコレクション。アプリのビルドが実行されている場合、ステップはワークフローで定義された順序で実行されます。

  • ステージ:ワークフローのコレクション。ステージには、同じステージですべて並行して実行される複数のワークフローを含めることができます。すべてのワークフローがステージで成功すると、パイプラインは次のステージに進みます。ワークフローのいずれかが失敗した場合、特定のステージを常に実行するように構成しない限り、パイプラインは他のステージを実行せずに終了します。

Bitriseパイプラインの構成

現在、パイプラインの構成は、直接編集することによってのみ可能です。 bitrise.yml ファイル。グラフィカルなワークフローエディターでワークフローを作成および変更できますが、パイプラインとステージをYAML形式で定義する必要があります。

パイプライン、ステップ、およびワークフローの定義

The bitrise.yml ファイルには、パイプラインの完全な構成が含まれています。すべてのように bitrise.yml ファイルの場合、最初にフォーマットバージョンとプロジェクトタイプを定義する必要があります。

---
format_version: '8'
default_step_lib_source: 
project_type: android

これは最低限です bitrise.yml 構成。パイプラインを定義するには、パイプライン属性を使用する必要があります。

pipelines:  
  pipeline-successful:
    stages:
    - stage-successful-1: {}
    - stage-successful-2: {}
    - stage-successful-3: {}

この例では、というパイプラインがあります pipeline-successful、連続して実行される3つのステージがあります。これは、 stage-successful-1 正常に終了し、 stage-successful-2 開始します。いずれかのステージが失敗した場合、後続のステージは開始されません。代わりに、パイプラインが中止され、失敗としてマークされます。

各ステージは、 stages 属性。ステージの定義とは、ステージの一部であるワークフローを指定することを意味します。

stages:
  stage-successful-1:
    workflows:
    - test-1: {}
  stage-successful-2:
    workflows:
    - build-1: {}
    - build-2: {}
  stage-successful-3:
    workflows:
    - deploy-1: {}
    - deploy-2: {}

この例では、ステージは test-1build-1build-2deploy-1、 と deploy-2 ワークフロー。

常に実行するようにステージを構成する

デフォルトでは、ワークフローの 1 つが失敗したためにステージが失敗した場合、パイプラインの他の後続のステージは実行されません。ただし、パイプラインが中止されない限り、特定のステージを実行するようにパイプラインを構成できます。

これを行うには、設定する必要があります should_always_run ステージの属性をtrueに設定します。

stages:
  stage-always-run-successful-1:
    should_always_run: true
    workflows:
    - deploy-1: {}
    - deploy-2: {}

上記の例では、Stage が呼び出されます。 stage-always-run-successful-1 前のステージのステータスに関係なく、常に実行されます。これらのステージが実行されない唯一の方法は、パイプライン ビルドがユーザーによって中止された場合です。

失敗したステージのワークフローを中止する

デフォルトでは、特定のステージのワークフローに障害が発生しても、同じステージの他のワークフローは自動的に中止されません。これらのワークフローは実行されますが、次のステージは開始されません。ただし、この動作を変更して、同じステージ内の他のすべてのワークフローを即座に自動的に中止することができます。

そのためには、を設定する必要があります abort_on_fail に属性 true

stages:
  stage-abort-on-fail-1:
    abort_on_fail: true
    workflows:
    - deploy-1: {}
    - deploy-2: {}

パイプライン ステージ間で環境変数を共有する

から任意の環境変数を再利用できます。 ワークフロー その後で再利用します ステージ を使用して パイプライン変数を共有するステップ.このステップを使用して環境変数を共有しても、 アプリ.

run_if 条件を使用したオプションのワークフロー

簡単に組み合わせることができます パイプライン変数を共有する ステップ run_if オプションのワークフローでパイプラインを作成するための式。詳細については、こちらをご覧ください パイプラインを使用したオプションのワークフローの run_if 条件の設定.パイプラインを使用したオプションのワークフローの run_if 条件の設定

そうするために:

  1. 追加 パイプライン変数を共有する ワークフローに進みます。

  2. 必要に応じて、追加の実行条件を 追加の実行条件 入力。ステップは、ここで指定した条件が真の場合にのみ実行されます。

  3. 後続のステージで使用する環境変数を パイプライン ステージ間で共有する変数 入力。

    環境変数キーの使用

    を使用して環境変数を定義できます。{key}={value}構文。例えば、 MY_ENV_KEY=value、 また INSTALL_PAGE_URL=$BITRISE_PUBLIC_PAGE_URL.

    デフォルトの環境変数キーを使用する場合は、簡略構文を使用できます。例えば、 EXISTING_ENV_KEY.

    このステップを使用して環境変数を共有しても、 アプリ.

それでおしまい!後続のステージで環境変数を使用できるようになりました!

Bitriseパイプラインの構成

現在、パイプラインの構成は、直接編集することによってのみ可能です。 bitrise.yml ファイル。グラフィカルなワークフローエディターでワークフローを作成および変更できますが、パイプラインとステージをYAML形式で定義する必要があります。

パイプライン、ステップ、およびワークフローの定義

The bitrise.yml ファイルには、パイプラインの完全な構成が含まれています。すべてのように bitrise.yml ファイルの場合、最初にフォーマットバージョンとプロジェクトタイプを定義する必要があります。

---
format_version: '8'
default_step_lib_source: 
project_type: android

これは最低限です bitrise.yml 構成。パイプラインを定義するには、パイプライン属性を使用する必要があります。

pipelines:  
  pipeline-successful:
    stages:
    - stage-successful-1: {}
    - stage-successful-2: {}
    - stage-successful-3: {}

この例では、というパイプラインがあります pipeline-successful、連続して実行される3つのステージがあります。これは、 stage-successful-1 正常に終了し、 stage-successful-2 開始します。いずれかのステージが失敗した場合、後続のステージは開始されません。代わりに、パイプラインが中止され、失敗としてマークされます。

各ステージは、 stages 属性。ステージの定義とは、ステージの一部であるワークフローを指定することを意味します。

stages:
  stage-successful-1:
    workflows:
    - test-1: {}
  stage-successful-2:
    workflows:
    - build-1: {}
    - build-2: {}
  stage-successful-3:
    workflows:
    - deploy-1: {}
    - deploy-2: {}

この例では、ステージは test-1build-1build-2deploy-1、 と deploy-2 ワークフロー。

常に実行するようにステージを構成する

デフォルトでは、ワークフローの 1 つが失敗したためにステージが失敗した場合、パイプラインの他の後続のステージは実行されません。ただし、パイプラインが中止されない限り、特定のステージを実行するようにパイプラインを構成できます。

これを行うには、設定する必要があります should_always_run ステージの属性をtrueに設定します。

stages:
  stage-always-run-successful-1:
    should_always_run: true
    workflows:
    - deploy-1: {}
    - deploy-2: {}

上記の例では、Stage が呼び出されます。 stage-always-run-successful-1 前のステージのステータスに関係なく、常に実行されます。これらのステージが実行されない唯一の方法は、パイプライン ビルドがユーザーによって中止された場合です。

失敗したステージのワークフローを中止する

デフォルトでは、特定のステージのワークフローに障害が発生しても、同じステージの他のワークフローは自動的に中止されません。これらのワークフローは実行されますが、次のステージは開始されません。ただし、この動作を変更して、同じステージ内の他のすべてのワークフローを即座に自動的に中止することができます。

そのためには、を設定する必要があります abort_on_fail に属性 true

stages:
  stage-abort-on-fail-1:
    abort_on_fail: true
    workflows:
    - deploy-1: {}
    - deploy-2: {}

パイプライン ステージ間で環境変数を共有する

から任意の環境変数を再利用できます。 ワークフロー その後で再利用します ステージ を使用して パイプライン変数を共有するステップ.このステップを使用して環境変数を共有しても、 アプリ.

run_if 条件を使用したオプションのワークフロー

簡単に組み合わせることができます パイプライン変数を共有する ステップ run_if オプションのワークフローでパイプラインを作成するための式。詳細については、こちらをご覧ください パイプラインを使用したオプションのワークフローの run_if 条件の設定.パイプラインを使用したオプションのワークフローの run_if 条件の設定

そうするために:

  1. 追加 パイプライン変数を共有する ワークフローに進みます。

  2. 必要に応じて、追加の実行条件を 追加の実行条件 入力。ステップは、ここで指定した条件が真の場合にのみ実行されます。

  3. 後続のステージで使用する環境変数を パイプライン ステージ間で共有する変数 入力。

    環境変数キーの使用

    を使用して環境変数を定義できます。{key}={value}構文。例えば、 MY_ENV_KEY=value、 また INSTALL_PAGE_URL=$BITRISE_PUBLIC_PAGE_URL.

    デフォルトの環境変数キーを使用する場合は、簡略構文を使用できます。例えば、 EXISTING_ENV_KEY.

    このステップを使用して環境変数を共有しても、 アプリ.

それでおしまい!後続のステージで環境変数を使用できるようになりました!

iOSプラットフォームで現在サポートされているユースケース

一部ご用意しました パイプライン iOS の一般的な使用例に基づいたレシピ。これらには、ユーザーが実行する必要のある最も頻繁なタスクが含まれています。

(iOS)複数のシミュレーターで並行してテストを実行する

説明

この例では、 sample-swift-project-with-parallel-ui-test iOSオープンソースサンプルアプリ。ユニットテストとUIテストの例がいくつかあり、テストプランを使用してテストをグループ化します。

The パイプライン構成の例 プロジェクトのすべてのテストケースをさまざまなiOSシミュレーターで実行する方法を紹介します。

run_tests_on_simulators パイプラインは2つのステージを順番に実行します。

  1. build_tests stage を実行します build_tests ワークフロー。このワークフローgitは、サンプルプロジェクトのクローンを作成し、 xcode-build-for-test ターゲットと関連するテストを構築する手順。構築されたテストバンドルは次のステージに転送されます(run_tests_on_simulators)経由 deploy-to-bitrise-io ステップ。

    ビルドテストバンドルは圧縮されています

    xcode-build-for-test ステップは、ビルドされたテストバンドルを圧縮し、生成されたzipを $BITRISE_DEPLOY_DIR。そのディレクトリのコンテンツは、デフォルトでワークフローアーティファクトにデプロイされます。 deploy-to-bitrise-io ステップ。

    アーティファクト ファイルのサイズ制限

    デプロイするファイルの数に制限はありません アーティファクト ビルドごと。ただし、ファイルサイズには制限があり、1 ファイルあたり 2GB です。

  2. run_tests_on_simulators Stageは、3つのワークフローを並行して実行します。 run_tests_iPadrun_tests_iPhone、 と run_tests_iPod。これらのワークフローは両方とも、新しいワークフローを使用します xcode-test-without-building 前のステージで構築されたテストバンドルに基づいてテストを実行するステップ。事前に構築されたテストバンドルは、 _pull_test_bundle ユーティリティワークフロー。

    iOS_example_modified.png

指示

新しいBitriseサンプルプロジェクトで構成をテストするには、次の手順を実行します。

  1. 訪問 新しいアプリページを作成する 新しいアプリを作成します。

  2. gitリポジトリを選択するように求められたら、 その他/マニュアル サンプルプロジェクトリポジトリのURLを貼り付けます(https://github.com/bitrise-io/sample-swift-project-with-parallel-ui-test) の中に Gitリポジトリ(クローン)URL 分野。

  3. 表示されるポップアップで、これがパブリックリポジトリであることを確認します。

  4. を選択 主人 スキャンするブランチ。

  5. プロジェクトスキャナーが完了するのを待ちます。

  6. 提供されている配布方法のいずれかを選択します(たとえば、 発達、現在はテストに重点を置いているため、実際には問題ではありません)。

  7. 提供されたスタックを確認し、アプリアイコンとWebhook登録の選択をスキップして、最初のビルドを開始します。

  8. 新しいBitriseプロジェクトのワークフローエディタを開きます。

  9. に移動します bitrise.yml タブを押して、既存のものを置き換えます bitrise.yml 例の内容で bitrise.yml ファイル。

  10. クリック ビルドの開始/スケジュール ボタンをクリックし、 run_tests_on_simulatorsワークフロー、パイプラインポップアップの下部にある「」ドロップダウンメニュー。

bitrise.yml

GitHubリンク: https://github.com/bitrise-io/workflow-recipes/blob/main/recipes/ios-run-tests-in-parallel-on-multiple-simulators.md#bitriseyml

(iOS)テストグループを並行して実行する

説明

この例では、 sample-swift-project-with-parallel-ui-test iOSオープンソースサンプルアプリ。ユニットテストとUIテストの例がいくつかあり、テストプランを使用してテストをグループ化します。

XCodeテストプラン

Xcodeテストプランは、さまざまなテスト構成で一連のテストを実行する方法を提供します。 raywenderlich.comには素晴らしい Xcodeテストプランの開始方法に関するチュートリアル

パイプライン構成の例は、さまざまなテストグループを並行して実行する方法を示しています。

run_tests_groups パイプラインは2つのステージを順番に実行します。

  1. build_tests を実行するステージ build_tests ワークフロー。このワークフローgitは、サンプルプロジェクトのクローンを作成し、 xcode-build-for-test ターゲットと関連するテストを構築する手順。構築されたテストバンドルは次のステージに転送されます(run_tests_groups)経由 deploy-to-bitrise-io ステップ。

  2. run_tests_groups Stageは、2つのワークフローを並行して実行します。 run_ui_testsrun_unit_tests。これらのワークフローは両方とも新しいxを使用しますcode-test-without-building 前のステージで構築されたテストバンドルに基づいてテストを実行するステップ。事前に構築されたテストバンドルは、 _pull_test_bundle ユーティリティワークフロー。

    iOS_example_2.png

指示

  1. 訪問 新しいアプリページを作成する 新しいアプリを作成します。

  2. gitリポジトリを選択するように求められたら、 その他/マニュアル サンプルプロジェクトリポジトリのURLを貼り付けます(https://github.com/bitrise-io/sample-swift-project-with-parallel-ui-test) の中に Gitリポジトリ(クローン)URL 分野。

  3. 表示されるポップアップで、これがパブリックリポジトリであることを確認します。

  4. を選択 主人 スキャンするブランチ。

  5. プロジェクトスキャナーが完了するのを待ちます。

  6. 提供されている配布方法のいずれかを選択します(たとえば、 発達、現在はテストに重点を置いているため、実際には問題ではありません)。

  7. 提供されたスタックを確認し、アプリアイコンとWebhook登録の選択をスキップして、最初のビルドを開始します。

  8. 新しいBitriseプロジェクトのワークフローエディタを開きます。

  9. に移動します bitrise.yml タブを押して、既存のものを置き換えます bitrise.yml 例の内容で bitrise.yml ファイル。

  10. クリック ビルドの開始/スケジュール ボタンをクリックし、 run_tests_groupsワークフロー、パイプラインポップアップの下部にある「」ドロップダウンメニュー。

bitrise.yml

GitHubリンク: https://github.com/bitrise-io/workflow-recipes/blob/main/recipes/ios-run-test-groups-in-parallel.md#bitriseyml

(iOS)テスト結果のマージとテストレポートアドオンへのデプロイ

説明

Test Reportsアドオンは、Bitriseビルドに関連付けられています。異なるビルドで生成されたすべてのテストレポートをアドオンの単一のページに表示するには、レポートをマージして追加のビルドにデプロイする必要があります。

この例では、 sample-swift-project-with-parallel-ui-test iOSオープンソースサンプルアプリと拡張'iOSテストグループを並行して実行する'テスト結果をマージおよびデプロイするパイプライン構成の例。

run_ui_testsrun_unit_tests ワークフローは、deploy-to-bitrise-ioステップで拡張され、生成されたテスト結果を次のステージで利用できるようにします。

run_tests_groups パイプラインは新しいステージで拡張されます: deploy_test_results。このステージは、 deploy_test_results ワークフロー:

  1. artifact-pull ステップは、ステージによって以前に生成されたすべてのzip形式のテスト結果をダウンロードします。 run_tests_groups

  2. script ステップは、各テスト結果をテストレポートアドオンデプロイディレクトリ内の新しいテスト実行ディレクトリに解凍し、関連するものを作成します test-info.json ファイル。

  3. deploy-to-bitrise-io ステップは、マージされたテスト結果をデプロイします。

    iOS_example_3.png

指示

  1. 訪問 新しいアプリページを作成する 新しいアプリを作成します。

  2. gitリポジトリを選択するように求められたら、 その他/マニュアル サンプルプロジェクトリポジトリのURLを貼り付けます(https://github.com/bitrise-io/sample-swift-project-with-parallel-ui-test) の中に Gitリポジトリ(クローン)URL 分野。

  3. 表示されるポップアップで、これがパブリックリポジトリであることを確認します。

  4. を選択 主人 スキャンするブランチ。

  5. プロジェクトスキャナーが完了するのを待ちます。

  6. 提供されている配布方法のいずれかを選択します(たとえば、 発達、現在はテストに重点を置いているため、実際には問題ではありません)。

  7. 提供されたスタックを確認し、アプリアイコンとWebhook登録の選択をスキップして、最初のビルドを開始します。

  8. 新しいBitriseプロジェクトのワークフローエディタを開きます。

  9. に移動します bitrise.yml タブを押して、既存のものを置き換えます bitrise.yml 拡張された例の内容で bitrise.yml ファイル。

  10. クリック ビルドの開始/スケジュール ボタンをクリックし、 run_tests_groupsワークフロー、パイプラインポップアップの下部にある「」ドロップダウンメニュー。

  11. パイプラインのビルドページを開きます。

  12. を選択 deploy_test_results 建てる。

  13. クリック 詳細とアドオン ビルドの詳細ページで、 テストレポートアドオン マージされたテストレポートを表示します。

bitrise.yml

GitHubリンク: https://github.com/bitrise-io/workflow-recipes/blob/main/recipes/ios-merging-test-results-and-deploying-to-the-test-reports-add-on.md#bitriseyml

Androidプラットフォームで現在サポートされているユースケース

一部ご用意しました パイプライン 一般的な Android の使用例に基づいたレシピ。これらには、ユーザーが実行する必要がある最も頻繁なタスクが含まれています。例には全体が含まれます ワークフロー ほとんどの場合、コピーして貼り付けることができます。

(Android)複数のデバイスまたはシャードでUIテストを並行して実行する

説明

パイプラインを利用した並列ワークフローで単一モジュールのUI(インストルメンテーション)テストを実行します。シャードまたはデバイスごとにテストを並行して実行できます。

パイプラインには、シリアルに実行される2つのステージが含まれています。

  1. build_for_ui_testing:このステージはワークフローを実行します—名前も付けられます build_for_ui_testing —それは android-build-for-ui-testing テストで使用するAPKを作成し、 deploy-to-bitrise-io 後のステージで使用するためにそれらのAPKを保存するステップ。このステージを実際のテストとは別に実行すると、各テストステージで、テストステージごとに再構築するのではなく、これらの事前に作成されたAPKを使用できます。

  2. run_ui_tests_on_devices:このステージでは、3つのUIテストワークフローを並行して実行します— ui_test_on_phoneui_test_on_tabletui_test_on_foldable —を使用する android-instrumented-test 特定のデバイスタイプごとに、前のワークフローで構築されたAPKでUIテストを実行する手順。

    android_example.png

指示

新しいBitriseサンプルプロジェクトでこの構成をテストするには、次の手順を実行します。

  1. 訪問 新しいアプリページを作成する 新しいアプリを作成します。

  2. gitリポジトリを選択するように求められたら、 その他/マニュアル サンプルプロジェクトリポジトリのURLを貼り付けます(https://github.com/bitrise-io/Bitrise-Android-Modules-Sample.git) の中に Gitリポジトリ(クローン)URL 分野。

  3. 表示されるポップアップで、これがパブリックリポジトリであることを確認します。

  4. を選択 主要 スキャンするブランチ。

  5. プロジェクトスキャナーが完了するのを待ちます。

  6. 入る アプリ 指定されたモジュールとして。

  7. 入る デバッグ 指定されたバリアントとして。

  8. 通常どおりプロンプトを続行します—変更は必要ありません。

  9. 新しいBitriseプロジェクトのワークフローエディタを開きます。

  10. に移動します bitrise.yml タブをクリックし、既存のyamlの内容を例の内容に置き換えます bitrise.yml

  11. クリック ビルドの開始/スケジュール ボタンをクリックし、 ui_test_on_multiple_devices のオプション ワークフロー、パイプライン ポップアップの下部にあるドロップダウンメニュー。

bitrise.yml

GitHubリンク: https://github.com/bitrise-io/workflow-recipes/blob/main/recipes/android-parallel-ui-tests-on-multiple-devices.md#bitriseyml

(Android)ユニットテストとUIテストを並行して実行する

説明

パイプラインを利用して、単体テストとUIテストを並行して実行します。

このパイプラインには1つのステージが含まれています— stage_unit_and_ui_test —2つのワークフローを並行して実行します。

  1. unit_tests:このワークフローは、指定されたモジュールとバリアントの単体テストを、 android-unit-test ステップ。

  2. ui_tests:このワークフローは、指定されたモジュールとバリアントを使用してビルドします android-build-for-ui-testing ステップ、を使用してエミュレータを起動します avd-manager ステップ、エミュレータを使用して起動するのを待ちます wait-for-android-emulator ステップ、およびを使用してUIテストを実行します android-instrumented-test ステップ。

    android_example2.png

指示

  1. 訪問 新しいアプリページを作成する 新しいアプリを作成します。

  2. gitリポジトリを選択するように求められたら、 その他/マニュアル サンプルプロジェクトリポジトリのURLを貼り付けます(https://github.com/bitrise-io/Bitrise-Android-Modules-Sample.git) の中に Gitリポジトリ(クローン)URL 分野。

  3. 表示されるポップアップで、これがパブリックリポジトリであることを確認します。

  4. を選択 主要 スキャンするブランチ。

  5. プロジェクトスキャナーが完了するのを待ちます。

  6. 入る アプリ 指定されたモジュールとして。

  7. 入る デバッグ 指定されたバリアントとして。

  8. 通常どおりプロンプトを続行します—変更は必要ありません。

  9. 新しいBitriseプロジェクトのワークフローエディタを開きます。

  10. に移動しますbitrise.ymlタブをクリックし、既存のyamlの内容を例の内容に置き換えますbitrise.yml

  11. クリック ビルドの開始/スケジュール ボタンをクリックし、 pipeline_unit_and_ui_test のオプション ワークフロー、パイプライン ポップアップの下部にあるドロップダウンメニュー。

bitrise.yml

GitHubリンク: https://github.com/bitrise-io/workflow-recipes/blob/main/recipes/android-parallel-unit-and-ui-tests.md#bitriseyml

(Android)モジュールごとのユニットテストシャーディング

説明

パイプラインを利用した並列ワークフローで、モジュール化されたアプリの単体テストを実行します。

このパイプラインには、2つのワークフローを並行して実行する1つのステージ(stage_unit_test)が含まれています。

  1. unit_test_app:このワークフローは、を使用してアプリモジュールの単体テストを実行します android-unit-test ステップ。

  2. unit_test_library:このワークフローは、の単体テストを実行します lib-example モジュールを使用して android-unit-test ステップ。

    android_example_3.png

指示

  1. 訪問 新しいアプリページを作成する 新しいアプリを作成します。

  2. gitリポジトリを選択するように求められたら、 その他/マニュアル サンプルプロジェクトリポジトリのURLを貼り付けます(https://github.com/bitrise-io/Bitrise-Android-Modules-Sample.git) の中に Gitリポジトリ(クローン)URL 分野。

  3. 表示されるポップアップで、これがパブリックリポジトリであることを確認します。

  4. を選択 主要 スキャンするブランチ。

  5. プロジェクトスキャナーが完了するのを待ちます。

  6. 入る アプリ 指定されたモジュールとして。

  7. 入る デバッグ 指定されたバリアントとして。

  8. 通常どおりプロンプトを続行します—変更は必要ありません。

  9. 新しいBitriseプロジェクトのワークフローエディタを開きます。

  10. に移動しますbitrise.yml タブをクリックし、既存のyamlの内容を例の内容に置き換えますbitrise.yml

  11. クリック ビルドの開始/スケジュール ボタンをクリックし、を選択します pipeline_unit_test のオプション ワークフロー、パイプライン ポップアップの下部にあるドロップダウンメニュー。

bitrise.yml

GitHubリンク: https://github.com/bitrise-io/workflow-recipes/blob/main/recipes/android-parallel-testing-unit-test-shards.md#bitriseyml