Skip to main content

確認済みの手順

概要

検証済みステップは、所有者がBitriseユーザーに対して安全で、維持され、一貫性があり、高品質のパフォーマンスを保証するBitriseステップです。ステップを確認するには、確認済みバッジを申請する必要があります。

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

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

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

  • 確認済みの手順には、青いバッジが付いています ビットライズ。

  • 公式のビットライズステップには、緑色のバッジが付いています。

  • コミュニティで作成されたステップにはバッジがありません。

Verified Steps

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

貢献の管理

次のガイドラインは、検証済みステップの作成者が投稿を分類できるようにすることを目的としています。検証済みステップの作成者は、検証済みステップへの貢献に対して責任を負います。検証済みステップの作成者は、修正を実行するための推定時間をラベルに追加し、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 の一般的なタスクを実行するためのベストプラクティス

  • ステップのインプットとアウトプット、ステップのチェーニングのベストプラクティス

  • ステップエラーのトラブルシューティング。

このセクションの内容: