クレジット使用量
この記事は、クレジットベース(分単位課金)のサブスクリプションプランをご利用の場合にのみ関連します 。クレジットベースのプランを利用していないユーザーには、InsightsのCreditsページは表示されません。
クレジット使用量を注視することで、クレジット使用量の増加につながる変更による予期せぬ事態を避けやすくなります。Bitrise Insightsを使用すると、クレジット使用量の傾向を確認でき、悪化傾向に気づいた場合はInsightsを使ってその原因を突き止めることができます。
クレジット使用量全体を追跡するClick to copy link
Bitrise Insightsを開くと、最初に Overview ページが表示されます。
Credit usageセクションまでスクロールすると、Workspaceの全体的なクレジット使用量と、クレジットを最も多く消費しているtop 5のアプリを確認できます。
クレジット使用量を予測したい場合は、左サイドバーの EXPLORE セクションにある Credits オプションをクリックするか、Credit usage セクションの View details ボタンをクリックして、Credits ページに切り替えてください。
Credits ページでは、デフォルトで過去12週間(3か月)のクレジット使用量の傾向が週単位で表示されます。使用するクレジット量を予測するには、いくつかの方法があります。
月次表示に切り替えると、過去6か月のクレジット使用量、クレジット使用量の傾向、および今月のこれまでの使用量を確認できます。
あるいは、日次表示(Last 30 days)に切り替え、チャートを Cumulative に変更することで、過去30日間に使用したクレジット量とその傾向を確認することもできます。
傾向が比較的安定している場合(大きな増減がない場合)は、左上の Credit usage に表示されている過去30日間の使用量とほぼ同程度のクレジットを今後も使用する可能性が高いです。
この日次表示を月次表示と比較することで、その月に見込まれるクレジット使用量や、過去の月のクレジット使用量との比較について、良い指針が得られるはずです。
アプリ、Workflow、またはStep別のクレジット使用量Click to copy link
左サイドバーの EXPLORE セクションにある Creditsページ を開きます。まだ週次表示になっていない場合は、過去12週間の週次表示に切り替えることもできます。
他のExploreページと同様に、2つのチャートが表示されます。上のチャートには、設定したフィルターに対応するデータが常に表示されます。下のチャートはブレイクダウンチャートと呼ばれ、フィルターした項目よりも1段階詳細なデータが表示されます。
Workspace内にアプリが1つしかない場合、Exploreのいずれかのページを開くと、Insightsはそのアプリを自動的に選択します。Workspace内に複数のアプリがある場合、Credits ページを開くと、上のチャートにはWorkspace内のすべてのアプリにわたるWorkspaceの全体的なクレジット使用量が表示されます。
この場合、下のチャートには同じデータがアプリ単位で表示されます。これにより、選択した期間内でどのアプリが最もクレジットを多く使用したかを確認できます。
ここでブレイクダウンチャートを見ると、このWorkspaceで最もクレジットを多く使用したアプリケーションがあることが分かります。そのアプリにフィルターを絞り込むと、次のレベルでWorkflow別の内訳が確認できます。
これで上のチャートにはフィルターした内容、つまりこの場合は選択したアプリのクレジット使用量が表示されます。下のブレイクダウンチャートでは、最もクレジットを使用したWorkflowを確認できます。
そのWorkflowにフィルターを絞り込んでみましょう。
これでチャートにはこのフィルタリングが反映され、Workflowのクレジット使用量の傾向が表示されます。
ここから、このWorkflowでクレジット使用量が増加している原因を突き止める必要があります。これは、ビルドの速度低下、ビルド数の増加、または1分あたりの消費クレジットが多いマシンタイプへの変更などが原因となっている可能性があります。
これを調査するには、Builds ページに切り替えます。他のExploreページに切り替えても、以前に選択したフィルターが引き継がれるため、同じアプリとWorkflowを再度選択する必要はありません。この場合、メトリクスタブを確認すると、この期間中ほとんどのメトリクスは安定しているようですが、Total duration メトリクスでも似たようなパターンが見られます。
Credits ページと同様に、Builds ページにも2つのチャートがあります。上のチャートには、該当するフィルター(選択したアプリとWorkflowに対する)の選択したメトリクス(この場合は Total duration)が表示されます。
下のブレイクダウンチャートには、ビルド合計時間のステップ別の内訳が表示されます。これにより、iOS Device Testing Step が最も時間がかかっており、それが全体的な傾向とも一致していることが分かります。
ビルド時間とビルド数は12週間を通して一定であり、この期間中に変化があったもう1つのメトリクスは Failure rate だけだったため、そのタブに切り替えてみましょう。
ここから分かるのは、クレジット使用量とtotal durationの両方が低下していた期間において、iOS Device Testing Step の失敗率が100%だったということです。失敗したStepsは通常完了までの時間が短いため、チャートの下にある Related builds セクションでrelated buildsも確認してみましょう。
該当するビルドを見つけるために、失敗率が上昇した期間を拡大表示します。最も簡単な方法は、チャート上でクリックしたままドラッグすることです。
Related builds セクションでも、この単一のStepにフィルターを絞り込んでみましょう。
これでビルド履歴をスクロールして、このStepのビルド時間がどのように変化したかを確認できます。失敗率が100%だった期間の終わりには、わずか数秒しかかかっていないことが分かります。
さらにスクロールを続けると、ビルドがまだ成功していた12月初旬には、Stepの完了に数分かかっていたことが分かります。
つまりこの場合、total duration(およびクレジット)の低下は、このStepが頻繁に失敗していたことが原因で、そのためビルドはより短時間で完了していました。テストの問題が修正されると、Stepとビルドは再び完了までに時間がかかるようになりましたが、実際にテストを実行して完了できるようになりました。
定期的に確認する価値があるもう1つの場所は、Bottlenecks ページです。
このページには Credits セクションがあり、Bitrise Insightsが最もクレジットを消費した悪化傾向をハイライト表示します。
失敗したWorkflow では、失敗したビルドでクレジット使用量が多かったWorkflowsが表示されます。上記の例では、testという名前のWorkflowが過去7日間で73.68%の確率で失敗しており、それらの失敗したビルドは合計624クレジットを消費したことが分かります。
Build timeでは、過去7日間のビルドがその前の7日間よりも時間がかかるようになったビルド速度低下の傾向が表示され、その悪化傾向によるクレジットへの影響も分かります。
Usage ボトルネックでは、過去7日間で最もクレジットを消費したWorkflowsが単純にリスト表示されます。
これらのボトルネック項目のいずれかをクリックすると、Workflowに絞り込まれた該当のExploreページが開きます。