Skillsshipping-and-launch
S

shipping-and-launch

Prepares production launches. Use when preparing to deploy to production. Use when you need a pre-launch checklist, when setting up monitoring, when planning a staged rollout, or when you need a rollback strategy.

Shipping and Launch - Production Release Safety Guide

Skill Overview

Shipping and Launch provides a comprehensive production release readiness framework that helps teams achieve reversible, observable, and incremental deployments through pre-release checklists, feature flag strategies, and phased rollout processes.

Applicable Scenarios

  1. First Production Deployment
    When you are preparing to deploy a new feature or application to production for the first time, use this skill to ensure that all security, performance, and monitoring checks have been completed, avoiding production incidents caused by inadequate preparation.

  2. Major Change Releases
    For releases involving architectural changes, data migrations, or changes to core business logic, reduce risk and preserve rapid rollback capabilities through phased rollouts and feature flag strategies.

  3. High-Traffic Application Releases
    Releases targeting a large number of users require precise risk control and a comprehensive monitoring system. Use canary releases and incremental rollout strategies to ensure that issues are detected and resolved while they affect only a small group of users.

Core Features

Pre-Release Checklist

Provides comprehensive checks across six major categories: code quality, security, performance, accessibility, infrastructure, and documentation. This ensures that pre-release testing, builds, security audits, performance optimization, and documentation updates are all complete. The checklist covers all critical items, from unit tests to security configuration.

Feature Flag Strategy

Use feature flags to decouple deployment from release, enabling a safe “deploy first, release later” model. Supports phased enablement (internal team testing → 5% → 25% → 50% → 100%), with clearly defined monitoring windows and decision thresholds for each stage to ensure that issues are detected before their impact expands.

Monitoring and Rollback Mechanisms

Defines the application metrics to monitor (error rate, response time, and business metrics), infrastructure metrics (CPU, memory, and database), and client-side metrics (Core Web Vitals). Provides a clear rollback decision matrix. A rollback is automatically triggered when the error rate exceeds twice the baseline or latency increases by more than 50%, ensuring rapid recovery.

Frequently Asked Questions

What must be checked before a production release?

All six major categories must be completed: code quality (all tests passing, builds with no warnings, and code review approval), security (no leaked secrets, no high-severity vulnerabilities in npm audit, and correct authentication and authorization), performance (passing Core Web Vitals, no N+1 queries, and optimized resources), accessibility (keyboard navigation, screen reader support, and color contrast), infrastructure (environment variable configuration, DNS/SSL, CDN, and logging and monitoring), and documentation updates.

When should a release be rolled back immediately?

Roll back immediately when the error rate exceeds twice the baseline, P95 latency increases by more than 50%, user-reported issues surge, data integrity problems are discovered, or a security vulnerability is found. Releases using feature flags can be rolled back within one minute by disabling the flag; code releases can be rolled back within five minutes by running git revert and rapidly deploying the previous version.

How do feature flags help reduce release risk?

Feature flags allow code to be deployed to production while remaining disabled, decoupling deployment from release. You can then enable the feature for internal teams first for production testing, followed by a gradual expansion of the user base through canary releases (5% → 25% → 50% → 100%). Each stage has a 24–48-hour monitoring window. If metrics become abnormal, you can revert to the previous stage or disable the feature completely at any time, avoiding impact on all users.