mcpField
T
The Standard Practices

The Standard Practices

github.com/hassanhabib開発2072 回インストール13 週間前に更新
リポジトリ

The Standard Practices について

The Standard Practicesは、コントリビューターやメンテナー向けのチーム運営スキルです。リポジトリ構成、ブランチ、コミット、レビュー、設定、開発指標の規約を示し、ブランチ命名や単一操作の範囲も定めます。

主な機能

  1. 01コード貢献とプロジェクト構成の指針
  2. 02ブランチ戦略と命名規約
  3. 03コミットとプルリクエストの規則
  4. 04FAIL／PASSのテスト規律
  5. 05設定、環境変数、シークレットの管理
  6. 06開発指標と貢献者の成長

活用シーン

  1. 01リポジトリの共同作業手順の計画
  2. 02作業ブランチの選定と命名
  3. 03コミットとプルリクエストの準備
  4. 04環境設定と機密情報の保護

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/hassanhabib/the-standard-skills --skill the-standard-practices

インストール後、Claude Code で/the-standard-practicesを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

manifest.json
contracts/
contracts.json
examples/bad/
example_bad_branches.md
example_bad_commits.md
examples/good/
example_commit_messages.md
example_branch_names.md
rules/
rules.json
rules.md
templates/
branch_naming_guide.md
pull_request_template.md
validations/
anti-patterns.md
checklist.md

詳細

標準のプラクティス

このスキルについて

このスキルは、The Standard におけるチームプロセス、コントリビューション、プロジェクト規律のレイヤーです。 作業の編成、命名、コミット、レビュー、設定、測定、継続的な成長の方法を定めます。

対象範囲の明示的な一覧

このスキルでは、以下を明示的に扱います。

  • コードのコントリビューション
  • フォーク／クローン／ブランチ作成
  • ブランチの命名規則
  • カテゴリーシステム
  • プロジェクト／ソリューションの構成
  • コミット戦略
  • FAIL／PASS の規律
  • プルリクエストの規約
  • 設定の取り扱い
  • 環境変数とシークレット
  • GitHub Actions の設定ガイダンス
  • 測定指標
  • コントリビューションポイント
  • 平均実装時間
  • ランク
  • プロジェクトの実装仕様とともに提供される、拡張版の実装仕様プラクティスセクション

使用するタイミング

作業の計画、ブランチの命名、リポジトリの整理、コミットの作成、プルリクエストの作成、環境の設定を行う際は、いつでもこのスキルを使用してください。

必須の運用ルール

  1. コントリビューションは構造化する必要があります。
  2. ブランチには意図を持った名前を付ける必要があります。
  3. コミットでは、実際の作業単位を伝える必要があります。
  4. TDD の作業では、FAIL／PASS の規律に従う必要があります。
  5. プルリクエストでは、Standard のカテゴリー命名規則を使用する必要があります。
  6. 機密性の高い設定をプレーンテキストでチェックインしてはいけません。
  7. 測定指標は、見栄えのためではなく、エンジニアとしての成長と公平性のためのものです。

標準的なプラクティス

4. プラクティス

コードのコントリビューション、ブランチ、コミット戦略、プロジェクト構成についてプラクティスを定めることは、あらゆるソフトウェア開発プロジェクトに不可欠です。 こうしたプラクティスにより、コードベースを管理するための明確で一貫した手法が確立され、コントリビューションを統制の取れた整理された方法で行えるようになります。 これにより、混乱や衝突を避け、コードベースの安定性と保守性を維持できます。 さらに、コードのコントリビューションとプロジェクト構成について十分に定義されたプラクティスは、開発チーム内のコラボレーションとコミュニケーションの改善にも役立ち、変更の追跡とレビュー、問題の特定と解決を容易にします。 総じて、コードのコントリビューション、ブランチ作成、コミット戦略、そしてプロジェクト構成に関するプラクティスを定めることは、ソフトウェア開発プロジェクトの成功に欠かせません。

プラクティスでは、次の主な側面を検討する必要があります。

  1. コードのコントリビューション
    1. フォーク／クローンとブランチ作成
    2. プロジェクト構成
    3. コミット
    4. プルリクエスト

The Standard Team は、前述の各項目のあらゆる側面を明確に理解し、定義する必要があります。

4.1 コードのコントリビューション

コントリビューションガイドラインを定めることは、オープンソースまたは共同で行うソフトウェア開発プロジェクトに不可欠です。 コントリビューターが変更を提出し、レビューする方法について明確なルールと期待事項を定めることで、すべてのコントリビューションを一貫性のある整理された方法で行えるようになります。 また、コントリビューションガイドラインでは、コーディング、テスト、ドキュメント作成のベストプラクティスを案内できるため、コードベース全体の品質向上にも役立ちます。 さらに、新しいコントリビューターに必要な情報や、プロジェクトに効果的に貢献するための手順を示す教育ツールとしても機能します。 （加えて、十分に定義された GitHub のコントリビューションガイドラインがあれば、新しいコントリビューターを引き付け、健全なオープンソースコミュニティを維持しやすくなります。）

4.1.1 フォークとブランチの戦略

コードのブランチ戦略は、安定して保守しやすいコードベースを維持するうえで不可欠です。 複数の開発者が互いの作業に干渉せず、異なる機能やバグ修正に同時に取り組めるようになります。 各開発者は作業用のブランチを作成でき、レビューと承認を経た後、メインブランチにマージできます。 これにより、競合を防ぎ、コードベースの安定性と一貫性を保つことができます。 さらに、ブランチ戦略を導入するとバージョン管理が可能になり、コードベースの異なるバージョンを作成して追跡できます。 これは、必要に応じて変更をロールバックしたり、異なる環境向けにソフトウェアの複数のバージョンを維持したりする際に役立ちます。 全体として、ブランチ戦略はあらゆるソフトウェア開発プロジェクトにとって重要な要素であり、コードベースの安定性と保守性を保つために不可欠です。

ソフトウェア開発では、次のようなさまざまなブランチ戦略を使用できます。

  1. Gitflow：厳格なブランチモデルに従う、広く使われているブランチ戦略です。機能開発はフィーチャーブランチで行い、メインの開発ブランチにマージします。この戦略は、多数のコントリビューターが参加する大規模なプロジェクトに適しています。

  2. トランクベース開発：メインブランチ、つまりトランク上で作業し、変更を直接コミットする戦略です。コントリビューターの数が少ない小規模なプロジェクトに適しています。

  3. フィーチャーブランチ：機能やバグ修正ごとに個別のブランチを作成し、完了したらメインブランチにマージする戦略です。複数のコントリビューターが参加する大規模なプロジェクトに適しています。

  4. フォーク：リポジトリのコピーを作成し、別々に作業する戦略です。同じコードベースに複数のコントリビューターが取り組むオープンソースプロジェクトに適しています。フォークワークフローの主な利点は、全員が単一の中央リポジトリにプッシュしなくても、コントリビューションを統合できることです。開発者はサーバー側の自分のリポジトリにプッシュし、公式リポジトリにプッシュできるのはプロジェクトのメンテナーだけです。これにより、公式コードベースへの書き込み権限を与えることなく、メンテナーはどの開発者からのコミットも受け入れられます。

  5. リリースブランチ：リリースごとに個別のブランチを作成し、リリースの準備が整ったらメインブランチにマージする戦略です。定期的なリリーススケジュールがあるプロジェクトに適しています。

  6. 継続的インテグレーション：コード変更を行うたびにマージし、コードベースの安定性を保つために自動テストを実行する戦略です。変更頻度の高いプロジェクトに適しています。

最終的には、プロジェクトのニーズと制約に合致し、すべてのコントリビューターが容易に理解して従えるブランチ戦略を選ぶことが重要です。

4.1.1.1 オープンソース開発

The Standard はオープンソースの取り組みを推進しているため、フォーク戦略を簡単に見てみましょう。

仕組み

フォークワークフローは、サーバーに保存された公式の公開リポジトリから始まります。新しい開発者がプロジェクトに取り組み始める場合、公式リポジトリを直接クローンすることはありません。

その代わりに、公式リポジトリをフォークして、そのコピーを作成します。この新しいコピーが、個人用の公開リポジトリとなります。
サーバー側にコピーを作成した後、開発者は git clone を実行して、ローカルマシンにコピーを取得します。
これは、ほかのワークフローと同様に、プライベートな開発環境として機能します。

ローカルのコミットを公開する準備ができたら、自分の公開リポジトリ（公式リポジトリではありません）にコミットをプッシュします。
次に、メインリポジトリにプルリクエストを作成します。これにより、プロジェクトのメンテナーに更新を取り込む準備ができたことが通知されます。
プルリクエストはレビューでき、コントリビュートされたコードに問題がある場合は、便利なディスカッションスレッドとしても機能します。

以下は、このワークフローの手順を示す例です。

  1. 開発者が「公式」のサーバー側リポジトリを「フォーク」します。これにより、独自のサーバー側コピーが作成されます。
  2. 新しいサーバー側コピーをローカルシステムにクローンします。
  3. 新しいローカルの機能ブランチを作成します。
  4. 開発者が新しいブランチで変更を加えます。
  5. 変更を含む新しいコミットを作成します。
  6. ブランチを開発者自身のサーバー側コピーにプッシュします。
  7. 開発者が新しいブランチから「公式」リポジトリにプルリクエストを作成します。
  8. プルリクエストをレビューし、ビルドの成功とテストの結果を確認します。この時点で、メンテナーは変更をリクエストするか、マージを承認できます。承認された場合、変更は元のサーバー側リポジトリにマージされます。
4.1.1.2 ブランチ名の規則

ブランチ名には、次の命名規則を適用できます。users/[username]/[category]-[entity]-[action]

変数は次のように置き換えます。

  • [username] => GitHub のユーザー名
  • [category] => 作業対象のカテゴリ
  • [entity] => サービス／ブローカーが使用するエンティティ
  • [action] => アクション — 作業対象のレイヤーの言語に合わせる必要があります
レイヤーごとのブランチアクションの言語

[action] セグメントには、一般的な説明ではなく、レイヤー固有の語彙を使用します。

レイヤー正しいアクション誤ったアクション
BROKERSinsert、select-all、select-by-id、update、deleteadd、retrieve、modify、remove
FOUNDATIONSadd、retrieve-all、retrieve-by-id、modify、removeinsert、select、update、delete
PROCESSINGSensure、upsert、try-add、try-removeインフラストラクチャ関連の動詞
INFRA、DATA、CONFIGcreate、setup、update、remove（厳格な言語上の制約なし）

例：

# Correct — infrastructure verb for a BROKERS branch
users/hassanhabib/BROKERS-student-insert
users/hassanhabib/BROKERS-student-select-all
users/hassanhabib/BROKERS-student-select-by-id
users/hassanhabib/BROKERS-student-update
users/hassanhabib/BROKERS-student-delete

# Correct — business verb for a FOUNDATIONS branch
users/hassanhabib/FOUNDATIONS-student-add
users/hassanhabib/FOUNDATIONS-student-retrieve-all
users/hassanhabib/FOUNDATIONS-student-modify

# Wrong — business verb in a BROKERS branch
users/hassanhabib/BROKERS-student-add        ← should be 'insert'
users/hassanhabib/BROKERS-student-retrieve   ← should be 'select-by-id' or 'select-all'
ブランチごとに1つの操作

各ブランチは単一の操作を表します。プロンプトの範囲が曖昧な場合 （例：「Student 用のストレージブローカーを構築する」）、エージェントはブランチを作成したりコードを書いたりする前に、実装する操作を確認する必要があります。すべての CRUD を作成すると決めつけてはいけません。

Ambiguous prompt:  "Build a storage broker for Student"
Required response: "Which operation should this branch implement?
                   insert / select-all / select-by-id / update / delete"
4.1.1.3 カテゴリ一覧
カテゴリ説明
INFRA初期プロジェクトのセットアップ、ビルドプロジェクト／ビルドスクリプトの作成。
MAJOR INFRA大規模な更新。単純な設定やファイルの削除または追加。
MEDIUM INFRA中規模の更新。単純な設定やファイルの削除または追加。
MINOR INFRA小規模な更新。単純な設定やファイルの削除または追加。
PROVISIONSプロビジョニングプロジェクト／スクリプトの作成。
RELEASESソフトウェアをリリースするためのインフラ作業。
DATAデータモデルの作成（EF を使用する場合はそのマイグレーションも含む）。
MAJOR DATA既存のデータモデルに対する、5 つ以上のプロパティの追加／変更を伴う変更。
MEDIUM DATA既存のデータモデルに対する、3～4 つのプロパティの追加／変更を伴う変更。
MINOR DATA既存のデータモデルに対する、1～2 つのプロパティの追加／変更を伴う変更。
MIGRATIONあるシステムから別のシステムへのデータの移動または変換、既存データの更新、レポートの生成。
MAJOR MIGRATION大量のデータや複雑さを伴う、大規模なデータマイグレーションまたは変換作業。
MEDIUM MIGRATION中程度のデータ量または作業量を伴う、中程度の複雑さのデータマイグレーションまたは更新。
MINOR MIGRATION複雑さが低い、またはデータ量が少ない、小規模なデータマイグレーションまたは単純なデータ更新。
BROKERS外部ライブラリ、リソース、サービス、API をラップするブローカーを作成する場合。
MAJOR BROKERS既存のブローカーに対する大規模な変更（機能の大幅な変更）。
MEDIUM BROKERS既存のブローカーに対する中規模の変更（複数の重要な変更）。
MINOR BROKERS既存のブローカーに対する小規模な変更（単純な変更）。
FOUNDATIONSFoundation Service を作成する場合。
MAJOR FOUNDATIONS既存の foundation service に対して、5 件以上のテストをすべて作成または更新する変更。
MEDIUM FOUNDATIONS既存の foundation service に対して、3～4 件のテストを作成または更新する変更。
MINOR FOUNDATIONS既存の foundation service に対して、1～2 件のテストを作成または更新する変更。
PROCESSINGSProcessing Service を作成する場合。
MAJOR PROCESSINGS既存の processing service に対して、5 件以上のテストをすべて作成または更新する変更。
MEDIUM PROCESSINGS既存の processing service に対して、3～4 件のテストを作成または更新する変更。
MINOR PROCESSINGS既存の processing service に対して、1～2 件のテストを作成または更新する変更。
ORCHESTRATIONSOrchestration Service を作成する場合。
MAJOR ORCHESTRATIONS既存の orchestration service に対して、5 件以上のテストをすべて作成または更新する変更。
MEDIUM ORCHESTRATIONS既存の orchestration service に対して、3～4 件のテストを作成または更新する変更。
MINOR ORCHESTRATIONS既存の orchestration service に対して、1～2 件のテストを作成または更新する変更。
COORDINATIONSCoordination Service を作成する場合。
MAJOR COORDINATIONS既存の coordination service に対して、5 件以上のテストをすべて作成または更新する変更。
MEDIUM COORDINATIONS既存の coordination service に対して、3～4 件のテストを作成または更新する変更。
MINOR COORDINATIONS既存の coordination service に対して、1～2 件のテストを作成または更新する変更。
MANAGEMENTSManagement Service を作成する場合。
MAJOR MANAGEMENTS既存の management service に対して、5 件以上のテストをすべて作成または更新する変更。
MEDIUM MANAGEMENTS既存の management service に対して、3～4 件のテストを作成または更新する変更。
MINOR MANAGEMENTS既存の management service に対して、1～2 件のテストを作成または更新する変更。
AGGREGATIONSAggregation Service を作成する場合。
MAJOR AGGREGATIONS既存の aggregation service に対して、5 件以上のテストをすべて作成または更新する変更。
MEDIUM AGGREGATIONS既存の aggregation service に対して、3～4 件のテストを作成または更新する変更。
MINOR AGGREGATIONS既存の aggregation service に対して、1～2 件のテストを作成または更新する変更。
CONTROLLERSController を作成する場合。
MAJOR CONTROLLERS既存の controller に対して、5 件以上のテストをすべて作成または更新する変更。
MEDIUM CONTROLLERS既存の controller に対して、3～4 件のテストを作成または更新する変更。
MINOR CONTROLLERS既存の controller に対して、1～2 件のテストを作成または更新する変更。
CLIENTS他者が使用できるライブラリにクライアントを作成する場合。
MAJOR CLIENTS既存のクライアントに対して、5 件以上のテストを作成または更新する変更。
MEDIUM CLIENTS既存のクライアントに対して、3～4 件のテストを作成または更新する変更。
MINOR CLIENTS既存のクライアントに対して、1～2 件のテストを作成または更新する変更。
PROVIDERS他者が使用できる SPAL provider library にプロバイダーを作成する場合。
EXPOSERSProgram.cs など、その他の種類のエクスポーザーを作成する場合。
MAJOR EXPOSERS
MEDIUM EXPOSERS
MINOR EXPOSERS
VIEWSView Service を作成する場合。
MAJOR VIEWS既存のビューに対して、5 件以上のテストをすべて作成または更新する変更。
MEDIUM VIEWS既存のビューに対して、3～4 件のテストを作成または更新する変更。
MINOR VIEWS既存のビューに対して、1～2 件のテストを作成または更新する変更。
BASESフロントエンドのベースコンポーネントを作成する場合。
MAJOR BASES
MEDIUM BASES
MINOR BASES
COMPONENTSコンポーネントを作成する場合。
MAJOR COMPONENTS既存のコンポーネントに対して、5 件以上のテストをすべて作成または更新する変更。
MEDIUM COMPONENTS既存のコンポーネントに対して、3～4 件のテストを作成または更新する変更。
MINOR COMPONENTS既存のコンポーネントに対して、1～2 件のテストを作成または更新する変更。
PAGESBlazor ページを作成する場合。
MAJOR PAGES
MEDIUM PAGES
MINOR PAGES
ACCEPTANCE受け入れテストを作成する場合。
MAJOR ACCEPTANCE
MEDIUM ACCEPTANCE
MINOR ACCEPTANCE
INTEGRATION統合テストを作成する場合。
MAJOR INTEGRATION
MEDIUM INTEGRATION
MINOR INTEGRATION
CODE RUBスタイル、コードのフォーマット、スペルなどを修正する小規模な変更（バグ修正には使用しない）。
MAJOR CODE RUB複数のファイルに影響する、大規模なコードクリーンアップ。
MEDIUM CODE RUB複数のファイルに影響する、中規模のコードクリーンアップ。
MINOR CODE RUB少数のファイルに影響する、小規模なコードクリーンアップ。
MINOR FIXプログラム全体の機能を大きく変えない、小規模なバグ修正／変更。
MEDIUM FIXプログラムまたはシステムの機能やパフォーマンスに中程度の影響を与える修正。
MAJOR FIXソフトウェアプログラムまたはシステムの重大な問題に対処する、大規模なバグ修正。
DOCUMENTATION一般的なドキュメント。
CONFIGさまざまな環境向けの appsettings.json の設定など、あらゆる設定変更。
REVIEWプロジェクトの標準および規格への準拠という観点から、提出された作業をレビューすること。
STANDARDThe Standard に新しい項目を導入する場合、または既存の項目を更新する場合。
DESIGNアーキテクチャの設計詳細（High Level Design／Low Level Design）を記載したドキュメントの作成。
MAJOR DESIGN15 件以上のサービスメソッドを設計すること。
MEDIUM DESIGN10～14 件のサービスメソッドを設計すること。
MINOR DESIGN10 件未満のサービスメソッドを設計すること。
BUSINESS業務プロセス／標準業務手順をまとめたドキュメントの作成。
IMPORT別のシステムからコードとテストを、名前空間などの軽微な変更のみ、または変更なしでコピーする場合。インポートするコンポーネントを含め、形式は IMPORT: [COMPONENT]: [Description] とすること。
STATUS設計ドキュメントの STATUS 情報を更新する場合。
PLANNING計画は機能ごとに一度実施し、サービス間での協力を伴う必要があります。個人が自分の作業を計画することは、計画としては認められません。計画には、リーダーが複数のエンジニアとともにタスクを割り当て、チーム全体に分配することが含まれます。
MAJOR PLANNING10 件以上のタスクを計画すること。
MEDIUM PLANNING5 件以上のタスクを計画すること。
MINOR PLANNING5 件未満のタスクを計画すること。
MENTORSHIP60 分以上のセッション。
MAJOR MENTORSHIP60 分以上のセッション。
MEDIUM MENTORSHIP45 分のセッション。
MINOR MENTORSHIP30 分のセッション。
DISCUSSION技術的な問題を扱う DISCUSSION タイトルの会議を実施する場合。
MAJOR DISCUSSION60 分以上のディスカッション。
MEDIUM DISCUSSION45 分のディスカッション。
MINOR DISCUSSION30 分のディスカッション。
4.1.2 プロジェクト

Visual Studio では、開発者がコードやリソースを論理的で簡単に移動できる形で整理できるよう、階層型のプロジェクト構造を採用しています。
最上位にはソリューションがあり、1 つ以上のプロジェクトを格納するコンテナーです。
プロジェクトは、アプリケーションを構成するすべてのファイルとリソースを格納するコンテナーです。

4.1.2.1 ソリューション内のプロジェクト

一般的なソリューション構造は次のようになります……

  |-- Taarafo.Core                              (API)
  |-- Taarafo.Core.Infrastructure               (Console App)
  |-- Taarafo.Core.Tests.Acceptance             (xUnit Test Project)
  |-- Taarafo.Core.Tests.Unit                   (xUnit Test Project)
4.1.2.1 プロジェクト構造

一般的なプロジェクトのフォルダー構造は次のようになります……

Taarafo.Core
  |-- Brokers
        |-- DateTimes
        |-- Loggings
        |-- Storages
  |-- Models
        |-- Foundations
            |-- Posts
               |-- Exceptions
            |-- Comments
               |-- Exceptions
  |-- Migrations
  |-- Services
        |-- Foundations
            |-- Students
        |-- Processings
            |-- Students
        |-- Orchestrations
            |-- Students
  |-- Controllers

上記のフォルダー構造は、テストプロジェクトにも適用してモデルを整理し、Services\[Service Type]\[ServiceName] ごとに各種テストをグループ化できます。

4.1.3 コミット

この標準では、実際のコードを書く前にテストを書くことを重視する、TDD（テスト駆動開発）のソフトウェア開発手法に従います。
テストケースを書いて実行し、失敗することを確認してから、テストに合格するコードを書くというプロセスです。
これは、開発者がコードの要件、設計、実装に集中できる反復的なプロセスです。
TDD を使用する場合、開発者は xUnit や NUnit などのテストフレームワークを使ってテストケースを書き、そのフレームワークを使ってテストを実行し、アサートします。
目標は、高いテストカバレッジを確保してコードを十分にテストし、開発プロセスの早い段階でバグや問題を発見することです。
このアプローチにより、コードの保守性と理解しやすさを確保し、プロジェクトの要件を満たすことができます。

この TDD プロセスでテストケースを書く際は、テスト名とその結果を使って作業をコミットできます。
テストを書き、失敗することを確認するまでの作業は、[Test Name] -> FAIL の形式でコミットできます。例：ShouldAddPostAsync -> FAIL
その後、テストに合格させるための作業は、[Test Name] -> PASS の形式でコミットできます。例：ShouldAddPostAsync -> PASS

テストが不要なコード、つまり DATA、BROKERS、CONTROLLERS に取り組む場合は、プルリクエストで使用するものと同じ命名規則を採用します。
この規則では、カテゴリと作業内容の説明を [CATEGORY]: [Description Of Work Completed] の構文で記述します。カテゴリは必ず大文字、説明はパスカルケースにします。
例：DATA: Add Student Model または BROKERS: Insert Student または CONTROLLERS: POST Student（カテゴリの一覧については、上記のカテゴリ表を参照してください）

4.1.4 プルリクエスト

開発者は作業が完了したら、メインリポジトリに対してプルリクエストを作成できます。これにより、プロジェクトのメンテナーに更新を統合する準備ができたことを知らせます。
プルリクエスト（PR）の名前は、[CATEGORY]: [Description Of Work Completed] の構文で作成できます。カテゴリは必ず大文字、説明はパスカルケースにします。
例：FOUNDATIONS: Add Student

PR のコメント欄には、行った作業についての追加情報や、承認者にとって役立つ情報、関連情報を記載できます。
例：CONTROLLER の各アクションが想定どおりに動作していることを示し、201 - Created、400 - Bad Request、424 - Failed Dependency など、さまざまなレスポンス結果を示すスクリーンショットを添付できます。

キーワード #ISSUE-NUMBER をコメント欄のどこかに追加すると、プルリクエストを Issue にリンクして修正作業中であることを示し、プルリクエストまたはブランチがマージされたときに Issue を自動的にクローズすることもできます。
例：Closes #10。PR が複数の項目を対象とする場合は、Closes #10, closes #123 と記述できます。

マージ時にクローズせず、Issue へのリンクのみを設定したい場合は、キーワードを省略して #ISSUE-NUMBER を追加します。例：#10

4.1.5 構成

構成設定とは、ソフトウェアアプリケーションの動作を決定する値です。
データベース接続文字列や API キーから、機能フラグやログレベルまで、さまざまなものが含まれます。
構成設定を使用すると、コードを変更せずにアプリケーションの動作をカスタマイズできるため、
さまざまな環境へのデプロイや管理が容易になります。

.NET アプリケーションで構成設定を保存する一般的な方法の 1 つは、appsettings.json ファイルを使用することです。
このファイルは、構成設定を表すキーと値のペアを含む JSON 形式のファイルです。
開発者はこれらの設定を簡単に変更して、アプリケーションの動作を変えられます。

ただし、すべての構成設定を appsettings.json ファイルに安全に保存できるわけではありません。
API キー、データベースのパスワード、またはアプリケーションやそのリソースへの不正アクセスを許す可能性のあるその他のデータなど、
機密データは秘密にしておく必要があります。機密データを構成ファイル、特にプレーンテキスト形式で保存すると、アプリケーションのセキュリティが危険にさらされる可能性があります。

開発者は、安全なコーディングの実践に従い、パスワードやその他の機密データを構成プロバイダーのコードやプレーンテキストの構成ファイルに決して保存しないことが非常に重要です。
このような機密データは、Azure Key Vault のような安全な場所、またはデプロイ環境で設定された環境変数に保存してください。ローカル設定ファイルにパスワードを保存することも推奨されません。開発者がファイルをバージョン管理から除外し忘れたり、誰かがファイルを変更して機密ファイルを誤って含めてしまったりすると、パスワードがコードリポジトリに誤ってコミットされる事態につながり、アプリケーションのセキュリティが危険にさらされる可能性があるためです。

機密データを保護する方法の 1 つは、ユーザーシークレットを使用することです。ユーザーシークレットは、開発中に機密データを保存および取得する便利な方法を開発者に提供する .NET の機能です。
このデータは開発者のマシン上にローカル保存され、本番環境での使用を目的としていません。ユーザーシークレットは、機密データをソース管理の対象外にし、開発中に簡単にアクセスできるようにするうえで便利ですが、GitHub ワークフローのアクションとは互換性がない点に注意が必要です。
その代わりに、開発者は環境変数や、GitHub Action Secrets、Azure Key Vault のような安全な場所にシークレットを保存するなど、より安全な方法を検討してください。
ユーザーシークレットは GitHub のビルドパイプラインと直接互換性がないため、この方法についてはこれ以上説明しません。

機密データを保護するもう 1 つの方法は、環境変数を使用することです。
環境変数とは、オペレーティングシステムに設定され、実行時にアプリケーションからアクセスできる変数です。

appsettings.json と 環境変数の両方を使用すると、
開発者は機密データを他の構成設定から分離できるため、管理と保護が容易になります。さらに、
この方法により、開発者はビルドパイプラインで構成設定を安全に保存でき、
開発ライフサイクル全体を通じて機密データを保護できます。

4.1.5.1 appsettings.json

.NET アプリは、ファイルがアプリケーションのルートディレクトリにある場合、アプリケーションの起動時に appsettings.json と appsettings.{Environment}.json を自動的に読み込み、IConfiguration インターフェイスに登録します。 つまり、appsettings.json ファイルで定義されたキーと値のペアには IConfiguration オブジェクトを通じてアクセスでき、開発者はアプリケーション全体で構成設定を簡単に利用できます。

appsettings.json ファイルに加えて、.NET には、環境変数やコマンドライン引数など、さまざまなソースから構成設定を読み込める他の構成プロバイダーもあります。 （必要に応じて、開発者が独自のカスタム構成プロバイダーを作成し、他のソースから構成設定を読み込むこともできます。）

構成ソースは、構成プロバイダーが指定された順序で読み込まれます。 アプリに必要な基盤となる構成ソースの優先順位に合わせて、コード内で構成プロバイダーの順序を設定してください。

一般的な構成プロバイダーの順序は次のとおりです。

  1. appsettings.json
  2. appsettings.{Environment}.json
  3. ユーザーシークレット
  4. 環境変数構成プロバイダーを使用した環境変数
  5. コマンドライン構成プロバイダーを使用したコマンドライン引数

これらの仕組みを確認するために、コード例を見てみましょう。

4.1.5.1 アプリケーション設定

appsettings.json

{
  "MySettings": {
    "ApiUrl": "https://api.somesite.com/",    
    "ApiKey": "1ae4e397-ec3c-4ed7-8280-a17d0e2cbe78",
    "OrganisationId": "1bac6df0-cd68-4ce5-9c29-b2beb58201cd"
  },
  "Logging": {
    "LogLevel": {
      "Default": "Information",
      "Microsoft": "Warning",
      "Microsoft.Hosting.Lifetime": "Information"
    }
  },
  "AllowedHosts": "*"
}

上記の appsettings.json ファイルを使うと、次のように変数を読み込めます。

    string apiUrl = configuration["MySettings:ApiUrl"];
    string apiKey = configuration["MySettings:ApiKey"];
    string organisationId = configuration["MySettings:OrganisationId"];
4.1.5.2 環境変数

次のようにして、Web アプリケーションに環境変数を追加できます。

var builder = WebApplication.CreateBuilder(args);
...
builder.Configuration.AddEnvironmentVariables();
...
var app = builder.Build();

また、コンソールアプリやユニットテストで試す場合は、次のようにできます。

var configurationBuilder = new ConfigurationBuilder()
    .AddJsonFile("appsettings.json", optional: true, reloadOnChange: true)
    .AddEnvironmentVariables("MYAPP_ACCEPTANCE_");

this.configuration = configurationBuilder.Build();

注記：環境変数名の先頭に付ける必要があるプレフィックスを定義しています。
このプレフィックスは、構成ビルダーによって環境変数名から自動的に削除されます。
これは非常に便利な機能です。これにより、複数のアプリや環境で同じ名前の環境変数を保存できるようになります。

ここまでは、環境変数に値を設定していないため、設定項目を取得しても同じ値が返されます。

C# .NET では、環境変数を簡単に扱えます。
Environment クラスには、環境変数の読み取りや設定を行うためのメソッドがいくつか用意されています。
たとえば、環境変数を読み取るには、取得する変数名を渡して Environment.GetEnvironmentVariable メソッドを使用します。
環境変数を設定するには、変数名と値を指定して Environment.SetEnvironmentVariable メソッドを使用します。
コマンドラインで SETX コマンドを実行して、環境変数を設定することもできます。

デモでは、MySettings:ApiUrl の値を appsettings.json に残しておきます。

次に、次のコード行で MySettings:ApiKey の値を設定します。

Environment.SetEnvironmentVariable("MYSETTINGS:APIKEY", "3d4a1c55-fcd7-4b34-8536-99c8ae6ae33c");

また、MySettings:OrganisationId には、管理者権限のあるコンソールウィンドウでコマンドライン引数を使用します。

setx MYSETTINGS:APIKEY "b2440ae9-cad2-4d70-b138-4a807abe1bb7"

注記 Visual Studio は起動時に環境変数を事前に読み込み、アプリケーションが終了するまでキャッシュします。
コードで設定した環境変数とは異なり、コマンドラインで設定した環境変数は、事前読み込みの動作によりすぐには利用できません。
Visual Studio を終了して、再起動する必要があります。

Visual Studio を再読み込みしたら、次のようにして設定から値を再取得できます。

    string apiUrl = configuration["MySettings:ApiUrl"];
    string apiKey = configuration["MySettings:ApiKey"];
    string organisationId = configuration["MySettings:OrganisationId"];

ApiUrl は以前と同じですが、MySettings:ApiKey と MySettings:OrganisationId の値は変わっており、コードおよびコマンドラインの SETX を使って指定した環境変数の値と一致していることがわかります。

値を null に設定すると、コードから環境変数を削除することもできます。 Environment.SetEnvironmentVariable("MYSETTINGS:APIKEY", null);

または、コマンドラインで次のように実行できます。

setx MYSETTINGS:APIKEY /delete

GUI を使う場合は、SYSTEM PROPERTES > ENVIRONMENT VARIABLES に移動して、環境変数を追加／削除することもできます。

4.1.5.3 GitHub Actions ワークフロー

GitHub で環境変数を使用するには、リポジトリシークレットを設定し、ワークフローファイルの先頭にセクションを追加する必要があります。

  1. これらの設定を使用する GitHub リポジトリに移動し、上部のナビゲーションバーにある「Settings」をクリックします。

  2. 左側のサイドバーで「Secrets」をクリックし、「New repository secret」ボタンをクリックします。

  3. 「MYAPP_ACCEPTANCE_MYSETTINGS__APIKEY」と「MYAPP_ACCEPTANCE_MYSETTINGS__ORGANISATIONID」という名前の新しいシークレットを作成し、指定された設定の「ApiUrl」、「ApiKey」、「OrganisationId」に対応する値をそれぞれ設定します。

    注記

    • 先ほどの .AddEnvironmentVariables("MYAPP_ACCEPTANCE_"); の設定に合わせて、環境変数の前に MYAPP_ACCEPTANCE_ を付けています。
    • もう1つの違いは、GitHub Secrets では階層を表すためにコロン（:）を使用できないため、代わりに二重アンダースコア（__）を使用する必要があることです。

  4. GitHub Actions ワークフローでこれらのシークレットを環境変数として公開するには、次のコードスニペットをワークフローファイルの先頭に追加します。

env:
  API_URL: ${{ secrets.MySettings__ApiUrl }}
  API_KEY: ${{ secrets.MySettings__ApiKey }}
  ORG_ID: ${{ secrets.MySettings__OrganisationId }

dotnet.yml ファイルの全体例は次のようになります。

name: MyApplication Build
on:
  push:
    branches:
    - main
  pull_request:
    branches:
    - main
jobs:
  build:
    runs-on: windows-latest
    env:
      ApiKey: ${{ secrets.MYAPP_ACCEPTANCE_MYSETTINGS__APIKEY }}
      OrgId: ${{ secrets.MYAPP_ACCEPTANCE_MYSETTINGS__ORGANISATIONID }}
    steps:
    - name: Pulling Code
      uses: actions/checkout@v2
    - name: Installing .NET
      uses: actions/setup-dotnet@v1
      with:
        dotnet-version: 7.0.201
        include-prerelease: false
    - name: Restoring Packages
      run: dotnet restore
    - name: Building Solution
      run: dotnet build --no-restore
    - name: Running Tests
      run: dotnet test --no-build --verbosity normal

4.2 測定

Standard は、すべての人に対する公平性という理想を推進します。革新的なアイデア、優れた貢献、高いパフォーマンスは、特定の肩書きを持つ人だけのものではないと認識しています。すべての人の貢献を真に公平に評価するため、Standard では、さまざまなレベルやカテゴリに応じた貢献の価値とポイントを定めています。これらの貢献が蓄積されることで、貢献者のランクは次のレベルへと上がります。

4.2.0 貢献ポイント

以下は、すべての貢献の種類とそれぞれの価値の一覧です。

Title Starts WithReturn Value
INFRA10
MAJOR INFRA10
MEDIUM INFRA3
MINOR INFRA1
DATA5
MAJOR DATA5
MEDIUM DATA3
MINOR DATA1
MIGRATION20
MAJOR MIGRATION20
MEDIUM MIGRATION10
MINOR MIGRATION5
BROKER5
MAJOR BROKER5
MEDIUM BROKER3
MINOR BROKER1
FOUNDATION10
MAJOR FOUNDATION10
MEDIUM FOUNDATION5
MINOR FOUNDATION1
PROCESSING15
MAJOR PROCESSING15
MEDIUM PROCESSING10
MINOR PROCESSING5
ORCHESTRATION20
MAJOR ORCHESTRATION20
MEDIUM ORCHESTRATION15
MINOR ORCHESTRATION10
COORDINATION20
MAJOR COORDINATION20
MEDIUM COORDINATION15
MINOR COORDINATION5
MANAGEMENT20
MAJOR MANAGEMENT20
MEDIUM MANAGEMENT15
MINOR MANAGEMENT5
AGGREGATION10
MAJOR AGGREGATION10
MEDIUM AGGREGATION5
MINOR AGGREGATION1
CONTROLLER5
MAJOR CONTROLLER5
MEDIUM CONTROLLER3
MINOR CONTROLLER1
ACCEPTANCE10
MAJOR ACCEPTANCE10
MEDIUM ACCEPTANCE5
MINOR ACCEPTANCE3
INTEGRATION15
MAJOR INTEGRATION15
MEDIUM INTEGRATION10
MINOR INTEGRATION10
VIEW10
MAJOR VIEW10
MEDIUM VIEW5
MINOR VIEW1
BASE5
MAJOR BASE5
MEDIUM BASE3
MINOR BASE1
COMPONENT15
MAJOR COMPONENT15
MEDIUM COMPONENT10
MINOR COMPONENT5
PAGE5
MAJOR PAGE5
MEDIUM PAGE3
MINOR PAGE1
CLIENT5
MAJOR CLIENT5
MEDIUM CLIENT3
MINOR CLIENT1
EXPOSER5
MAJOR EXPOSER5
MEDIUM EXPOSER3
MINOR EXPOSER1
DESIGN20
MAJOR DESIGN20
MEDIUM DESIGN10
MINOR DESIGN5
MAJOR FIX20
MEDIUM FIX10
MINOR FIX5
PLANNING15
MAJOR PLANNING15
MINOR PLANNING10
MINIOR PLANNING5
MENTORSHIP20
MAJOR MENTORSHIP20
MINOR MENTORSHIP15
MINIOR MENTORSHIP10
DISCUSSION15
MAJOR DISCUSSION15
MINOR DISCUSSION10
MINIOR DISCUSSION5
MAJOR CODE RUB10
MEDIUM CODE RUB5
MINOR CODE RUB1
CODE RUB1
PROVISION10
IMPORT5
RELEASE10
CONFIG5
REVIEW1
DOCUMENTATION1
STANDARD100
BUSINES50
STATUS1
UNKNOWN0

これらの各カテゴリーは、前のセクションですでに定義されています。

4.2.1 平均実装時間

以下の表は、The Standard のアーキテクチャにおける各レイヤーまたはコンポーネントの実装に必要な平均推定時間を示しています。
これらの時間は実務経験に基づいており、計画や工数見積もりの一般的な参考値として使用されます。

レイヤー／コンポーネント平均時間
ブローカー、基盤約1時間
ファウンデーション、コンポーネント約3時間
処理、オーケストレーション、調整、オーケストレーションコンポーネント約5時間
管理、Uber Manager約3時間
コントローラー、ページ、クライアント約1時間

これらの見積もりは、標準的な複雑さで外部依存関係がない場合における、単一のサービスまたはコンポーネントの一般的な実装期間を示しています。

4.2.2 ランク

以下は、The Standard コミュニティおよび Standard 準拠プロジェクトへの生涯累計貢献度に基づくランクです。

役職スコア
SWE I10,000
SWE II25,000
SR. SWE50,000
PRINCIPAL100,000
PARTNER/DIRECTOR300,000
VP500,000
DISTINGUISHED1,000,000
THE STANDARD BEARER1M + DELEGATION

実装プロファイルのプラクティスに関する補足

12. プラクティス

コードへの貢献、ブランチ、コミット戦略、プロジェクト構造に関するプラクティスを定めることは、あらゆるソフトウェア開発プロジェクトに不可欠です。
こうしたプラクティスにより、コードベースを管理するための明確で一貫した方法が確立され、貢献が統制のとれた整理された形で行われるようになります。
これにより、混乱や競合を防ぎ、コードベースの安定性と保守性を維持できます。
また、コードへの貢献やプロジェクト構造に関する明確なプラクティスは、開発チーム内のコラボレーションとコミュニケーションの改善にも役立ちます。その結果、変更の追跡やレビュー、問題の特定と解決が容易になります。
全体として、コードへの貢献、ブランチとコミットの戦略、そしてプロジェクト構造に関するプラクティスを定めることは、ソフトウェア開発プロジェクトを成功させるうえで重要な要素です。

プラクティスでは、次の主な項目を考慮する必要があります。

  1. コードへの貢献
    1. フォーク／クローンとブランチ
    2. プロジェクト構造
    3. コミット
    4. プルリクエスト

The Standard チームは、前述の各項目を隅々まで明確に理解し、定義する必要があります。

12.1 コードへの貢献

貢献ガイドラインを定めることは、あらゆるオープンソースまたは共同ソフトウェア開発プロジェクトにとって不可欠です。
貢献者が変更を提出してレビューする際の明確なルールと期待事項を定めることで、すべての貢献が一貫性のある整理された形で行われるようになります。
また、貢献ガイドラインでは、コーディング、テスト、ドキュメント作成のベストプラクティスに関する指針を示せるため、コードベース全体の品質向上に役立ちます。
さらに、新しい貢献者にとっての学習ツールとしても機能し、プロジェクトに効果的に貢献するために必要な情報や手順を提供します。
（さらに、明確に定義された GitHub の貢献ガイドラインがあると、新しい貢献者を引きつけ、健全なオープンソースコミュニティを維持しやすくなります。）

12.1.1 フォークとブランチの戦略

コードのブランチ戦略は、安定した保守しやすいコードベースを維持するうえで不可欠です。 複数の開発者が互いの作業に干渉することなく、異なる機能やバグ修正に同時に取り組めるようになります。 各開発者は作業用のブランチを作成でき、レビューと承認を受けた後にメインブランチへマージできます。 これにより、競合を回避し、コードベースの安定性と一貫性を保つことができます。 さらに、ブランチ戦略によってバージョン管理が可能になり、コードベースの異なるバージョンを作成して追跡できます。 これは、必要に応じて変更をロールバックしたり、異なる環境向けにソフトウェアの複数のバージョンを維持したりする際に役立ちます。 総じて、ブランチ戦略はあらゆるソフトウェア開発プロジェクトにおける重要な要素であり、コードベースの安定性と保守性を確保するうえで不可欠です。

ソフトウェア開発では、次のようなさまざまなブランチ戦略を使用できます。

  1. Gitflow：厳格なブランチモデルに従う、広く採用されているブランチ戦略です。開発は機能ブランチで行い、メインの開発ブランチにマージします。この戦略は、多数の貢献者が参加する大規模プロジェクトに適しています。

  2. トランクベース開発：メインブランチ、つまりトランクで作業し、変更を直接コミットする戦略です。貢献者が少ない小規模プロジェクトに適しています。

  3. 機能ブランチ：機能やバグ修正ごとに個別のブランチを作成し、完了したらメインブランチにマージする戦略です。複数の貢献者が参加する大規模プロジェクトに適しています。

  4. フォーク：リポジトリのコピーを作成し、独立して作業する戦略です。同じコードベースに複数の貢献者が取り組むオープンソースプロジェクトに適しています。フォークワークフローの主な利点は、全員が単一の中央リポジトリにプッシュしなくても、貢献を取り込めることです。開発者はそれぞれのサーバー側リポジトリにプッシュし、公式リポジトリにプッシュできるのはプロジェクトのメンテナーだけです。これにより、公式コードベースへの書き込みアクセス権を与えることなく、メンテナーはどの開発者からのコミットでも受け入れられます。

  5. リリースブランチ：リリースごとに個別のブランチを作成し、リリースの準備が整ったらメインブランチにマージする戦略です。定期的なリリーススケジュールがあるプロジェクトに適しています。

  6. 継続的インテグレーション：コードの変更を行うとすぐにマージし、自動テストを実行してコードベースの安定性を確保する戦略です。変更の頻度が高いプロジェクトに適しています。

最終的には、プロジェクトのニーズや制約に合い、すべての貢献者が容易に理解して従えるブランチ戦略を選ぶことが重要です。

12.1.1.1 オープンソース開発

The Standard はオープンソースの取り組みを推進しているため、フォークするワークフローを簡単に見てみましょう。

仕組み

フォークするワークフローは、サーバー上に保存された公式の公開リポジトリから始まります。新しい開発者がプロジェクトに取り組み始める際、公式リポジトリを直接クローンすることはありません。

代わりに、公式リポジトリをフォークしてコピーを作成します。この新しいコピーが、開発者個人の公開リポジトリとなります。
サーバー側にコピーを作成した後、開発者は git clone を実行して、ローカルマシンにコピーを取得します。
他のワークフローと同様に、これが開発者のプライベートな開発環境となります。

ローカルのコミットを公開する準備ができたら、公式リポジトリではなく、自分の公開リポジトリにコミットをプッシュします。
次に、メインリポジトリにプルリクエストを作成します。これにより、プロジェクトのメンテナーに更新を統合する準備ができたことを知らせます。
プルリクエストはレビューできるほか、コントリビュートされたコードに問題がある場合の便利な議論の場にもなります。

以下に、このワークフローの手順を示します。

  1. 開発者がサーバー側の「公式」リポジトリを「フォーク」します。これにより、開発者自身のサーバー側のコピーが作成されます。
  2. 新しいサーバー側のコピーをローカルシステムにクローンします。
  3. 新しいローカルの機能ブランチを作成します。
  4. 開発者が新しいブランチで変更を行います。
  5. 変更をコミットします。
  6. ブランチを開発者自身のサーバー側のコピーにプッシュします。
  7. 開発者が新しいブランチから「公式」リポジトリにプルリクエストを作成します。
  8. プルリクエストがレビューされ、ビルドの成功とテスト結果が検証されます。この時点で、メンテナーは変更を依頼するか、マージを承認できます。承認された場合、変更は元のサーバー側リポジトリにマージされます。
12.1.1.2 ブランチ名の規則

ブランチ名には、次の命名規則を適用できます。users/[username]/[category]-[entity]-[action]

各変数には、次の値を指定します。

  • [username] => GitHub のユーザー名
  • [category] => 作業対象のカテゴリ
  • [entity] => サービス／ブローカーが使用するエンティティ
  • [action] => アクション
12.1.1.3 カテゴリ一覧
カテゴリ説明
INFRA初期プロジェクトのセットアップ、ビルドプロジェクト／ビルドスクリプトの作成。
MAJOR INFRA大規模な更新。単純な設定やファイルの削除または追加。
MEDIUM INFRA中規模の更新。単純な設定やファイルの削除または追加。
MINOR INFRA小規模な更新。単純な設定やファイルの削除または追加。
PROVISIONSプロビジョニングプロジェクト／スクリプトの作成。
RELEASESソフトウェアをリリースするためのインフラ作業。
DATAデータモデルの作成（EF を使用する場合はそのマイグレーションも含む）。
MAJOR DATA既存のデータモデルに対する、5 つ以上のプロパティの追加／変更を伴う変更。
MEDIUM DATA既存のデータモデルに対する、3～4 つのプロパティの追加／変更を伴う変更。
MINOR DATA既存のデータモデルに対する、1～2 つのプロパティの追加／変更を伴う変更。
MIGRATIONあるシステムから別のシステムへのデータの移動または変換、既存データの更新、レポートの生成。
MAJOR MIGRATION大量のデータや複雑さを伴う、大規模なデータマイグレーションまたは変換作業。
MEDIUM MIGRATION中程度のデータ量または作業量を伴う、中程度の複雑さのデータマイグレーションまたは更新。
MINOR MIGRATION複雑さが低い、またはデータ量が少ない、小規模なデータマイグレーションまたは単純なデータ更新。
BROKERS外部ライブラリ、リソース、サービス、API をラップするブローカーを作成する場合。
MAJOR BROKERS既存のブローカーに対する大規模な変更（機能の大幅な変更）。
MEDIUM BROKERS既存のブローカーに対する中規模の変更（複数の重要な変更）。
MINOR BROKERS既存のブローカーに対する小規模な変更（単純な変更）。
FOUNDATIONSFoundation Service を作成する場合。
MAJOR FOUNDATIONS既存の foundation service に対して、5 件以上のテストをすべて作成または更新する変更。
MEDIUM FOUNDATIONS既存の foundation service に対して、3～4 件のテストを作成または更新する変更。
MINOR FOUNDATIONS既存の foundation service に対して、1～2 件のテストを作成または更新する変更。
PROCESSINGSProcessing Service を作成する場合。
MAJOR PROCESSINGS既存の processing service に対して、5 件以上のテストをすべて作成または更新する変更。
MEDIUM PROCESSINGS既存の processing service に対して、3～4 件のテストを作成または更新する変更。
MINOR PROCESSINGS既存の processing service に対して、1～2 件のテストを作成または更新する変更。
ORCHESTRATIONSOrchestration Service を作成する場合。
MAJOR ORCHESTRATIONS既存の orchestration service に対して、5 件以上のテストをすべて作成または更新する変更。
MEDIUM ORCHESTRATIONS既存の orchestration service に対して、3～4 件のテストを作成または更新する変更。
MINOR ORCHESTRATIONS既存の orchestration service に対して、1～2 件のテストを作成または更新する変更。
COORDINATIONSCoordination Service を作成する場合。
MAJOR COORDINATIONS既存の coordination service に対して、5 件以上のテストをすべて作成または更新する変更。
MEDIUM COORDINATIONS既存の coordination service に対して、3～4 件のテストを作成または更新する変更。
MINOR COORDINATIONS既存の coordination service に対して、1～2 件のテストを作成または更新する変更。
MANAGEMENTSManagement Service を作成する場合。
MAJOR MANAGEMENTS既存の management service に対して、5 件以上のテストをすべて作成または更新する変更。
MEDIUM MANAGEMENTS既存の management service に対して、3～4 件のテストを作成または更新する変更。
MINOR MANAGEMENTS既存の management service に対して、1～2 件のテストを作成または更新する変更。
AGGREGATIONSAggregation Service を作成する場合。
MAJOR AGGREGATIONS既存の aggregation service に対して、5 件以上のテストをすべて作成または更新する変更。
MEDIUM AGGREGATIONS既存の aggregation service に対して、3～4 件のテストを作成または更新する変更。
MINOR AGGREGATIONS既存の aggregation service に対して、1～2 件のテストを作成または更新する変更。
CONTROLLERSController を作成する場合。
MAJOR CONTROLLERS既存の controller に対して、5 件以上のテストをすべて作成または更新する変更。
MEDIUM CONTROLLERS既存の controller に対して、3～4 件のテストを作成または更新する変更。
MINOR CONTROLLERS既存の controller に対して、1～2 件のテストを作成または更新する変更。
CLIENTS他者が使用できるライブラリにクライアントを作成する場合。
MAJOR CLIENTS既存のクライアントに対して、5 件以上のテストを作成または更新する変更。
MEDIUM CLIENTS既存のクライアントに対して、3～4 件のテストを作成または更新する変更。
MINOR CLIENTS既存のクライアントに対して、1～2 件のテストを作成または更新する変更。
PROVIDERS他者が使用できる SPAL provider library にプロバイダーを作成する場合。
EXPOSERSProgram.cs など、その他の種類のエクスポーザーを作成する場合。
MAJOR EXPOSERS
MEDIUM EXPOSERS
MINOR EXPOSERS
VIEWSView Service を作成する場合。
MAJOR VIEWS既存のビューに対して、5 件以上のテストをすべて作成または更新する変更。
MEDIUM VIEWS既存のビューに対して、3～4 件のテストを作成または更新する変更。
MINOR VIEWS既存のビューに対して、1～2 件のテストを作成または更新する変更。
BASESフロントエンドのベースコンポーネントを作成する場合。
MAJOR BASES
MEDIUM BASES
MINOR BASES
COMPONENTSコンポーネントを作成する場合。
MAJOR COMPONENTS既存のコンポーネントに対して、5 件以上のテストをすべて作成または更新する変更。
MEDIUM COMPONENTS既存のコンポーネントに対して、3～4 件のテストを作成または更新する変更。
MINOR COMPONENTS既存のコンポーネントに対して、1～2 件のテストを作成または更新する変更。
PAGESBlazor ページを作成する場合。
MAJOR PAGES
MEDIUM PAGES
MINOR PAGES
ACCEPTANCE受け入れテストを作成する場合。
MAJOR ACCEPTANCE
MEDIUM ACCEPTANCE
MINOR ACCEPTANCE
INTEGRATION統合テストを作成する場合。
MAJOR INTEGRATION
MEDIUM INTEGRATION
MINOR INTEGRATION
CODE RUBスタイル、コードのフォーマット、スペルなどを修正する小規模な変更（バグ修正には使用しない）。
MAJOR CODE RUB複数のファイルに影響する、大規模なコードクリーンアップ。
MEDIUM CODE RUB複数のファイルに影響する、中規模のコードクリーンアップ。
MINOR CODE RUB少数のファイルに影響する、小規模なコードクリーンアップ。
MINOR FIXプログラム全体の機能を大きく変えない、小規模なバグ修正／変更。
MEDIUM FIXプログラムまたはシステムの機能やパフォーマンスに中程度の影響を与える修正。
MAJOR FIXソフトウェアプログラムまたはシステムの重大な問題に対処する、大規模なバグ修正。
DOCUMENTATION一般的なドキュメント。
CONFIGさまざまな環境向けの appsettings.json の設定など、あらゆる設定変更。
REVIEWプロジェクトの標準および規格への準拠という観点から、提出された作業をレビューすること。
STANDARDThe Standard に新しい項目を導入する場合、または既存の項目を更新する場合。
DESIGNアーキテクチャの設計詳細（High Level Design／Low Level Design）を記載したドキュメントの作成。
MAJOR DESIGN15 件以上のサービスメソッドを設計すること。
MEDIUM DESIGN10～14 件のサービスメソッドを設計すること。
MINOR DESIGN10 件未満のサービスメソッドを設計すること。
BUSINESS業務プロセス／標準業務手順をまとめたドキュメントの作成。
IMPORT別のシステムからコードとテストを、名前空間などの軽微な変更のみ、または変更なしでコピーする場合。インポートするコンポーネントを含め、形式は IMPORT: [COMPONENT]: [Description] とすること。
STATUS設計ドキュメントの STATUS 情報を更新する場合。
PLANNING計画は機能ごとに一度実施し、サービス間での協力を伴う必要があります。個人が自分の作業を計画することは、計画としては認められません。計画には、リーダーが複数のエンジニアとともにタスクを割り当て、チーム全体に分配することが含まれます。
MAJOR PLANNING10 件以上のタスクを計画すること。
MEDIUM PLANNING5 件以上のタスクを計画すること。
MINOR PLANNING5 件未満のタスクを計画すること。
MENTORSHIP60 分以上のセッション。
MAJOR MENTORSHIP60 分以上のセッション。
MEDIUM MENTORSHIP45 分のセッション。
MINOR MENTORSHIP30 分のセッション。
DISCUSSION技術的な問題を扱う DISCUSSION タイトルの会議を実施する場合。
MAJOR DISCUSSION60 分以上のディスカッション。
MEDIUM DISCUSSION45 分のディスカッション。
MINOR DISCUSSION30 分のディスカッション。
12.1.2 プロジェクト

Visual Studio では階層構造のプロジェクト構成を採用しており、開発者はコードやリソースを論理的で移動しやすい形に整理できます。 最上位にはソリューションがあり、1 つ以上のプロジェクトを格納するコンテナーとなります。 プロジェクトは、アプリケーションを構成するすべてのファイルとリソースを格納するコンテナーです。

12.1.2.1 ソリューション内のプロジェクト

一般的なソリューション構成は、次のようになります。

  |-- Taarafo.Core                     (API)
  |-- Taarafo.Core.Infrastructure      (Console App)
  |-- Taarafo.Core.Tests.Acceptance    (xUnit Test Project)
  |-- Taarafo.Core.Tests.Unit          (xUnit Test Project)
12.1.2.1 プロジェクト構成

一般的なプロジェクトのフォルダー構成は、次のようになります。

Taarafo.Core
  |-- Brokers
        |-- DateTimes
        |-- Loggings
        |-- Storages
  |-- Models
        |-- Foundations
            |-- Posts
               |-- Exceptions
            |-- Comments
               |-- Exceptions
  |-- Migrations
  |-- Services
        |-- Foundations
            |-- Students
        |-- Processings
            |-- Students
        |-- Orchestrations
            |-- Students
  |-- Controllers

上記のフォルダー構成は、テストプロジェクトにも適用してモデルを整理し、 各種テストを Services\[Service Type]\[ServiceName] ごとにグループ化できます。

12.1.3 コミット

Standard では、実際のコードを書く前にテストを書くことを重視する、TDD（テスト駆動開発）のソフトウェア開発手法に従います。 これは、テストケースを書いて実行し、失敗することを確認してから、テストに合格するコードを書くプロセスです。 開発者がコードの要件、設計、実装に集中できる、反復的なプロセスです。 TDD を使用する場合、開発者は xUnit や NUnit などのテストフレームワークを使ってテストケースを書き、そのフレームワークでテストを実行して結果を検証します。 目標は高いテストカバレッジを達成し、コードを十分にテストして、開発プロセスの早い段階でバグや問題を発見できるようにすることです。 このアプローチにより、コードの保守性と理解しやすさが向上し、プロジェクトの要件を満たすことができます。

この TDD プロセスに従ってテストケースを書く際は、テスト名とその結果をコミットに使用できます。 テストを書き、失敗を確認する作業は、[Test Name] -> FAIL としてコミットできます（例：ShouldAddPostAsync -> FAIL）。 その後、テストに合格させる作業は、[Test Name] -> PASS としてコミットできます（例：ShouldAddPostAsync -> PASS）。

12.1.3.1 FAIL/PASS コミットの規律

各 TDD サイクルでは、必ず 2 つのコミットを作成します。

  1. FAIL コミット — 新しいテスト（およびコンパイルに必要な新しい例外モデルファイル）を含みますが、テストに合格させる実装コードは含めません。
  2. PASS コミット — 以前失敗したテストに合格させる実装コード（例：catch ブロック、ヘルパーメソッド、検証ロジック）のみを含みます。

重要なルール： FAIL コミットを作成する前に、テストランナーでテストを実行し、実際に失敗することを確認しなければなりません。実行できない、コンパイルできない、または合格するテストは、有効な FAIL ではありません。同様に、PASS コミットを作成する前に、新しいテストだけでなく、すべてのテストを実行し、合格することを確認しなければなりません。

TDD サイクルは次のとおりです。

1. Write the test                    → build → run test → verify FAIL → commit "[TestName] -> FAIL"
2. Write the minimum implementation  → build → run ALL tests → verify PASS → commit "[TestName] -> PASS"
3. Repeat for the next test
12.1.3.2 各コミットに含める内容
コミットの種類含めるもの含めないもの
FAIL新しいテストメソッド、テストのコンパイルに必要な新しい例外モデルクラス、新しい using ディレクティブサービス内の実装（catch ブロック、検証ロジック、ヘルパーメソッド）
PASSサービス内の実装コード（catch ブロック、ヘルパーメソッド、検証ロジック）新しいテスト（次の FAIL コミットに含めます）
12.1.3.3 基盤サービスの TDD コミット順序

Add{Entity}Async メソッドを実装する際の、FAIL/PASS コミットペアの正確な順序は次のとおりです。

 1. ShouldAdd{Entity}Async                                                              -> FAIL
 2. ShouldAdd{Entity}Async                                                              -> PASS
 3. ShouldThrowValidationExceptionOnAddIf{Entity}IsNullAndLogItAsync                    -> FAIL
 4. ShouldThrowValidationExceptionOnAddIf{Entity}IsNullAndLogItAsync                    -> PASS
 5. ShouldThrowValidationExceptionOnAddIf{Entity}IsInvalidAndLogItAsync                 -> FAIL
 6. ShouldThrowValidationExceptionOnAddIf{Entity}IsInvalidAndLogItAsync                 -> PASS
 7. ShouldThrowDependencyValidationExceptionOnAddIfBadRequestErrorOccursAndLogItAsync    -> FAIL
 8. ShouldThrowDependencyValidationExceptionOnAddIfBadRequestErrorOccursAndLogItAsync    -> PASS
 9. ShouldThrowDependencyValidationExceptionOnAddIfConflictErrorOccursAndLogItAsync      -> FAIL
10. ShouldThrowDependencyValidationExceptionOnAddIfConflictErrorOccursAndLogItAsync      -> PASS
11. ShouldThrowCriticalDependencyExceptionOnAddIfUnauthorizedErrorOccursAndLogItAsync    -> FAIL
12. ShouldThrowCriticalDependencyExceptionOnAddIfUnauthorizedErrorOccursAndLogItAsync    -> PASS
13. ShouldThrowCriticalDependencyExceptionOnAddIfForbiddenErrorOccursAndLogItAsync       -> FAIL
14. ShouldThrowCriticalDependencyExceptionOnAddIfForbiddenErrorOccursAndLogItAsync       -> PASS
15. ShouldThrowCriticalDependencyExceptionOnAddIfNotFoundErrorOccursAndLogItAsync        -> FAIL
16. ShouldThrowCriticalDependencyExceptionOnAddIfNotFoundErrorOccursAndLogItAsync        -> PASS
17. ShouldThrowCriticalDependencyExceptionOnAddIfUrlNotFoundErrorOccursAndLogItAsync     -> FAIL
18. ShouldThrowCriticalDependencyExceptionOnAddIfUrlNotFoundErrorOccursAndLogItAsync     -> PASS
19. ShouldThrowDependencyExceptionOnAddIfInternalServerErrorOccursAndLogItAsync          -> FAIL
20. ShouldThrowDependencyExceptionOnAddIfInternalServerErrorOccursAndLogItAsync          -> PASS
21. ShouldThrowDependencyExceptionOnAddIfServiceUnavailableErrorOccursAndLogItAsync      -> FAIL
22. ShouldThrowDependencyExceptionOnAddIfServiceUnavailableErrorOccursAndLogItAsync      -> PASS
23. ShouldThrowCriticalDependencyExceptionOnAddIfHttpRequestErrorOccursAndLogItAsync     -> FAIL
24. ShouldThrowCriticalDependencyExceptionOnAddIfHttpRequestErrorOccursAndLogItAsync     -> PASS
25. ShouldThrowServiceExceptionOnAddIfServiceErrorOccursAndLogItAsync                    -> FAIL
26. ShouldThrowServiceExceptionOnAddIfServiceErrorOccursAndLogItAsync                    -> PASS

すべてのテストに合格した後、最後に設定をコミットし、サービスを Program.cs に登録します。

27. CONFIGURATIONS: Register I{Entity}Service in Program.cs

ストレージベースのサービスでは、コミット 7～24 を、同じ FAIL/PASS パターンに従った対応する SQL/EF 例外テスト （DuplicateKeyException、DbUpdateException、SqlException など）に置き換えます。

12.1.3.4 テストを伴わないコミット

テストが不要なコード、つまり DATA、BROKERS、CONTROLLERS に取り組んでいる場合は、プルリクエストで使用するものと同じ命名規則を採用します。カテゴリと作業内容の説明を、次の構文で記述します：[CATEGORY]: [Description Of Work Completed]。カテゴリは常に大文字、説明はパスカルケースにします。 例：DATA: Add Student Model、BROKERS: Insert Student、CONTROLLERS: POST Student（カテゴリの完全な一覧については、上記のカテゴリ表を参照してください）

12.1.4 プルリクエスト

開発者は作業を完了したら、メインリポジトリにプルリクエストを作成できます。これにより、プロジェクトのメンテナーに更新を統合する準備ができたことを知らせられます。 プルリクエスト（PR）の名前は、次の構文で作成できます：[CATEGORY]: [Description Of Work Completed]。カテゴリは常に大文字、説明はパスカルケースにします。 例：FOUNDATIONS: Add Student

PR のコメント欄には、行った作業について、承認者にとって役立つ、または関連性のある追加情報を記載することもできます。 例：CONTROLLER のアクションが期待どおりに動作することを示すスクリーンショットを添付し、201 - Created、400 - Bad Request、424 - Failed Dependency など、さまざまな応答結果を示します。

プルリクエストをイシューにリンクして、修正作業が進行中であることを示し、プルリクエストまたはブランチがマージされたときにイシューを自動的にクローズすることもできます。コメント欄の任意の場所に、KEYWORD #ISSUE-NUMBER を追加してください。 例：Closes #10、または PR が複数の項目を対象とする場合は、Closes #10, closes #123 と記述できます。

マージ時にイシューをクローズせず、単にイシューへリンクしたい場合は、キーワードを省略して #ISSUE-NUMBER のみを追加します。例：#10

12.1.5 構成

構成設定とは、ソフトウェアアプリケーションの動作を決定する値です。
データベースの接続文字列や API キーから、機能フラグやログ記録レベルまで、さまざまなものが含まれます。
構成設定を使用すると、コードを変更せずにアプリケーションの動作をカスタマイズできるため、
さまざまな環境へのデプロイや管理が容易になります。

.NET アプリケーションで構成設定を保存する一般的な方法の一つは、appsettings.json ファイルを使用することです。
このファイルは、構成設定を表すキーと値の組を含む JSON 形式のファイルです。
開発者は、これらの設定を簡単に変更して、アプリケーションの動作を変えることができます。

ただし、すべての構成設定を appsettings.json ファイルに安全に保存できるわけではありません。
API キー、データベースのパスワード、その他アプリケーションやそのリソースへの
不正アクセスを可能にするデータなどの機密データは、秘密にしておく必要があります。
機密データを構成ファイル、特にプレーンテキスト形式で保存すると、アプリケーションのセキュリティが危険にさらされる可能性があります。

開発者は、セキュアコーディングのプラクティスに従い、パスワードやその他の機密データを
構成プロバイダーのコードやプレーンテキストの構成ファイルに決して保存しないことが非常に重要です。
このような機密データは、Azure Key Vault のような安全な場所や、デプロイ環境で設定される
環境変数に保存する必要があります。ローカル設定ファイルにパスワードを保存することも
推奨されません。開発者がファイルをバージョン管理から除外し忘れたり、誰かが変更した際に
機密ファイルを誤って含めてしまったりして、パスワードが誤ってコードリポジトリにコミットされる事態に
簡単につながり、アプリケーションのセキュリティが危険にさらされる可能性があるためです。

機密データを保護する方法の一つは、ユーザーシークレットを使用することです。ユーザーシークレットは、開発中に機密データを
保存して取得するための便利な方法を提供する .NET の機能です。
このデータは開発者のマシンにローカル保存され、本番環境での使用を想定していません。
ユーザーシークレットは、機密データをソース管理から除外し、開発中に簡単に利用できるようにするうえで便利ですが、
GitHub workflow actions とは互換性がないことに注意が必要です。
代わりに、開発者は環境変数や、GitHub Action Secrets または Azure Key Vault のような安全な場所に保存するなど、
より安全なシークレットの保存方法を検討する必要があります。
ユーザーシークレットは GitHub のビルドパイプラインと直接互換性がないため、この方法についてはこれ以上説明しません。

機密データを保護するもう一つの方法は、環境変数を使用することです。
環境変数はオペレーティングシステムに設定される変数で、実行時にアプリケーションからアクセスできます。

appsettings.json と 環境変数の両方を使用することで、
開発者は機密データをその他の構成設定から分離でき、管理と保護が容易になります。さらに、
この方法により、開発者はビルドパイプラインで構成設定を安全に保存でき、
開発ライフサイクル全体を通じて機密データを確実に保護できます。

12.1.5.1 appsettings.json

.NET アプリは、ファイルがアプリケーションのルートディレクトリにある場合、アプリケーションの起動時に appsettings.json と appsettings.{Environment}.json を自動的に読み込み、IConfiguration インターフェースに登録します。 つまり、appsettings.json ファイルで定義されたキーと値のペアには、IConfiguration オブジェクトを通じてアクセスできるため、開発者はアプリケーション全体で構成設定を簡単に利用できます。

appsettings.json ファイルに加えて、.NET には、環境変数やコマンドライン引数など、さまざまなソースから構成設定を読み込める構成プロバイダーが用意されています。 （必要に応じて、開発者が独自のカスタム構成プロバイダーを作成し、他のソースから構成設定を読み込むこともできます。）

構成ソースは、構成プロバイダーが指定された順序で読み込まれます。 アプリに必要な基盤となる構成ソースの優先順位に合わせて、コード内で構成プロバイダーの順序を設定してください。

一般的な構成プロバイダーの順序は次のとおりです。

  1. appsettings.json
  2. appsettings.{Environment}.json
  3. ユーザーシークレット
  4. 環境変数（環境変数構成プロバイダーを使用）
  5. コマンドライン引数（コマンドライン構成プロバイダーを使用）

これらの仕組みを確認するため、コード例をいくつか見てみましょう。

12.1.5.1 アプリケーション設定

appsettings.json

{
  "MySettings": {
    "ApiUrl": "https://api.somesite.com/",    
    "ApiKey": "1ae4e397-ec3c-4ed7-8280-a17d0e2cbe78",
    "OrganisationId": "1bac6df0-cd68-4ce5-9c29-b2beb58201cd"
  },
  "Logging": {
    "LogLevel": {
      "Default": "Information",
      "Microsoft": "Warning",
      "Microsoft.Hosting.Lifetime": "Information"
    }
  },
  "AllowedHosts": "*"
}

上記の appsettings.json ファイルを使うと、次のように変数を読み込めます。

    string apiUrl = configuration["MySettings:ApiUrl"];
    string apiKey = configuration["MySettings:ApiKey"];
    string organisationId = configuration["MySettings:OrganisationId"];
12.1.5.2 環境変数

次のようにして、Web アプリケーションに環境変数を追加できます。

var builder = WebApplication.CreateBuilder(args);
...
builder.Configuration.AddEnvironmentVariables();
...
var app = builder.Build();

また、コンソールアプリや単体テストで試してみたい場合は、次のようにできます。

var configurationBuilder = new ConfigurationBuilder()
    .AddJsonFile("appsettings.json", optional: true, reloadOnChange: true)
    .AddEnvironmentVariables("MYAPP_ACCEPTANCE_");

this.configuration = configurationBuilder.Build();

注記：環境変数の名前に付ける必要があるプレフィックスを定義しています。
構成ビルダーによって、このプレフィックスは環境変数の名前から自動的に削除されます。
この機能は非常に便利です。複数のアプリや環境で、同じ名前の環境変数を保存できるためです。

ここまでは、環境変数の値をまだ設定していないため、構成項目を取得しても同じ値が返されます。

C# .NET では、環境変数を簡単に扱えます。 Environment クラスには、環境変数の読み取りと設定を行うメソッドがいくつか用意されています。 たとえば、環境変数を読み取るには、取得したい変数の名前を指定して Environment.GetEnvironmentVariable メソッドを使用します。 環境変数を設定するには、変数の名前と値を指定して Environment.SetEnvironmentVariable メソッドを使用します。 コマンドラインから SETX コマンドを実行して環境変数を設定することもできます。

デモでは、MySettings:ApiUrl の値は appsettings.json に残しておきます。

次に、次のコード行で MySettings:ApiKey の値を設定します。

Environment.SetEnvironmentVariable("MYSETTINGS:APIKEY", "3d4a1c55-fcd7-4b34-8536-99c8ae6ae33c");

また、MySettings:OrganisationId には、管理者権限のあるコンソールウィンドウからコマンドライン引数を使用します。

setx MYSETTINGS:APIKEY "b2440ae9-cad2-4d70-b138-4a807abe1bb7"

注記 Visual Studio は起動時に環境変数を読み込み、アプリケーションを閉じるまでキャッシュします。
コードで設定した環境変数とは異なり、コマンドラインで設定した環境変数は、起動時に読み込まれるためすぐには使用できません。
Visual Studio を閉じて、再度開く必要があります。

Visual Studio を再起動したら、次のようにして構成から値を再取得できます。

    string apiUrl = configuration["MySettings:ApiUrl"];
    string apiKey = configuration["MySettings:ApiKey"];
    string organisationId = configuration["MySettings:OrganisationId"];

ApiUrl は以前と同じですが、MySettings:ApiKey と MySettings:OrganisationId の値は変更されており、コードおよびコマンドラインの SETX を使って環境変数に指定した値と同じになっていることがわかります。

値を null に設定すると、コードから環境変数を削除することもできます。 Environment.SetEnvironmentVariable("MYSETTINGS:APIKEY", null);

または、コマンドラインから次のように実行できます。

setx MYSETTINGS:APIKEY /delete

GUI を使う場合は、SYSTEM PROPERTES > ENVIRONMENT VARIABLES に移動して、環境変数を追加または削除することもできます。

12.1.5.3 GitHub Actions ワークフロー

GitHub で使用する環境変数を設定するには、リポジトリシークレットを設定し、ワークフローファイルの先頭にセクションを追加する必要があります。

  1. これらの設定を使用する GitHub リポジトリに移動し、上部のナビゲーションバーにある「Settings」をクリックします。

  2. 左側のサイドバーで「Secrets」をクリックし、次に「New repository secret」ボタンをクリックします。

  3. 3 つの新しいシークレットを作成します。名前はそれぞれ「MYAPP_ACCEPTANCE_MYSETTINGS__APIKEY」と「MYAPP_ACCEPTANCE_MYSETTINGS__ORGANISATIONID」とし、指定された設定の「ApiUrl」、「ApiKey」、「OrganisationId」に対応する値を設定します。

    注記

    • 先ほどの .AddEnvironmentVariables("MYAPP_ACCEPTANCE_"); の設定に合わせて、環境変数に MYAPP_ACCEPTANCE_ というプレフィックスを付けています。
    • もう 1 つの違いは、GitHub Secrets では階層を表すためにコロン（:）を使用できないため、代わりに二重アンダースコア（__）を使用する必要がある点です。

  4. これらのシークレットを GitHub Actions ワークフローの環境変数として公開するには、ワークフローファイルの先頭に次のコードスニペットを追加します。

env:
  API_URL: ${{ secrets.MySettings__ApiUrl }}
  API_KEY: ${{ secrets.MySettings__ApiKey }}
  ORG_ID: ${{ secrets.MySettings__OrganisationId }

dotnet.yml ファイルの全体例は次のようになります。

name: MyApplication Build
on:
  push:
    branches:
    - main
  pull_request:
    branches:
    - main
jobs:
  build:
    runs-on: windows-latest
    env:
      ApiKey: ${{ secrets.MYAPP_ACCEPTANCE_MYSETTINGS__APIKEY }}
      OrgId: ${{ secrets.MYAPP_ACCEPTANCE_MYSETTINGS__ORGANISATIONID }}
    steps:
    - name: Pulling Code
      uses: actions/checkout@v2
    - name: Installing .NET
      uses: actions/setup-dotnet@v1
      with:
        dotnet-version: 7.0.201
        include-prerelease: false
    - name: Restoring Packages
      run: dotnet restore
    - name: Building Solution
      run: dotnet build --no-restore
    - name: Running Tests
      run: dotnet test --no-build --verbosity normal
12.2 測定

本基準は、すべての人に対する公平性の理想を推進します。本基準では、革新的なアイデア、多大な貢献、高い業績は、特定の肩書きを持つ人だけに限られるものではないと認識しています。すべての人の貢献を真に公平に測定できるようにするため、本基準では、さまざまなレベルやカテゴリーの貢献に価値とポイントを設定しています。これらの貢献の積み重ねによって、貢献者のランクは次のレベルへと上がります。

12.2.0 貢献ポイント

以下は、すべての貢献の種類と、それぞれの価値の一覧です。

Title Starts WithReturn Value
INFRA10
MAJOR INFRA10
MEDIUM INFRA3
MINOR INFRA1
DATA5
MAJOR DATA5
MEDIUM DATA3
MINOR DATA1
MIGRATION20
MAJOR MIGRATION20
MEDIUM MIGRATION10
MINOR MIGRATION5
BROKER5
MAJOR BROKER5
MEDIUM BROKER3
MINOR BROKER1
FOUNDATION10
MAJOR FOUNDATION10
MEDIUM FOUNDATION5
MINOR FOUNDATION1
PROCESSING15
MAJOR PROCESSING15
MEDIUM PROCESSING10
MINOR PROCESSING5
ORCHESTRATION20
MAJOR ORCHESTRATION20
MEDIUM ORCHESTRATION15
MINOR ORCHESTRATION10
COORDINATION20
MAJOR COORDINATION20
MEDIUM COORDINATION15
MINOR COORDINATION5
MANAGEMENT20
MAJOR MANAGEMENT20
MEDIUM MANAGEMENT15
MINOR MANAGEMENT5
AGGREGATION10
MAJOR AGGREGATION10
MEDIUM AGGREGATION5
MINOR AGGREGATION1
CONTROLLER5
MAJOR CONTROLLER5
MEDIUM CONTROLLER3
MINOR CONTROLLER1
ACCEPTANCE10
MAJOR ACCEPTANCE10
MEDIUM ACCEPTANCE5
MINOR ACCEPTANCE3
INTEGRATION15
MAJOR INTEGRATION15
MEDIUM INTEGRATION10
MINOR INTEGRATION10
VIEW10
MAJOR VIEW10
MEDIUM VIEW5
MINOR VIEW1
BASE5
MAJOR BASE5
MEDIUM BASE3
MINOR BASE1
COMPONENT15
MAJOR COMPONENT15
MEDIUM COMPONENT10
MINOR COMPONENT5
PAGE5
MAJOR PAGE5
MEDIUM PAGE3
MINOR PAGE1
CLIENT5
MAJOR CLIENT5
MEDIUM CLIENT3
MINOR CLIENT1
EXPOSER5
MAJOR EXPOSER5
MEDIUM EXPOSER3
MINOR EXPOSER1
DESIGN20
MAJOR DESIGN20
MEDIUM DESIGN10
MINOR DESIGN5
MAJOR FIX20
MEDIUM FIX10
MINOR FIX5
PLANNING15
MAJOR PLANNING15
MINOR PLANNING10
MINIOR PLANNING5
MENTORSHIP20
MAJOR MENTORSHIP20
MINOR MENTORSHIP15
MINIOR MENTORSHIP10
DISCUSSION15
MAJOR DISCUSSION15
MINOR DISCUSSION10
MINIOR DISCUSSION5
MAJOR CODE RUB10
MEDIUM CODE RUB5
MINOR CODE RUB1
CODE RUB1
PROVISION10
IMPORT5
RELEASE10
CONFIG5
REVIEW1
DOCUMENTATION1
STANDARD100
BUSINES50
STATUS1
UNKNOWN0

これらの各カテゴリーは、前のセクションで定義されています。

12.2.1 平均実装時間

次の表は、The Standard アーキテクチャのさまざまなレイヤーやコンポーネントの実装に必要な平均推定時間を示しています。
これらの時間は実務経験に基づいており、計画や工数見積もりの一般的な目安として使用されます。

レイヤー／コンポーネント平均時間
ブローカー、ベース約1時間
基盤、コンポーネント約3時間
処理、オーケストレーション、調整、オーケストレーションコンポーネント約5時間
管理、Uber Manager約3時間
コントローラー、ページ、クライアント約1時間

これらの見積もりは、標準的な複雑さで外部依存関係がない場合に、単一のサービスまたはコンポーネントを実装するために一般的に必要な期間を示しています。

12.2.2 ランク

以下は、The Standard コミュニティおよび Standard 準拠プロジェクトへの生涯にわたる累積貢献に基づくランクです。

POSITIONSCORE
SWE I10,000
SWE II25,000
SR. SWE50,000
PRINCIPAL100,000
PARTNER/DIRECTOR300,000
VP500,000
DISTINGUISHED1,000,000
THE STANDARD BEARER1M + DELEGATION

コメント

Markdown 対応