Verified Steps
Verified StepsについてClick to copy link
Stepには、特定のビルドタスクを実行するコードが含まれています。BitriseのStep Library(StepLib)には400以上のStepsがあり、サードパーティ企業やオープンソースチームが自社のサービスやツ ールに基づいてStepsを追加できます。つまり、彼らはStepの更新を自由にロールアウトできますが、Bitriseはサービス品質とセキュリティを確保するための管理を維持しています。
Verified Stepとは、サービスやツールの所有者、またはオープンソースチームが、すべてのBitriseユーザーに対して安全でメンテナンスが行き届いた、一貫性のある高品質なパフォーマンスを保証していることを意味します。公式のBitrise Stepsは弊社がメンテナンスを行い、Community Stepsはコミュニティがメンテナンスを行います。GUI上でStepがどちらのタイプに該当するかは簡単に判断できます。
- Verified StepsにはBitriseで青いバッジが付いています。
- 公式のBitrise Stepsには緑のバッジが付いています。
- コミュニティが作成したStepsにはバッジが付いていません。
Stepを作成する前に、Step 開発 ガイドラインを参照することを強くお勧めします。
コントリビューションの管理Click to copy link
以下のガイドラインは、Verified Stepの作者がコントリビューションを分類する際に役立つことを目的としています。Verified Stepの作者は、Verified Stepに対して行われたあらゆるコントリビューションに責任を負います。Verified Stepの作者は、ラベルを追加して修正の見積もり時間を示し、PRをマージすることでコントリビューションを承認します。作者はコントリビューションの種類を分類するために、以下の4つのラベルを使用できます。
critical-bugラベルは、現在の機能セットに異常な動作があり、ユーザーがStepを使用できなくなっていて、その問題を回避する方法がないことを意味します。この重大なバグは作者が修正する必要があります。bugラベルは、現在の機能セットに異常な動作があるものの、ユーザーがStepを使用できなくなるわけではなく、その問題に対する回避策があることを意味します。このバグは作者が修正する必要があります。feature-requestラベルは、新機能またはStepがリクエストされていることを意味します。Verified Stepの作者は、その機能を実装する価値があるかどうかを判断できます。maintenanceラベルは、Stepのソースコードを、Stepに新機能や潜在的なバグを追加しない形で改善することを意味します。Verified Stepの作者は、その機能を実装する価値があるかどうかを判断できます。rejectedラベルは、Verified Stepの作者によって却下されたコントリビューションは、初回応答時間である5営業日以内にクローズする必要があることを意味します。コントリビューションを却下する場合、Verified Stepの作者は初回応答時間内にコントリビューターへ説明を提供する必要があります。acceptedコントリビューションとは、該当するcritical-bug、bug、feature、maintenanceが、指定された解決時間内に修正/マージされることを意味します。
初回応答時間とは、Verified Stepの作者がコントリビューションに対してacceptedまたはrejectedのラベルで応答すべき5日間の期間を意味します。
解決時間とは、コントリビューション(issueまたはPR)がVerified Stepの作者によって完了されるべき一定の営業日数を意味します。
| 種類 | 初回応答時間 | 解決時間 |
|---|---|---|
| critical-bug | 5営業日 | 10営業日 |
| bug | 5営業日 | 15営業日 |
| feature-request | 5営業日 | 20営業日 |
| maintenance | 5営業日 | 20営業日 |
Stepの重複にどう対応していますか?Click to copy link
一般的に、StepLibを整理された状態に保ち、同じビルドタスクに対するStepの重複を避けるよう努めています。ここでは、Stepの重複の可能性に関するいくつかの質問と回答を紹介します。
- Stepを提出してVerifiedバッジを申請しようとしていたのですが、StepLibに同じビルドタスク用の公式のBitrise Stepが既に存在することがわかりました。どうすればよいですか?
Stepを提出し、申請プロセスを進めてください。申請が完了すると、公式のBitrise Stepは非推奨となり、ユーザーは新しいVerified Stepを使用 できるようになります。
- Stepを提出してVerifiedバッジを申請しようとしていたのですが、同じビルドタスク用のCommunity Stepが既に存在することがわかりました。どうすればよいですか?
Stepを提出し、申請プロセスを進めてください。新しいVerified StepとCommunity Stepの両方がStepLibで利用可能になります。
- Community Stepを提出しようとしていたのですが、同じビルドタスク用のVerified Stepが既に存在することがわかりました。どうすればよいですか?
StepLibにVerified Stepが既に存在する場合、Stepの重複を避けるため、同じビルドタスクに対するCommunity Stepの提出は却下されます。その代わり、Community Stepの開発者には、既存のVerified Stepの今後のアップデートに携わっていただくことを提案します。
verified Stepのメンテナーへのお願いClick to copy link
verified Stepのメンテナーには、以下のベストプラクティスに従っていただくようお願いしています。
- Stepのリポジトリでユーザーが起票したissueを監視し、適時に対応してください。
- Stack 更新ポリシー、特に破壊的変更の頻度について理解しておいてください。Stepは(意図的か否かにかかわらず)スタック環境のツールに依存している場合があり、スタックの更新後にStepsが壊れることは望んでいません。
- Stepsを、利用可能なすべてのスタックとプラットフォームで定期的にテストしてください。スケジュールビルドと、ビルド失敗時の何らかの通知を備えたCIワークフローを設定することをお勧めします。
Step関連の質問について何かサポートが必要な場合は、お気軽にお問い合わせください。例えば、次のようなことでお手伝いできます。
- Stepsで一般的なタスクを実行するためのベストプラクティス
- Step inputsと出力のベストプラクティス、Stepsの連携
- Stepエラーのトラブルシューティング