確認済みの手順
検証済みステップは、所有者がBitriseユーザーに対して安全で、維持され、一貫性があり、高品質のパフォーマンスを保証するBitriseステップです。ステップを確認するには、確認済みバッジを申請する必要があります。
検証済みの手順とは何ですか?
ステップには、特定のビルドタスクを実行するコードが含まれています。 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をマージすることにより、貢献を認めます。著者が投稿の種類を分類するために使用できるラベルは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で使用可能な場合、ステップの重複を避けるために、同じビルドタスクに対するコミュニティステップの送信を拒否します。コミュニティステップの開発者に、既存の検証済みステップの将来の更新に取り組むことを提案します。
検証済みの Step メンテナーへの要望
検証済みの Step メンテナーには、以下のベストプラクティスに従うようお願いしています。
-
Step リポジトリ内のユーザーが開いた問題を監視し、タイムリーに対応します。
-
私たちのことをよく理解してください スタックの更新ポリシー特に、重大な変更の頻度について。Step が (誤って、または意図的に) スタック環境のツールに依存している可能性があり、スタックの更新後にステップが壊れてしまうのは避けたいものです
-
利用可能なすべてのスタックとプラットフォームで定期的にステップをテストしてください。CI ワークフローは、スケジュールされたビルドと、ビルドが失敗した場合に何らかの通知を受け取るように設定することをおすすめします
STEP関連の質問についてサポートが必要な場合は、お気軽にお問い合わせください。たとえば、次のようなことを喜んでお手伝いします
-
Steps の一般的なタスクを実行するためのベストプラクティス
-
ステップのインプットとアウトプット、ステップのチェーニングのベストプラクティス
-
ステップエラーのトラブルシューティング。