mcpField
G
gitlab-workflow

gitlab-workflow

github.com/mindrallyクラウド・DevOps2871.1k 回インストール3 週間前に更新
リポジトリ

gitlab-workflow について

gitlab-workflowは、GitLabを使うチーム向けのワークフロースキルです。コードレビュー、CI/CD、課題管理、DevOpsの実践方法を扱います。

主な機能

  1. 01マージリクエストの規約
  2. 02CI/CDパイプライン設計
  3. 03GitLab Flowのブランチ戦略
  4. 04課題とプロジェクトの管理
  5. 05アクセス制御とセキュリティ

活用シーン

  1. 01レビューしやすいマージリクエストの準備
  2. 02テスト・デプロイパイプラインの設計
  3. 03課題、ラベル、マイルストーンの整理
  4. 04リポジトリのセキュリティ設定

インストール

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

$npx skills add https://github.com/mindrally/skills --skill gitlab-workflow

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

詳細

GitLab ワークフローのベストプラクティス

マージリクエスト、CI/CD パイプライン、課題管理、DevOps のベストプラクティスなど、GitLab ワークフローに精通しています。

基本原則

  • すべてのコード変更でマージリクエストを使用し、十分にレビューします
  • .gitlab-ci.yml を使用して包括的な CI/CD パイプラインを実装します
  • GitLab Flow または同様のブランチ戦略に従います
  • GitLab に組み込まれた DevOps 機能を活用します
  • 適切なアクセス制御とスキャンによってセキュリティを維持します

マージリクエストのベストプラクティス

効果的なマージリクエストの作成
  1. MR は小さく、目的を絞ります

    • MR ごとに 1 つの機能または修正を含めます
    • 大きな変更は、レビューしやすい小さな単位に分割します
  2. MR のタイトル規約

    • Conventional Commits を使用します:feat: add user authentication
    • 課題への参照を含めます:feat: add login page (#123)
  3. MR の説明テンプレート

    ## Summary
    Brief description of what this MR accomplishes.
    
    ## Changes
    - List of specific changes
    
    ## Testing
    - How changes were tested
    - Test commands to run
    
    ## Checklist
    - [ ] Tests added/updated
    - [ ] Documentation updated
    - [ ] Pipeline passes
    
    ## Related Issues
    Closes #123
    
  4. 課題を適切にリンクします

    • Closes #123 を使用すると、マージ時に課題が自動的にクローズされます
    • クローズせずに参照する場合は Related to #123 を使用します
ドラフトマージリクエスト

作業中の変更にはドラフト MR を使用します:

  • タイトルの先頭に Draft: を付けるか、Draft ボタンを使用します
  • アプローチについて早い段階でフィードバックを求めます
  • 完了したら準備完了の状態に変更します

CI/CD パイプラインのベストプラクティス

基本的なパイプライン構成
stages:
  - build
  - test
  - security
  - deploy

variables:
  NODE_VERSION: "20"

default:
  image: node:${NODE_VERSION}
  cache:
    key: ${CI_COMMIT_REF_SLUG}
    paths:
      - node_modules/

build:
  stage: build
  script:
    - npm ci
    - npm run build
  artifacts:
    paths:
      - dist/
    expire_in: 1 week

test:
  stage: test
  script:
    - npm ci
    - npm test
  coverage: '/Coverage: \d+\.\d+%/'

lint:
  stage: test
  script:
    - npm ci
    - npm run lint
  allow_failure: false
高度なパイプライン機能
並列ジョブ
test:
  stage: test
  parallel: 3
  script:
    - npm ci
    - npm test -- --shard=$CI_NODE_INDEX/$CI_NODE_TOTAL
条件付きジョブ
deploy:production:
  stage: deploy
  script:
    - ./deploy.sh production
  rules:
    - if: $CI_COMMIT_BRANCH == "main"
      when: manual
    - when: never
  environment:
    name: production
    url: https://example.com
ジョブテンプレート
.test_template: &test_template
  stage: test
  before_script:
    - npm ci
  cache:
    key: ${CI_COMMIT_REF_SLUG}
    paths:
      - node_modules/

unit_tests:
  <<: *test_template
  script:
    - npm run test:unit

integration_tests:
  <<: *test_template
  script:
    - npm run test:integration
  services:
    - postgres:15
セキュリティスキャン
include:
  - template: Security/SAST.gitlab-ci.yml
  - template: Security/Dependency-Scanning.gitlab-ci.yml
  - template: Security/Secret-Detection.gitlab-ci.yml
  - template: Security/Container-Scanning.gitlab-ci.yml

sast:
  stage: security

dependency_scanning:
  stage: security

secret_detection:
  stage: security
複数環境へのデプロイ
.deploy_template:
  stage: deploy
  script:
    - ./deploy.sh $ENVIRONMENT
  environment:
    name: $ENVIRONMENT
    url: https://$ENVIRONMENT.example.com

deploy:staging:
  extends: .deploy_template
  variables:
    ENVIRONMENT: staging
  rules:
    - if: $CI_COMMIT_BRANCH == "develop"

deploy:production:
  extends: .deploy_template
  variables:
    ENVIRONMENT: production
  rules:
    - if: $CI_COMMIT_BRANCH == "main"
      when: manual

GitLab Flow

ブランチ戦略
  1. メインブランチ - 本番環境に対応したコード
  2. 機能ブランチ - feature/description という名前を付けます
  3. 環境ブランチ(任意)- staging、production
ワークフロー
  1. main から機能ブランチを作成します
  2. 変更を開発してコミットします
  3. プッシュしてマージリクエストを作成します
  4. レビュー、テストを行い、必要に応じて修正します
  5. main にマージします
  6. 自動または手動でデプロイします

課題とプロジェクトの管理

課題テンプレート

.gitlab/issue_templates/ に作成します:

Bug.md:

## Description
Clear description of the bug.

## Steps to Reproduce
1. Step one
2. Step two

## Expected vs Actual Behavior
- Expected:
- Actual:

## Environment
- Browser:
- OS:
- Version:

/label ~bug ~needs-triage

Feature.md:

## Problem Statement
Describe the problem this feature solves.

## Proposed Solution
Describe your proposed solution.

## Acceptance Criteria
- [ ] Criterion 1
- [ ] Criterion 2

/label ~feature ~needs-refinement
ラベルとボード

ラベルを使用して整理します:

  • 種類:~bug、~feature、~documentation
  • 優先度:~priority::high、~priority::medium、~priority::low
  • ステータス:~workflow::ready、~workflow::in-progress、~workflow::review
  • チーム:~team::backend、~team::frontend
マイルストーン
  • スプリントやリリースにマイルストーンを使用します
  • バーンダウンチャートで進捗を追跡します
  • 完了したらマイルストーンをクローズします

リポジトリ設定

保護ブランチ

main に次の設定を行います:

  • マージを許可するユーザー:メンテナー
  • プッシュを許可するユーザー:なし
  • 承認を必須にする
  • パイプラインの成功を必須にする
マージリクエストの設定
  • ファストフォワードマージまたはマージコミット
  • コミットをスカッシュするオプション
  • マージ後にソースブランチを削除
  • すべてのディスカッションの解決を必須にする

セキュリティのベストプラクティス

CI/CD 変数
# Use protected and masked variables
variables:
  DEPLOY_TOKEN:
    value: ""
    description: "Deployment authentication token"

Settings > CI/CD > Variables で設定します:

  • 保護:保護ブランチでのみ使用可能
  • マスク:ジョブログで非表示
アクセス制御
  • チームの権限にはグループを使用します
  • 最小権限の原則に従います
  • 2FA を必須にします
  • アクセスを定期的に監査します
コンプライアンス

コンプライアンス機能を有効にします:

  • マージリクエストの承認
  • プッシュルール
  • 監査イベント
  • コンプライアンスフレームワーク

Auto DevOps

すばやく設定するには、Auto DevOps を有効にします:

include:
  - template: Auto-DevOps.gitlab-ci.yml

variables:
  AUTO_DEVOPS_PLATFORM_TARGET: ECS
  POSTGRES_ENABLED: "true"

含まれる機能:

  • 自動ビルド
  • 自動テスト
  • 自動コード品質チェック
  • 自動 SAST
  • 自動依存関係スキャン
  • 自動コンテナースキャン
  • 自動レビューアプリ
  • 自動デプロイ

コメント