GH GambleHub

CI/CDパイプライン：GitHubアクション、GitLab CI

CI/CDパイプライン： GitHubアクション、GitLab CI

1） CI/CDタスクとプラットフォームスペース

CI/CDは、リポジトリから本番環境への変更の継続的なアセンブリ、テスト、および配信です。目的：
  • リリースのスピードと予測可能性（短いリードタイム）。
  • 品質（自動テスト、静的/動的解析）。
  • サプライチェーンセキュリティ（アーティファクト署名、アクセス制御）。
  • 信頼性（カナリア鉱床、高速ロールバック）。
  • 観測可能性（各ステージでのトレースとメトリック）。

主な原則：「コードとしてのパイプライン」、不変アーティファクト「、ビルド1回-多くの」、「shift-left security」、 「left privilege」、決定論的アセンブリを実行します。

2）コンベヤーの建築パターン

Stage-gate： build→test→security→package→deploy→post-deployチェック。
ファンアウト/ファンイン：結果を連結した並列行列アセンブリ（言語/プラットフォーム）。
プロモーション：同じアーティファクトが環境（dev→stage→prod）を通じてプロモートされ、再構成されません。
トランクベース+ショートブランチ：ドリフト最小化、PR/MRの自動チェック。
再利用可能：再利用可能なワークフローGitLab： includes/child-pipelines）。
GitOps（オプション）：「assembly」と「delivery」 （Argo CD/Fluxモニター宣言レポ環境）の分離。

3）サプライチェーンセキュリティ

識別：ランナーからクラウドまでのOIDCフェデレーション（長寿命キーなし）。
秘密：集中型ストレージ、コンテキスト制限、ロギングの禁止。
アーティファクト/コンテナ（cosign/Sigstore）の署名、入場管理における署名の検証。
SBOM （CycloneDX/SPDX）とSCA、 SAST/DAST/コンテナスキャン-「必須ゲート」。
政治家：OPA/Conftest for IaC/manifestos、 「no latest」、特権コンテナの禁止。
ランナーの分離：プライベートネットワーク内のプロッドランナー、公共インターネットからの個別の送信アクセス。

4） GitHubアクション-構造とプラクティス

4.1ワークフロー構造

'。github/workflows/。yml'-'（'on： push、 、 schedule、 。
標準化のための再利用可能なワークフロー（linter、 SCA、コンテナアセンブリ、展開）。

4.2例：OIDCと画像署名を備えたマルチステージパイプライン

yaml name: ci-cd

on:
push:
branches: [ "main" ]
pull_request:
branches: [ "main" ]

permissions:
id-token: write  # для OIDC contents: read packages: write

jobs:
build_test_matrix:
runs-on: ubuntu-latest strategy:
matrix:
node: [18, 20]
os: [ubuntu-latest]
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4 with: { node-version: ${{ matrix. node }} }
- name: Cache npm uses: actions/cache@v4 with:
path: ~/.npm key: npm-${{ runner. os }}-${{ matrix. node }}-${{ hashFiles('/package-lock. json') }}
- run: npm ci
- run: npm run lint && npm test -- --ci

docker_build_sign:
runs-on: ubuntu-latest needs: build_test_matrix steps:
- uses: actions/checkout@v4
- name: Login to GHCR uses: docker/login-action@v3 with:
registry: ghcr. io username: ${{ github. actor }}
password: ${{ secrets. GITHUB_TOKEN }}
- name: Build image run:
docker build --pull --no-cache -t ghcr. io/org/app:${{ github. sha }}.
docker push ghcr. io/org/app:${{ github. sha }}
- name: Generate SBOM uses: anchore/syft-action@v0 with:
image: ghcr. io/org/app:${{ github. sha }}
format: cyclonedx-json output-file: sbom. json
- name: Cosign sign (OIDC)
uses: sigstore/cosign-installer@v3
- name: Sign image run:
cosign sign ghcr. io/org/app:${{ github. sha }} \
--yes \
--identity-token $ACTIONS_ID_TOKEN_REQUEST_TOKEN \
--rekor-url https://rekor. sigstore. dev

deploy_stage:
runs-on: ubuntu-latest needs: docker_build_sign environment:
name: stage url: https://stage. example. com steps:
- uses: actions/checkout@v4
- name: Assume cloud role via OIDC uses: aws-actions/configure-aws-credentials@v4 with:
role-to-assume: arn:aws:iam::123456789012:role/github-deployer aws-region: eu-central-1
- name: Helm deploy (canary 10%)
run:
helm upgrade --install app charts/app \
--set image. tag=${{ github. sha }} \
--set canary. enabled=true --set canary. traffic=10
- name: Smoke checks run:./scripts/smoke. sh

promote_prod:
runs-on: ubuntu-latest needs: deploy_stage environment:
name: production url: https://app. example. com concurrency: prod-release steps:
- name: Manual approval gate run: echo "Requires environment approvers in repo settings"
- name: Promote canary → 100% (blue-green)
run:
helm upgrade --install app charts/app \
--set image. tag=${{ github. sha }} \
--set canary. enabled=false
- name: Post-deploy checks & rollback on SLO breach run:./scripts/verify_or_rollback. sh
キー：
  • 'permissions'は最小化され、'id-token： write'はOIDCで有効です。
  • 承認者とURLを持つ環境「、並行性」はレースから保護します。
  • トラフィックのカナリア包含とSLO上の自動ロールバック。

4.3再利用可能なワークフロー（コール例）

yaml jobs:
security_suite:
uses: org/.github/.github/workflows/security. yml@v1 with:
severity_threshold: high

5） GitLab CI-構造とプラクティス

5.1基本的な構造

'。gitlab-ci。yml'ルートで；キーエンティティ：'stage'、 'jobs'、' rules'、'needs'、'artifacts'、'environments'、'manual'。
再使用：'include：'（ローカル/リモートパターン）、複雑なモノレポの子/親パイプライン。

5.2例：行列、キャッシュ、署名、環境、承認

yaml stages: [lint, test, build, security, deploy]

variables:
DOCKER_TLS_CERTDIR: "" # docker: dind acceleration
IMAGE_TAG: $CI_COMMIT_SHA

lint:
stage: lint image: node:20 script:
- npm ci
- npm run lint cache:
key: "npm-${CI_COMMIT_REF_SLUG}"
paths: [node_modules/]
rules:
- if: $CI_PIPELINE_SOURCE == "merge_request_event"

test:
stage: test image: node:20 parallel:
matrix:
- NODE_VERSION: ["18", "20"]
script:
- nvm install $NODE_VERSION          true
- npm ci
- npm test -- --ci artifacts:
when: always reports:
junit: report. xml

build_image:
stage: build image: docker:26. 1 services: [ "docker:26. 1-dind" ]
script:
- docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
- docker build -t $CI_REGISTRY_IMAGE:$IMAGE_TAG.
- docker push $CI_REGISTRY_IMAGE:$IMAGE_TAG artifacts:
expire_in: 1 week paths: [ "sbom. json" ]
after_script:
- syft $CI_REGISTRY_IMAGE:$IMAGE_TAG -o cyclonedx-json > sbom. json

security_scans:
stage: security image: alpine:3. 20 script:
- trivy image --exit-code 0 --severity HIGH,CRITICAL $CI_REGISTRY_IMAGE:$IMAGE_TAG rules:
- if: '$CI_COMMIT_BRANCH == "main"'

deploy_stage:
stage: deploy image: bitnami/kubectl:1. 30 environment:
name: stage url: https://stage. example. com on_stop: stop_stage script:
- kubectl set image deploy/app app=$CI_REGISTRY_IMAGE:$IMAGE_TAG -n stage
-./scripts/smoke. sh needs: [build_image, security_scans]
when: manual allow_failure: false

stop_stage:
stage: deploy image: bitnami/kubectl:1. 30 environment:
name: stage action: stop script:
- kubectl rollout undo deploy/app -n stage

deploy_prod:
stage: deploy image: alpine/k8s:1. 30. 2 environment:
name: production url: https://app. example. com rules:
- if: '$CI_COMMIT_BRANCH == "main"'
when: manual allow_failure: false script:
-./scripts/canary_traffic. sh 10
-./scripts/verify_or_rollback. sh
キー：
  • 'parallel。matrix'は行列アセンブリをシミュレートします。
  • 'artifacts'+テストレポート。
  • 'on_stop'、 manual 'when： manual'が承認のための環境。
  • 画像を構築するためのDIND（より良い-Kaniko/BuildKit in the k8s runner）。

5.3子パイプラインとモノレポのために含める

yaml include:
- local:.gitlab/ci/includes/security. yml
- project: org/platform/pipelines file: /k8s/deploy. yml ref: v1

stages: [prepare, component_a, component_b, deploy]

component_a:
stage: component_a trigger:
include:.gitlab/ci/component_a. yml strategy: depend

component_b:
stage: component_b trigger:
include:.gitlab/ci/component_b. yml strategy: depend

6）モノレポジトリとマルチサービス

ディレクトリベースの所有権：CODEOWNERSとスコープ付きテストをパスごとに実行します。
差分ビルド：影響を受けるパッケージ/チャートを特定します。パスキーとロックファイルによるキャッシュ。
動的パイプライン：child-pipelines/' workflow_call'は変更されたコンポーネントに対してのみ実行されます。
バージョン管理：各モジュールのsemver、リリース段階のchangelog。

7）キャッシュと加速

コンテンツアドレスキャッシュ（hashFiles/lockfile）。
依存関係とアーティファクトのキャッシュを分離します。
プリウォームランナー画像（ツールチェーン、SDK）。
ローカルパケットミラー（npm/pip/maven）とコンテナレジストリキャッシュ。

8）リリース戦略とロールバック

カナリア州：徐々にトラフィックの割合を増加させます。SLOの劣化中に自動停止します。
ブルーグリーン：パラレルスタック、インスタントスイッチング。
Shadow：クライアントに影響を与えることなく、リクエストを複製します。
フィーチャーフラグ：フラッグレベルでロールアウトし、リリースレベルではありません。
ロールバック：1ボタンスクリプトをクリアすると、アーティファクトバージョンがリリースメタデータに保存されます。

9）インフラとGitOps

IaC： Terraform/Ansible/Helmは別々のリポジトリで管理されています。policy-as-code as a gate。
GitOps-contour： Argo CD/Fluxは環境のマニフェストでレポを観察します。パイプラインはアーティファクトのみを作成し、Gitでバージョンを更新します。
利点：環境変化の明確な履歴、idempotency、 Gitによる標準的なロールバック。

10） CI/CDの観察可能性

DORAメトリクス：枯渇率、コミットから本番までの時間、故障率、MTTR。
テレメトリー：ジョブキューの時間、ステージの持続時間、キャッシュのヒットレート、フラッキーテストの頻度。
セキュリティログ：誰がリリースを開始しましたか、どのゲートが通過しましたか、どの例外が発行されました。

11）アクセス管理および承認

ブランチ保護と必須チェック。
環境承認：ステージ/prodの個別の承認者リスト。
手動ステップ、セッションログのJITアクセス。
職務の分離：「write code」、 「approves」、 「releases」のさまざまな役割。

12）頻繁なエラー（アンチパターン）

OIDCの役割ではなく、レポの秘密の長寿命のクラウドキー。
ステージとプロッドのための異なるアーティファクトの組み立て（「ビルド1回」の違反）。
'latest'タグと可変画像。
ステップログ（非障害者マスキング）に秘密を公開します。
生産展開のための1つの一般的なパブリックランナー。
セキュリティ「gates」 （SAST/SCA/Policy）の欠如と展開後のチェック。

13）実装チェックリスト（0-60日）

0-15日

トランクベースのPR/MRルール、必須の静的チェックを構成します。
クラウドへのOIDCフェデレーションを有効にします。最小限の'permissions'。
ポストランナー：パブリック-CI用、プライベート-CD用。

16-30日

SBOM、イメージ署名を追加します。クラスタ-署名検証。
カナリア/ブルーグリーンを入力してください。SLOによる自動ロールバック。
依存関係とアーティファクトのキャッシュ、プリウォームイメージ。

31-60日

個別のアセンブリとデリバリー（GitOps）、ポリシーアズコードゲート。
パイプラインの劣化のためのDORAメトリックとアラートを確立します。
すべてのサービスのテンプレートパイプライン（再利用可能/子）。

14）実用的な信頼性のヒント

小さい、速いパイプラインを支えて下さい（PR信号の10-12分前に）。
flakyテストを殺す：検疫タグ+平行修正。
CIアーティファクトとリリースアーティファクトを混在させないでください。ストアメタデータ（コミット、時間、SBOM、署名）。
開発者にローカルスクリプトをパイプラインステップ（dev-prodパリティ）と同一にします。

15）再利用のためのテンプレート

15.1 GitHubアクション-セキュリティ再利用可能なワークフロー（簡略化）

yaml name: security-suite on:
workflow_call:
inputs:
severity_threshold:
type: string required: false default: high jobs:
sast_sca:
runs-on: ubuntu-latest steps:
- uses: actions/checkout@v4
- run:./sec/sast. sh --threshold ${{ inputs. severity_threshold }}
- run:./sec/sca. sh --format cyclonedx-json --out sbom. json artifacts: # if using actions/upload-artifact
- sbom. json

15.2 GitLab-テンプレート展開を含める（簡略化）

yaml
.deployment_template:
image: alpine/k8s:1. 30 script:
- helm upgrade --install $APP charts/$APP --set image. tag=$IMAGE_TAG rules:
- if: '$CI_COMMIT_BRANCH == "main"'

16）結論

GitHub ActionsとGitLab CIは、高速で安全なコード→prodループのための成熟したメカニズムを提供します。成功の鍵は標準化とセキュリティです。OIDCではなく、キー、シグネチャ、SBOM、品質ゲート、プロモーション付きの単一のアーティファクト、GitOpsの配信、DORAによるオブザビリティ。製品としてパイプラインを構築する：測定、簡素化、スピードアップ-リリースはイベントではなくコアになります。

Contact

お問い合わせ

ご質問やサポートが必要な場合はお気軽にご連絡ください。いつでもお手伝いします！

Telegram
@Gamble_GC
統合を開始

Email は 必須。Telegram または WhatsApp は 任意。

お名前 任意
Email 任意
件名 任意
メッセージ 任意
Telegram 任意
@
Telegram を入力いただいた場合、Email に加えてそちらにもご連絡します。
WhatsApp 任意
形式：+国番号と電話番号（例：+81XXXXXXXXX）。

ボタンを押すことで、データ処理に同意したものとみなされます。