devops-cicd
CI/CDパイプラインの構築・最適化、インフラのコード化(IaC)、およびデプロイ戦略の立案・実装を支援します。GitHub ActionsやTerraformなどのツールを活用し、開発から本番環境へのリリースフローを自動化・効率化したい場面で活躍します。
description の原文を見る
CI/CD pipelines, infrastructure as code, and deployment strategies
SKILL.md 本文
DevOps & CI/CD
概要
ビルド、テスト、デプロイメントパイプラインを自動化するための実践方法。
CI/CDパイプライン
パイプラインステージ
┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐
│ Commit │ → │ Build │ → │ Test │ → │ Deploy │ → │ Release │
│ │ │ │ │ │ │ Staging │ │ Prod │
└──────────┘ └──────────┘ └──────────┘ └──────────┘ └──────────┘
│ │ │ │ │
│ ┌────┴────┐ ┌────┴────┐ │ │
│ │ Compile │ │ Unit │ │ │
│ │ Lint │ │ Integ │ │ │
│ │ Type │ │ E2E │ │ │
│ └─────────┘ └─────────┘ │ │
│ │ │
Trigger Manual? Approval?
GitHub Actions
# .github/workflows/ci.yml
name: CI
on:
push:
branches: [main]
pull_request:
branches: [main]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Setup Node.js
uses: actions/setup-node@v4
with:
node-version: '20'
cache: 'npm'
- name: Install dependencies
run: npm ci
- name: Lint
run: npm run lint
- name: Type check
run: npm run type-check
- name: Test
run: npm run test -- --coverage
- name: Upload coverage
uses: codecov/codecov-action@v3
- name: Build
run: npm run build
- name: Upload build artifact
uses: actions/upload-artifact@v4
with:
name: build
path: dist/
deploy-staging:
needs: build
if: github.ref == 'refs/heads/main'
runs-on: ubuntu-latest
environment: staging
steps:
- name: Download build artifact
uses: actions/download-artifact@v4
with:
name: build
path: dist/
- name: Deploy to staging
run: |
# Deploy script here
echo "Deploying to staging..."
deploy-production:
needs: deploy-staging
runs-on: ubuntu-latest
environment:
name: production
url: https://myapp.com
steps:
- name: Deploy to production
run: |
echo "Deploying to production..."
マトリックスビルド
jobs:
test:
runs-on: ${{ matrix.os }}
strategy:
matrix:
os: [ubuntu-latest, windows-latest, macos-latest]
node: [18, 20, 22]
exclude:
- os: windows-latest
node: 18
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: ${{ matrix.node }}
- run: npm ci
- run: npm test
デプロイメント戦略
ブルーグリーンデプロイメント
デプロイ前:
┌─────────────────────────────────────────┐
│ ロードバランサー │
└─────────────────┬───────────────────────┘
│
┌───────┴───────┐
↓ ↓
┌───────────┐ ┌───────────┐
│ Blue │ │ Green │
│ (v1.0) │ │ (待機中) │
│ アクティブ │ │ │
└───────────┘ └───────────┘
Greenへv1.1をデプロイ:
┌───────────┐ ┌───────────┐
│ Blue │ │ Green │
│ (v1.0) │ │ (v1.1) │
│ アクティブ │ │ テスト中 │
└───────────┘ └───────────┘
トラフィックを切り替え:
┌───────────────┐
↓ ↓
┌───────────┐ ┌───────────┐
│ Blue │ │ Green │
│ (v1.0) │ │ (v1.1) │
│ 待機中 │ │ アクティブ │
└───────────┘ └───────────┘
カナリアデプロイメント
# Argo Rolloutsを使用したKubernetesカナリアデプロイメント
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
name: my-app
spec:
replicas: 10
strategy:
canary:
steps:
- setWeight: 10 # 新しいバージョンへの10%のトラフィック
- pause: { duration: 5m }
- setWeight: 30
- pause: { duration: 5m }
- setWeight: 50
- pause: { duration: 10m }
- setWeight: 100
analysis:
templates:
- templateName: success-rate
startingStep: 2 # 30%での分析開始
args:
- name: service-name
value: my-app
ローリングアップデート
# Kubernetesローリングアップデート
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app
spec:
replicas: 4
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 1 # レプリカ数を1超えることが可能
maxUnavailable: 0 # アップデート中はすべて利用可能
template:
spec:
containers:
- name: app
image: my-app:v1.1
readinessProbe:
httpGet:
path: /health
port: 8080
initialDelaySeconds: 5
periodSeconds: 5
インフラストラクチャアズコード
Terraform
# main.tf
terraform {
required_providers {
aws = {
source = "hashicorp/aws"
version = "~> 5.0"
}
}
backend "s3" {
bucket = "my-terraform-state"
key = "prod/terraform.tfstate"
region = "us-east-1"
}
}
# 変数
variable "environment" {
type = string
default = "production"
}
variable "instance_count" {
type = number
default = 2
}
# リソース
resource "aws_vpc" "main" {
cidr_block = "10.0.0.0/16"
tags = {
Name = "main-vpc"
Environment = var.environment
}
}
resource "aws_instance" "web" {
count = var.instance_count
ami = "ami-0c55b159cbfafe1f0"
instance_type = "t3.micro"
vpc_security_group_ids = [aws_security_group.web.id]
tags = {
Name = "web-${count.index}"
}
}
# 出力
output "instance_ips" {
value = aws_instance.web[*].public_ip
}
Terraformモジュール
# modules/vpc/main.tf
variable "cidr_block" {
type = string
}
variable "environment" {
type = string
}
resource "aws_vpc" "this" {
cidr_block = var.cidr_block
tags = {
Environment = var.environment
}
}
output "vpc_id" {
value = aws_vpc.this.id
}
# モジュールの使用
module "vpc" {
source = "./modules/vpc"
cidr_block = "10.0.0.0/16"
environment = "production"
}
resource "aws_subnet" "main" {
vpc_id = module.vpc.vpc_id
# ...
}
Docker
Dockerfileのベストプラクティス
# 特定のバージョンタグを使用
FROM node:20-alpine AS builder
# 作業ディレクトリを設定
WORKDIR /app
# 依存ファイルを最初にコピー (レイヤーキャッシュ)
COPY package*.json ./
# 依存関係をインストール
RUN npm ci --only=production
# ソースコードをコピー
COPY . .
# アプリケーションをビルド
RUN npm run build
# 本番ステージ - より小さい最終イメージ
FROM node:20-alpine AS production
WORKDIR /app
# 非rootユーザーを作成
RUN addgroup -g 1001 -S nodejs && \
adduser -S nodejs -u 1001
# ビルダーからコピー
COPY --from=builder --chown=nodejs:nodejs /app/dist ./dist
COPY --from=builder --chown=nodejs:nodejs /app/node_modules ./node_modules
# 非rootユーザーを使用
USER nodejs
# ポートを公開
EXPOSE 3000
# ヘルスチェック
HEALTHCHECK --interval=30s --timeout=3s --start-period=5s \
CMD wget --quiet --tries=1 --spider http://localhost:3000/health || exit 1
# アプリケーションを実行
CMD ["node", "dist/index.js"]
Docker Compose
# docker-compose.yml
version: '3.8'
services:
app:
build:
context: .
dockerfile: Dockerfile
ports:
- "3000:3000"
environment:
- DATABASE_URL=postgres://postgres:password@db:5432/myapp
- REDIS_URL=redis://cache:6379
depends_on:
db:
condition: service_healthy
cache:
condition: service_started
db:
image: postgres:15-alpine
volumes:
- postgres_data:/var/lib/postgresql/data
environment:
- POSTGRES_PASSWORD=password
- POSTGRES_DB=myapp
healthcheck:
test: ["CMD-SHELL", "pg_isready -U postgres"]
interval: 5s
timeout: 5s
retries: 5
cache:
image: redis:7-alpine
volumes:
- redis_data:/data
volumes:
postgres_data:
redis_data:
Kubernetes
基本的なデプロイメント
# deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app
labels:
app: my-app
spec:
replicas: 3
selector:
matchLabels:
app: my-app
template:
metadata:
labels:
app: my-app
spec:
containers:
- name: my-app
image: my-app:v1.0.0
ports:
- containerPort: 3000
resources:
requests:
memory: "128Mi"
cpu: "100m"
limits:
memory: "256Mi"
cpu: "500m"
livenessProbe:
httpGet:
path: /health/live
port: 3000
initialDelaySeconds: 3
periodSeconds: 10
readinessProbe:
httpGet:
path: /health/ready
port: 3000
initialDelaySeconds: 5
periodSeconds: 5
env:
- name: DATABASE_URL
valueFrom:
secretKeyRef:
name: app-secrets
key: database-url
---
apiVersion: v1
kind: Service
metadata:
name: my-app
spec:
selector:
app: my-app
ports:
- port: 80
targetPort: 3000
type: ClusterIP
ConfigMapsとSecrets
# configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
name: app-config
data:
LOG_LEVEL: "info"
MAX_CONNECTIONS: "100"
---
# secret.yaml (base64エンコード)
apiVersion: v1
kind: Secret
metadata:
name: app-secrets
type: Opaque
data:
database-url: cG9zdGdyZXM6Ly91c2VyOnBhc3NAaG9zdDo1NDMyL2Ri
GitOps
ArgoCDアプリケーション
# application.yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: my-app
namespace: argocd
spec:
project: default
source:
repoURL: https://github.com/org/k8s-manifests.git
targetRevision: HEAD
path: apps/my-app/production
destination:
server: https://kubernetes.default.svc
namespace: production
syncPolicy:
automated:
prune: true
selfHeal: true
syncOptions:
- CreateNamespace=true
フィーチャーフラグ
// LaunchDarkly / Unleashパターンの使用
interface FeatureFlags {
newCheckoutFlow: boolean;
betaFeatures: boolean;
maxUploadSize: number;
}
class FeatureFlagService {
constructor(private client: FeatureFlagClient) {}
async isEnabled(flag: keyof FeatureFlags, user?: User): Promise<boolean> {
return this.client.getBooleanValue(flag, false, {
userId: user?.id,
email: user?.email,
groups: user?.groups
});
}
}
// 使用例
if (await featureFlags.isEnabled('newCheckoutFlow', user)) {
return <NewCheckoutFlow />;
} else {
return <LegacyCheckout />;
}
関連スキル
- [[testing-strategies]] - CIテスト統合
- [[reliability-engineering]] - デプロイメント信頼性
- [[monitoring-observability]] - デプロイメント監視
ライセンス: MIT(寛容ライセンスのため全文を引用しています) · 原本リポジトリ
詳細情報
- 作者
- miles990
- ライセンス
- MIT
- 最終更新
- 不明
Source: https://github.com/miles990/claude-software-skills / ライセンス: MIT
関連スキル
superpowers-streamer-cli
SuperPowers デスクトップストリーマーの npm パッケージをインストール、ログイン、実行、トラブルシューティングできます。ユーザーが npm から `superpowers-ai` をセットアップしたい場合、メールまたは電話でサインインもしくはアカウント作成を行いたい場合、ストリーマーを起動したい場合、表示されたコントロールリンクを開きたい場合、後で停止したい場合、またはソースコードへのアクセスなしに npm やランタイムの一般的な問題から復旧したい場合に使用します。
catc-client-ops
Catalyst Centerのクライアント操作・監視機能 - 有線・無線クライアントのリスト表示・フィルタリング、MACアドレスによる詳細なクライアント検索、クライアント数分析、時間軸での分析、SSIDおよび周波数帯によるフィルタリング、無線トラブルシューティング機能を提供します。MACアドレスやIPアドレスでのクライアント検索、サイト別やSSID別のクライアント数集計、無線周波数帯の分布分析、Wi-Fi信号の問題調査が必要な場合に活用できます。
ci-cd-and-automation
CI/CDパイプラインの設定を自動化します。ビルドおよびデプロイメントパイプラインの構築または変更時に使用できます。品質ゲートの自動化、CI内のテストランナー設定、またはデプロイメント戦略の確立が必要な場合に活用します。
shipping-and-launch
本番環境へのリリース準備を行います。本番環境へのデプロイ準備が必要な場合、リリース前チェックリストが必要な場合、監視機能の設定を行う場合、段階的なロールアウトを計画する場合、またはロールバック戦略が必要な場合に使用します。
linear-release-setup
Linear Releaseに向けたCI/CD設定を生成します。リリース追跡の設定、LinearのCIパイプライン構築、またはLinearリリースとのデプロイメント連携を実施する際に利用できます。GitHub Actions、GitLab CI、CircleCIなど複数のプラットフォームに対応しています。
tracking-application-response-times
API エンドポイント、データベースクエリ、サービスコール全体にわたるアプリケーションのレスポンスタイムを追跡・最適化できます。パフォーマンス監視やボトルネック特定の際に活用してください。「レスポンスタイムを追跡する」「API パフォーマンスを監視する」「遅延を分析する」といった表現で呼び出せます。