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.

Install

Hot:5

Download and extract to your skills directory

Copy command and send to AI Agent for auto-install:

Download and install this skill https://openskills.cc/api/download?slug=addyosmani-skills-shipping-and-launch&locale=en&source=copy

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

  • 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.

  • 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.

  • 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.