確認済みの手順

検証済みの手順とは何ですか？

ステップには、特定のビルドタスクを実行するコードが含まれています。 Bitriseには300以上のステップがありますステップライブラリ（StepLib）どのサードパーティ企業またはオープンソースチームが、サービス/ツールに基づいてステップで強化できるか。これは、Bitriseがサービスの品質とセキュリティを確保するためにオーバーレイ制御を維持しながら、ステップへの更新をロールアウトするフルパワーを持っていることを意味します。

検証済みステップとは、サービスまたはツールの所有者またはオープンソースチームが、Bitriseユーザーに対して安全で維持された一貫性のある高品質のパフォーマンスを保証することを意味します。私たちの公式のビットライズステップは私たちによって維持されていますが、私たちのコミュニティステップはコミュニティによって維持されています。ステップがGUIでどのタイプに該当するかを簡単に決定できます。

確認済みの手順には、青いバッジが付いていますビットライズ。
公式のビットライズステップには、緑色のバッジが付いています。
コミュニティで作成されたステップにはバッジがありません。

このガイドでは、ステップをBitriseで検証する方法について説明します。

要件

会社所有のサービスおよびツールの場合：会社は、認証済みバッジを申請するためにステップで使用されるサービスまたはツールの所有者である必要があります。
オープンソースサービスまたはツールの場合：オープンソースまたはその他の非公式チームのメンバーである場合は、自分でこれに署名できること、およびチームに提出するステップに適用されることをチームの他のメンバーに確認してください。。
あなたのステップは私たちに従わなければなりませんサービスレベル契約。
ステップには独自のステップアイコンが必要です。
確認済みステップになるには、ステップにワークフローレシピを含める必要があります。

弊社にご相談されることを強くお勧めしますステップ開発ステップを作成する前のガイドライン。

ワークフローレシピとは何ですか？

ワークフローレシピは、Bitriseにステップを送信する人が、確認済みステップバッジを申請するときにまとめる必要があるテンプレートです。ステップを開発してワークフローレシピを含めないことを決定できますが、ステップを検証済みステップに変えるには、ワークフローレシピも送信する必要があります。

ワークフローレシピはに公開されていますビットライズここで、Bitriseコミュニティは、特定のセットアップで検証済みステップを使用する方法を学ぶことができます。

ご不明な点がございましたら、以下のパートナーシップチームにお問い合わせください。 [email protected]。

確認済みのステップを宣伝する

検証済みステッププログラムの一環として、次の共同マーケティング活動の1つまたは複数に参加することを確約する必要があります。

アプリ内メッセージング。
専用の共同ブランドの電子メールキャンペーン、またはニュースレターの言及。
ブログ投稿コンテンツ。
ハウツー記事、ドキュメント、またはヘルプセンターページ。
ソーシャルメディア活動。
ウェビナーまたは仮想イベント。
ポッドキャスト。
イベント（パネル、炉辺談話、ビデオの声、またはスポンサーシップ）。
ケーススタディ/ホワイトペーパー/電子ブック/（共有調査、紹介文、章の共同執筆、お互いのブログへの公開）。
YouTubeの公開チャンネルに投稿されたビデオコンテンツ。
共同PRキャンペーン。

これらの共同マーケティングの機会により、製品のコンテンツ生成出力を増やし、市場開拓計画を拡大し、統合の採用を促進することができます。

Bitriseパートナーマネージャーに相談することができます（[email protected]）どの共同マーケティング活動を実行できるかを確認し、マーケティング計画に基づいてどのレベルの関与を行いたいかを明確にします。単一の共同マーケティングイベントに関心を持つ人が多いため、参加は先着順で管理されます。

確認済みバッジの申請

私たちに基づいてステップを作成しますステップ開発ガイドライン。ステップのリポジトリはGitHub上にある必要があります。
私たちのステップを共有する bitrise-steplib 新しいプルリクエストチェックリストに記入します。
いつ CLAアシスタント プロンプトが表示されたら、Contributor LicenseAgreementに署名します。これが完了するまで、マージはPRでブロックされます。
記入してくださいパートナーシップフォーム！

フォームを送信すると、パートナー管理チームから5営業日以内に連絡があり、残りのプロセスについて話し合います。

プロセスのいずれかの段階で、StepLibの別のステップですでにカバーされているステップ候補で何が起こるのか疑問に思った場合は、ステップ複製についてはどうすればよいですか？

検証済みステップの作成者向けのサービスレベル契約

課題またはプルリクエスト（PR）を作成することにより、誰でもすでにStepLibの一部である検証済みステップに貢献できます。検証済みステップの作成者は、最初から最後まで貢献（たとえば、問題、PR、またはサードパーティのシステム変更などのメンテナンス）を管理する必要があります。 Bitriseは、検証済みステップ用に作成された未解決の問題とPRを監視し、それらの貢献が処理されない場合は検証済みステップの作成者に連絡します。検証済みステップの作成者が貢献者ライセンス契約およびこのSLAに記載されているように貢献を管理できない場合、Bitriseは検証済みバッジをステップから撤回します。これは、StepLibの検証済みステップが常に高品質であり、Bitriseユーザーの期待に応えるためです。

貢献の管理

次のガイドラインは、検証済みステップの作成者が投稿を分類できるようにすることを目的としています。検証済みステップの作成者は、検証済みステップへの貢献に対して責任を負います。検証済みステップの作成者は、修正を実行するための推定時間をラベルに追加し、PRをマージすることにより、貢献を認めます。著者が投稿の種類を分類するために使用できるラベルは4つあります。

critical-bug ラベルは、現在の機能セットに異常な動作があることを意味します。これにより、ユーザーはステップを使用できなくなり、問題を修正するための回避策はありません。この重大なバグは、作成者が修正する必要があります。
bug ラベルは、現在の機能セットに異常な動作があることを意味します。これにより、ユーザーはステップを使用できなくなり、問題の回避策があります。このバグは作者が修正する必要があります。
feature-request ラベルは、新しい機能またはステップが要求されていることを意味します。検証済みステップの作成者は、機能を実装する価値があるかどうかを判断できます。
maintenance ラベルとは、ステップに新しい機能や潜在的なバグを追加しないように、ステップのソースコードを改善することを意味します。検証済みステップの作成者は、機能を実装する価値があるかどうかを判断できます。
rejected ラベルは、確認済みステップの作成者によって拒否された投稿は、最初の応答時間、つまり5営業日以内にクローズする必要があることを意味します。投稿を拒否する場合、検証済みステップの作成者は、最初の応答時間内に投稿者に説明を提供する必要があります。
accepted 貢献とは、指定された：重大-バグ、バグ、機能、メンテナンスが指定された解決時間内に修正/マージされることを意味します。

最初の応答時間とは、検証済みステップの作成者が承認または拒否されたラベルを使用して投稿に応答する必要がある5日間のウィンドウがあることを意味します。

解決時間とは、検証済みステップの作成者がコントリビューション（発行またはPR）を完了する必要がある一定の営業日を意味します。

タイプ	最初の応答時間	解決時間
クリティカルバグ	5営業日	10営業日
バグ	5営業日	15営業日
機能リクエスト	5営業日	20営業日
メンテナンス	5営業日	20営業日

ステップの重複についてはどうすればよいですか？

一般に、StepLibを合理化して、同じビルドタスクでのステップの重複を回避しようとします。ここでは、潜在的なステップの重複に関して、いくつかの質問と回答を見つけることができます。

ステップを送信して確認済みバッジを申請しようとしましたが、StepLibに同じビルドタスクの公式ビットライズステップがあることがわかりました。私は何をすべきか？

ステップを送信して、申請プロセスを実行します。アプリケーションが完了すると、公式のBitriseステップは廃止され、ユーザーは新しい確認済みステップを使用できるようになります。

ステップを送信して確認済みバッジを申請しようとしましたが、同じビルドタスクにコミュニティステップがあることがわかりました。私は何をすべきか？

ステップを送信して、申請プロセスを実行します。新しい確認済みステップとコミュニティステップは、どちらもStepLibで利用できます。

コミュニティステップを送信しようとしましたが、同じビルドタスクに検証済みステップがあることがわかりました。私は何をすべきか？

検証済みステップがすでにStepLibで使用可能な場合、ステップの重複を避けるために、同じビルドタスクに対するコミュニティステップの送信を拒否します。コミュニティステップの開発者に、既存の検証済みステップの将来の更新に取り組むことを提案します。