Files
2025-11-30 08:58:05 +08:00

352 lines
8.7 KiB
Markdown

# Release Strategies Reference
This document provides detailed guidance on different release strategies and deployment targets.
## npm Package Release
**Best for**: JavaScript/TypeScript libraries, CLI tools, frameworks
**Prerequisites**:
- npm account and NPM_TOKEN secret configured
- `package.json` with correct metadata (name, version, main, types)
- Build output in publishable state
**Workflow steps**:
1. Build the package
2. Run `npm publish`
3. Create GitHub Release with version tag
4. Include link to npm package in release notes
**Configuration**:
```json
{
"name": "@username/package-name",
"version": "1.0.0",
"main": "dist/index.js",
"types": "dist/index.d.ts",
"files": ["dist"],
"scripts": {
"build": "tsc",
"prepublishOnly": "npm run build"
}
}
```
**GitHub Release notes example**:
```
📦 Published to npm: https://www.npmjs.com/package/@username/package-name
Install with:
npm install @username/package-name
```
## GitHub Pages Deployment
**Best for**: Static websites, documentation sites, SPAs
**Prerequisites**:
- GitHub Pages enabled in repository settings
- Build outputs static files to a directory (usually `dist/` or `build/`)
**Workflow steps**:
1. Build the static site
2. Deploy to `gh-pages` branch using `peaceiris/actions-gh-pages`
3. Create GitHub Release with link to live site
**Configuration considerations**:
- Set correct `base` path for SPAs (e.g., Vite: `base: '/repo-name/'`)
- Configure 404.html for SPA routing
- Custom domain setup (optional)
**GitHub Release notes example**:
```
🌐 Deployed to: https://username.github.io/repo-name
Changes in this release:
[auto-generated release notes]
```
## Vercel Deployment
**Best for**: Next.js apps, React apps, modern web frameworks
**Prerequisites**:
- Vercel account connected to GitHub
- Vercel project configured (can be done via CLI or UI)
**Workflow approaches**:
### Option 1: Automatic (Recommended)
- Let Vercel handle deployment via their GitHub integration
- GitHub Actions only handles validation
- Every push to main triggers Vercel deployment automatically
### Option 2: Manual via GitHub Actions
- Use Vercel CLI in GitHub Actions
- Requires VERCEL_TOKEN secret
- More control but more complex
**GitHub Release notes example**:
```
🚀 Deployed to Vercel: https://project-name.vercel.app
Production URL: https://your-domain.com (if custom domain)
```
## Docker Container Release
**Best for**: Microservices, backend applications, full-stack apps
**Prerequisites**:
- Dockerfile in repository
- Multi-stage builds for optimization (recommended)
**Release targets**:
- **GitHub Container Registry** (ghcr.io) - Recommended, free with GitHub
- **Docker Hub** - Public registry, widely used
- **AWS ECR**, **Google GCR**, **Azure ACR** - Cloud-specific registries
**Workflow steps**:
1. Build Docker image with version tag
2. Push to container registry
3. Also tag as `latest`
4. Create GitHub Release with pull command
**Best practices**:
- Use multi-stage builds to minimize image size
- Run containers as non-root user
- Include health check in Dockerfile
- Version images with semantic versioning
**GitHub Release notes example**:
```
🐳 Docker image: `ghcr.io/username/repo-name:v1.2.3`
Pull and run:
docker pull ghcr.io/username/repo-name:v1.2.3
docker run -p 8080:8080 ghcr.io/username/repo-name:v1.2.3
```
## Binary Artifacts Release
**Best for**: CLI tools, desktop apps, native applications
**Platforms to support**:
- Linux (x86_64, arm64)
- macOS (x86_64, arm64/Apple Silicon)
- Windows (x86_64)
**Workflow approaches**:
### Option 1: GitHub Actions matrix build
Build on multiple runners (ubuntu, macos, windows) and upload artifacts
### Option 2: Cross-compilation
Compile for multiple targets from single runner (works for Go, Rust)
### Option 3: GoReleaser / cargo-dist
Use specialized tools for automated multi-platform releases
**GitHub Release notes example**:
```
📥 Download the binary for your platform:
- Linux x86_64: [app-linux-amd64](link)
- Linux ARM64: [app-linux-arm64](link)
- macOS x86_64: [app-darwin-amd64](link)
- macOS ARM64: [app-darwin-arm64](link)
- Windows x86_64: [app-windows-amd64.exe](link)
Quick install:
curl -L https://github.com/user/repo/releases/download/v1.2.3/app-linux-amd64 -o app
chmod +x app
./app
```
## Python Package (PyPI) Release
**Best for**: Python libraries, CLI tools, frameworks
**Prerequisites**:
- PyPI account and API token
- `pyproject.toml` or `setup.py` with metadata
- Build tool (build, setuptools, poetry)
**Workflow steps**:
1. Build distribution packages (wheel + sdist)
2. Upload to PyPI using twine
3. Create GitHub Release with PyPI link
**Configuration**:
```toml
[build-system]
requires = ["setuptools>=45", "wheel"]
build-backend = "setuptools.build_meta"
[project]
name = "my-package"
version = "1.0.0"
description = "Package description"
authors = [{name = "Your Name", email = "you@example.com"}]
```
**GitHub Release notes example**:
```
📦 Published to PyPI: https://pypi.org/project/my-package/
Install with:
pip install my-package
```
## Rust Crate (crates.io) Release
**Best for**: Rust libraries
**Prerequisites**:
- crates.io account
- CARGO_REGISTRY_TOKEN secret
- `Cargo.toml` with complete metadata
**Workflow steps**:
1. Run tests and validation
2. Publish to crates.io using `cargo publish`
3. Create GitHub Release
**GitHub Release notes example**:
```
📦 Published to crates.io: https://crates.io/crates/my-crate
Add to your Cargo.toml:
[dependencies]
my-crate = "1.0.0"
```
## Claude Code Skill Release
**Best for**: Claude Code skills and extensions
**Prerequisites**:
- Skill properly structured and validated
- Skill packaged as .skill file
**Workflow steps**:
1. Validate skill structure
2. Package skill into .skill file
3. Create GitHub Release with .skill file attached
4. No deployment needed
**GitHub Release notes example**:
```
🎯 Claude Code Skill Release
Download the skill file and install in Claude Code:
1. Download [skill-name.skill](link)
2. In Claude Code, run: /skills install /path/to/skill-name.skill
What's included:
- [Brief description of skill capabilities]
```
## Desktop App Distribution
**Best for**: Electron apps, Tauri apps
**Platforms**: Windows, macOS, Linux
**Workflow tools**:
- **Electron Builder**: Automated builds and updates
- **Tauri**: Rust-based alternative with smaller bundle sizes
**Distribution methods**:
- GitHub Releases with auto-updater
- Platform-specific stores (Microsoft Store, Mac App Store)
- Custom update server
## Platform-as-a-Service (PaaS) Deployment
**Platforms**: Railway, Fly.io, Render, Heroku (legacy)
**Common characteristics**:
- Git-based deployment
- Automatic container building
- Built-in databases and add-ons
- Easy environment variable management
**Workflow integration**:
Most PaaS platforms integrate directly with GitHub - just validation in GitHub Actions, deployment handled by platform
## Release Strategy Selection Guide
### Choose npm/PyPI/crates.io when:
- Building a library or package
- Want maximum distribution reach
- Package manager installation is preferred
### Choose GitHub Pages when:
- Pure static site
- Documentation site
- No server-side logic needed
- Want simple, free hosting
### Choose Vercel/Netlify when:
- Modern framework (Next.js, SvelteKit, etc.)
- Need serverless functions
- Want preview deployments for PRs
- Need automatic optimizations
### Choose Docker when:
- Microservices architecture
- Need consistent runtime environment
- Deploying to Kubernetes or container orchestration
- Complex dependencies
### Choose Binary release when:
- CLI tool
- Desktop application
- Want users to run without installing runtime
- Performance-critical application
### Choose PaaS when:
- Full-stack web application
- Need managed database
- Want simple deployment
- Solo developer or small team
## Multi-Release Strategy
Some projects benefit from multiple release targets:
**Example: CLI tool**
- npm package (for Node.js users)
- Standalone binary (for system installation)
- Docker image (for containerized environments)
**Example: Web framework**
- npm package (for developers)
- Documentation site on GitHub Pages
- Example deployed to Vercel
**Example: Library**
- Language package registry (npm, PyPI, etc.)
- GitHub Releases for changelogs
- Documentation site
## Versioning and Changelog Best Practices
**Semantic Versioning**:
- MAJOR: Breaking changes
- MINOR: New features (backward compatible)
- PATCH: Bug fixes
**Auto-versioning**:
Use commit messages or PR labels to determine version bump:
- `feat:` → MINOR bump
- `fix:` → PATCH bump
- `BREAKING CHANGE:` → MAJOR bump
**Changelog generation**:
- Auto-generate from commit messages (Conventional Commits)
- Auto-generate from PR titles
- Use GitHub's release notes generation
- Tools: semantic-release, conventional-changelog