- プロジェクト名: [あなたのGEMINIプロジェクトの簡潔で分かりやすいタイトル]
- プロジェクトID/コード: [プロジェクトの一意の識別子。例:
GMN-001] - 説明:
- このGEMINIプロジェクトが解決しようとしている問題は何ですか？
- 主な目的とスコープは何ですか？
- GEMINIが提供する主要な機能や洞察を簡潔に説明してください。
- ステータス: [例:
進行中,アルファ,ベータ,本番稼働中,アーカイブ済み] - 最終更新日: [YYYY-MM-DD] (これは自動化されるのが理想です)
このセクションでは、このGEMINIプロジェクトをサポートするインフラストラクチャがどのようにコードとして定義および管理されているかを説明します。
- クラウドプロバイダー: [例: GCP, AWS, Azure, オンプレミス]
- IaCツール: [例: Terraform, CloudFormation, Pulumi, Ansible]
- リポジトリの場所:
- IaC定義を含むリポジトリへのリンク (例:
iac-repo-link/path/to/project-iac) - 関連するディレクトリ/ファイルを指定してください。
- IaC定義を含むリポジトリへのリンク (例:
- デプロイプロセス:
- インフラストラクチャをデプロイまたは更新するための自動化された手順を概説してください。
- 関連するCI/CDパイプライン (例: Jenkins, GitHub Actions, GitLab CI) に言及してください。
- 主要なインフラストラクチャコンポーネント:
- [例:
Compute Instances(タイプと数をコードとして指定)] - [例:
Databases(タイプ、構成パラメータをコードとして指定)] - [例:
Networking(VPC/VNet定義、ファイアウォールルールをコードとして指定)] - [例:
Storage Buckets(命名規則、ポリシーをコードとして指定)] - [プロジェクトに関連するものを追加してください]
- [例:
このセクションでは、アプリケーションとサービスの構成がどのようにバージョン管理され、コードとして管理されているかを詳述します。
- 構成管理ツール: [例: Gitベースの構成ファイル, Consul, etcd, ConfigMaps (Kubernetes)]
- リポジトリの場所:
- 構成ファイルを含むリポジトリへのリンク (例:
config-repo-link/path/to/project-config) - 関連するディレクトリ/ファイルを指定してください。
- 構成ファイルを含むリポジトリへのリンク (例:
- 主要な構成パラメータ:
- [重要な環境変数や構成設定をリストアップ]
- [機密情報がどのように扱われるかを指定 (例: シークレット管理)]
- 構成のデプロイ:
- 構成の変更がどのように適用され、伝播されるかを説明してください。
- 自動化された検証やロールバックメカニズムに言及してください。
このセクションは、データスキーマ、モデル、変換がどのようにコードとして定義および管理されているかに焦点を当てています。
- スキーマ定義言語/ツール: [例: SQL DDL, Protobuf, Avro, JSON Schema, OpenAPI Specification]
- リポジトリの場所:
- データ定義を含むリポジトリへのリンク (例:
data-definitions-repo-link/path/to/schemas)
- データ定義を含むリポジトリへのリンク (例:
- データストア: [例:
PostgreSQL,BigQuery,Elasticsearch,Cloud Storage] - 主要なデータモデル/スキーマ:
- [主要なデータエンティティとその構造をリストアップし、簡潔に説明してください。]
- [スキーマの変更がどのように管理されるか (例: マイグレーション) を説明してください。]
- ETL/ELTパイプライン as Code:
- 該当する場合、データ変換ロジックがどのように定義されているか (例: Pythonスクリプト, SQLスクリプト, Dataflowテンプレート, DBTモデル) を説明してください。
- これらのパイプラインを制御するコードへのリンク。
これは通常標準的ですが、「Everything as Code」の哲学との統合を強調してください。
- リポジトリの場所: [メインアプリケーションのソースコードリポジトリへのリンク]
- プログラミング言語: [例: Python, Go, Java, Node.js]
- フレームワーク/ライブラリ: [主要な使用フレームワークをリストアップ]
- ビルド/テストプロセス:
- アプリケーションはどのように自動的にビルドされ、テストされますか？
- ビルドとテストのためのCI/CDパイプラインに言及してください。
- デプロイ戦略:
- 自動化されたデプロイプロセスを説明してください (例: Dockerイメージ, Kubernetesデプロイメント, サーバーレス関数)。
このセクションでは、テスト（単体、統合、エンドツーエンド、パフォーマンス）がどのようにコードの一部として定義され、実行されるかを説明します。
- テストフレームワーク: [例: Pytest, JUnit, Jest, Selenium, Locust]
- テストリポジトリの場所: [メインリポジトリ内のテストコードまたは別のテストリポジトリへのリンク]
- テストの種類:
- 単体テスト: [どのように、いつ実行されますか？]
- 統合テスト: [どのように、いつ実行されますか？]
- エンドツーエンドテスト: [どのように、いつ実行されますか？]
- パフォーマンステスト: [どのように定義され、実行されますか？]
- セキュリティテスト: [例: CI/CDに統合されたSAST/DASTツール]
- テストの自動化: 自動テストのためのCI/CDパイプラインのステップを説明してください。
監視設定、ダッシュボード、アラートがどのようにコードとして管理されるかを定義します。
- 監視ツール: [例: Prometheus, Grafana, Datadog, Stackdriver Monitoring, CloudWatch]
- アラートツール: [例: Alertmanager, PagerDuty, Slack, Opsgenie]
- 構成リポジトリの場所:
- 監視/アラート定義を含むリポジトリへのリンク (例:
monitoring-repo-link/path/to/dashboards/alerts) - 関連するファイルを指定してください (例: GrafanaダッシュボードのJSON, Prometheusのアラートルール)。
- 監視/アラート定義を含むリポジトリへのリンク (例:
- 監視対象の主要なメトリクス:
- [重要なアプリケーション/インフラストラクチャのメトリクスをリストアップ]
- アラートルール:
- [主要なアラート条件と通知チャネルを簡潔に説明]
セキュリティポリシー、アクセス制御、コンプライアンスチェックがどのようにコードを通じて定義され、実施されるか。
- ポリシー実施ツール: [例: OPA, HashiCorp Sentinel, AWS Organizations SCPs, GCP Organization Policies]
- リポジトリの場所: [セキュリティポリシー定義へのリンク]
- アクセス制御:
- IAM/RBACポリシーはどのようにコードとして定義されていますか？ (例: IAMのためのTerraform)
- セキュリティスキャン/チェック:
- CI/CDにおける自動セキュリティスキャンを説明してください (例:
linters,static analysis,dependency vulnerability scans)。
- CI/CDにおける自動セキュリティスキャンを説明してください (例:
- コンプライアンス要件: [関連するコンプライアンス標準 (例: GDPR, HIPAA, SOC2) と、それらがコードを通じてどのように対応されているかをリストアップしてください。]
このGEMINI.mdファイルは「Documentation as Code」の一例です。すべてのドキュメントは関連するコードとともにバージョン管理されるべきです。
- ドキュメントツール/フォーマット: [例: Markdown, reStructuredText, Sphinx, AsciiDoc]
- リポジトリの場所: [プロジェクト内の主要なドキュメントディレクトリまたは専用のドキュメントリポジトリへのリンク]
- 生成/公開:
- ドキュメントはどのように生成または公開されますか？ (例: 静的サイトジェネレーター, ReadTheDocs)
- ドキュメント更新のための自動パイプラインに言及してください。
インシデント対応、災害復旧、ルーチンメンテナンスのための運用手順がどのように文書化され、自動化されているか。
- フォーマット: [例: Markdown, Ansible Playbooks, Shell Scripts]
- リポジトリの場所: [ランブック/プレイブックのリポジトリまたはディレクトリへのリンク]
- 主要な手順:
- [重要なランブックをリストアップ (例:
データベース復元,アプリケーションロールバック,サービス再起動)] - [自動化されている場合は、関連するスクリプトまたは自動化コードへのリンク。]
- [重要なランブックをリストアップ (例:
プロジェクトコンポーネントがどのようにバージョン管理され、「Everything as Code」に従ってリリースがどのように管理されるか。
- バージョニング戦略: [例: セマンティックバージョニング (SemVer)]
- リリースプロセス:
- リリースにタグ付けし、変更ログを作成し、環境にデプロイするための自動化された手順を説明してください。
- 関連するCI/CDパイプラインに言及してください。
- 変更ログの場所: [
CHANGELOG.mdまたはリリースノートへのリンク]
他の人がこのGEMINIプロジェクトに、すべての「as Code」コンポーネントへの変更を含めて、どのように貢献できるか。
- 貢献プロセス:
- [例: フォーク, ブランチ戦略 (GitFlow, GitHub Flow), プルリクエスト/マージリクエストプロセス]
- [コードレビューガイドライン]
- スタイルガイド: [関連するコーディングまたはドキュメンテーションのスタイルガイドへのリンク]
- 連絡先/サポート: [プロジェクトメンテナーへの連絡方法]
- ライセンスの種類: [例: MIT, Apache 2.0, GPLv3]
- ライセンスファイルの場所: [
LICENSEファイルへのリンク]