黄金の道とは
I 黄金の道 （またはゴールデンロード）は、標準化され最適化されたルートです。 新しいサービスの作成からサービスの作成まで、最も一般的なワークフローを通じて開発者を支援します。 実稼働環境への導入、インフラストラクチャ構成から監視セットアップまで。それらは、 組織のベスト プラクティスが、再利用可能なテンプレート、自動化、ワークフローに凝縮されています。
ゴールデン パスのコンセプトは、Spotify の内部開発者の一環として普及しました。 プラットフォーム。基本的でシンプルなアイデア: 各開発者が自由に再発明できるようにするのではなく ホイールを操作すると (結果に一貫性がありません)、すべての要素を組み込んだ最適なパスが定義されます。 セキュリティ、パフォーマンス、可観測性、コンプライアンスのベスト プラクティス。
黄金の道はそうではないということを指摘することが重要です。 黄金の檻。彼らは妨げない 開発者は必要に応じて標準パスから逸脱することもできますが、標準的な選択を行います 非常にシンプルで魅力的なため、ほとんどの場合、これが自然な選択となります。
何を学ぶか
- ゴールデン パスの概念とそれが認知負荷を 60% 軽減する理由
- Web アプリ、API、マイクロサービス、インフラストラクチャのゴールデン パスを定義する方法
- テンプレート エンジン: Cookiecutter、Helm、Kustimize、カスタム ソリューション
- Yeoman、Nx ジェネレーター、カスタム CLI による自動スキャフォールディング
- テンプレートのガバナンス: バージョン管理、承認、メンテナンス
- 導入の指標と過剰な標準化の落とし穴を回避する方法
アプリケーションの種類ごとにゴールデン パスを定義する
ゴールデン パスを構築するための最初のステップは、 アプリケーションの種類 組織内で最も一般的なルートを選択し、それぞれに最適化されたルートを作成します。典型的なカテゴリは次のとおりです。
- ウェブアプリケーション: SSR、CDN、フロントエンド監視、A/B テストを備えた React/Angular/Vue フロントエンド
- REST API: データベース、キャッシュ、レート制限、OpenAPI ドキュメント、ヘルス チェックを備えたバックエンド サービス
- イベント駆動型ワーカー: 再試行ポリシー、デッドレターキュー、スループットメトリクスを備えた Kafka/RabbitMQ コンシューマ
- スケジュールされたジョブ: アラート、構造化ログ、自動再試行を備えた Kubernetes CronJob
- インフラストラクチャモジュール: テスト、ドキュメント、セマンティック バージョニングを備えた再利用可能な Terraform/Pulumi モジュール
ゴールデン パスは、タイプごとに、プロジェクトの構造、依存関係、構成を定義します。 CI/CD、Dockerfile、Kubernetes マニフェスト、モニタリング、ロギング、ドキュメント。
# Golden Path: definizione per REST API service
golden-path-rest-api:
name: "REST API Microservice"
description: "Percorso standard per creare un nuovo microservizio REST"
version: "2.1.0"
scaffolding:
language: TypeScript
framework: NestJS
structure:
- src/
- controllers/ # Route handlers
- services/ # Business logic
- models/ # Data models
- middleware/ # Auth, logging, validation
- config/ # Environment configuration
- test/
- unit/
- integration/
- e2e/
- docs/ # API documentation
- .github/workflows/ # CI/CD pipelines
included-features:
- health-check: "/health and /ready endpoints"
- openapi-docs: "Swagger UI at /api/docs"
- structured-logging: "JSON logs with correlation ID"
- metrics: "Prometheus metrics at /metrics"
- tracing: "OpenTelemetry auto-instrumentation"
- error-handling: "Centralized error handler with standard format"
- authentication: "JWT validation middleware"
- rate-limiting: "Per-client rate limiting"
ci-cd:
pipeline: GitHub Actions
stages:
- lint-and-format
- unit-tests (coverage > 80%)
- integration-tests
- security-scan (Snyk/Trivy)
- build-docker-image
- push-to-registry
- deploy-staging
- smoke-tests
- deploy-production (manual approval)
テンプレートと足場
I テンプレート これらはゴールデン パスの技術の中核です。生成できるものはほとんどありません 2 つ目は、組織のすべてのベスト プラクティスがすでに構成されている完全なプロジェクトです。 主なテンプレート ツールは次のとおりです。
- クッキーカッター: Python ベースのテンプレート エンジン、シンプルで人気があり、多言語プロジェクトに最適
- バックステージ ソフトウェア テンプレート: Web UI と承認ワークフローを備えた Backstage に統合された足場システム
- ヨーマン: インタラクティブなプロンプト、サブジェネレーター、構成を備えた Node.js ジェネレーター
- Nx ジェネレーター: Nx monorepo ツールに統合されたジェネレーター。Angular、React、Node.js プロジェクトに最適です。
- カスタムCLI: Commander.js、Inquirer.js、または Click (Python) で構築された内部 CLI ツール
# Backstage Software Template: scaffolding REST API
apiVersion: scaffolder.backstage.io/v1beta3
kind: Template
metadata:
name: rest-api-template
title: REST API Microservice
description: "Crea un nuovo microservizio REST con NestJS, Docker e CI/CD"
tags:
- typescript
- nestjs
- rest-api
- recommended
spec:
owner: platform-team
type: service
parameters:
- title: Service Info
required: [name, description, owner]
properties:
name:
title: Service Name
type: string
pattern: "^[a-z][a-z0-9-]*$"
description: "Nome del servizio (lowercase, hyphens)"
description:
title: Description
type: string
owner:
title: Owner Team
type: string
ui:field: OwnerPicker
- title: Technical Options
properties:
database:
title: Database
type: string
enum: [postgresql, mysql, mongodb, none]
default: postgresql
cache:
title: Cache Layer
type: string
enum: [redis, memcached, none]
default: redis
messageQueue:
title: Message Queue
type: string
enum: [kafka, rabbitmq, none]
default: none
steps:
- id: fetch-template
name: Fetch Template
action: fetch:template
input:
url: ./skeleton
values:
name: ${{ parameters.name }}
owner: ${{ parameters.owner }}
- id: publish
name: Publish to GitHub
action: publish:github
input:
repoUrl: github.com?owner=company&repo=${{ parameters.name }}
- id: register
name: Register in Catalog
action: catalog:register
input:
repoContentsUrl: ${{ steps.publish.output.repoContentsUrl }}
catalogInfoPath: /catalog-info.yaml
ゴールデン パスを使用した開発者のオンボーディング
ゴールデン パスの最も具体的な利点の 1 つは、処理時間の大幅な短縮です。 オンボーディング。 新しい開発者は、何十もの異なる構成を理解する必要がなく、次のパスに従うことができます。 標準化されており、非常に短期間で生産性が向上します。
Golden Paths ベースのオンボーディング プログラムには次のものが含まれます。
- 1日目: 自動スクリプトを使用したローカル環境のセットアップ、開発者ポータルへのアクセス、開発環境への最初のデプロイメント
- 2～3日目: ゴールデン パスを使用したテスト マイクロサービスの作成、CI/CD とモニタリングの理解
- 1週目: 最初の実際のプロジェクトへの貢献、セキュリティとガバナンスのポリシーの理解
- 2週目: プラットフォームを介したサービスの作成と管理における完全な自律性
オンボーディングに関する重要な事実
明確に定義されたゴールデン パスを持つ組織は、 オンボーディング時間が 80% 削減されました: 平均して 3 ～ 4 週間から 3 ～ 4 日になります。これは、両方の面で大幅な節約になります。 新しい開発者と彼をサポートするチームの時間。
テンプレートガバナンス
ゴールデン パスは静的なものではありません。組織、ベスト プラクティス、およびサービスに応じて進化する必要があります。 テクノロジー。効果的なテンプレート ガバナンスには次のものが含まれます。
- セマンティック バージョニング: 各テンプレートは SemVer に従っており、重大な変更が明確に伝えられています。
- レビュープロセス: テンプレートへの変更には、プラットフォーム チームと主要な関係者によるレビューが必要です
- 自動テスト: 各テンプレートには、スキャフォールディングが機能するプロジェクトを生成することを検証するテスト スイートがあります。
- 非推奨ポリシー: 非推奨のテンプレートは、定義された移行期間とともに非推奨になります
- 変更履歴: 各バージョンには、変更とその理由を説明する詳細な変更ログがあります。
# Template governance: CI pipeline per validazione template
name: Validate Golden Path Template
on:
pull_request:
paths:
- 'templates/**'
jobs:
validate-template:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Scaffold test project
run: |
npx cookiecutter templates/rest-api \
--no-input \
service_name=test-service \
owner=platform-team \
database=postgresql
- name: Verify project structure
run: |
test -f test-service/Dockerfile
test -f test-service/package.json
test -f test-service/.github/workflows/ci.yml
test -f test-service/catalog-info.yaml
test -d test-service/src/controllers
test -d test-service/test
- name: Run generated project tests
working-directory: test-service
run: |
npm install
npm run lint
npm run test
npm run build
- name: Build Docker image
working-directory: test-service
run: docker build -t test-service:test .
- name: Security scan
run: trivy image test-service:test
導入指標
ゴールデン パスが機能しているかどうかを理解するには、 導入指標。 主要な指標は次のとおりです。
- 採用率: ゴールデン パスを使用して作成された新しいサービスの割合 (目標: >80%)
- 最初の展開までの時間: サービスの作成から最初のステージング展開までの時間
- テンプレートの満足度: 利用可能なテンプレートに関する開発者の NPS スコア
- 偏差値: チームが標準的な道から外れる頻度とその理由
- テンプレートの鮮度: テンプレートの平均経過時間と更新頻度
高い偏差率は必ずしもマイナスではありません。ゴールデン パスがカバーしていないことを示している可能性があります。 すべてのユースケース、または更新が必要なユースケース。逸脱する開発者のフィードバック 標準パスと、テンプレートを改善するための貴重な情報源から取得します。
避けるべき罠
ゴールデン パスの実装には、いくつかの一般的な落とし穴があります。
- 過剰な標準化: 創造性や革新性の余地を残さない、厳格すぎるテンプレートを押し付けます。黄金の道は押し付けではなく推奨である必要があります
- テンプレートのドリフト: テンプレートは更新されず、現在のベスト プラクティスと比較して時代遅れになります。
- 文書の不足: 明確なドキュメントのないテンプレートは役に立ちません。各テンプレートには詳細な README、例、FAQ が必要です
- フィードバックを無視する: テンプレートに関する開発者のフィードバックを収集しない、または無視すると、採用率が低くなり、不満が生じます。
- 1 つのテンプレートですべてに対応: すべてのユースケースをカバーする単一のテンプレートを作成しようとすると、不必要な複雑さが生じます。タイプごとに特化したテンプレートを用意したほうがよい
黄金の道の黄金律
最高のゴールデンパスと開発者の考え 彼らは自発的に選択します なぜ それは彼らの仕事を楽にするものであり、強制的に使用するものではありません。黄金の道を課す必要がある場合、 おそらく十分ではありません。標準ルートを最も簡単なルートにすることに投資してください。