🌐 Overview
Recreate Deployment, also known as “Red/Black Deployment,” involves completely shutting down the current application version before deploying a new one. This straightforward approach represents the simplest deployment strategy but comes with the trade-off of service downtime during the transition period. It follows a “stop-then-start” model where the entire application is replaced in a single operation rather than gradually updated.
🔑 Key Concepts
- Current Version: The existing application version running in production that handles user traffic before deployment begins.
- New Version: The updated application version that will completely replace the current version after deployment.
- Deployment Window: The scheduled period during which the application will be unavailable while transitioning between versions.
🚀 Implementation Steps
- Prepare New Version: Thoroughly develop and test the new version in non-production environments to ensure readiness for deployment.
- Schedule Maintenance Window: Coordinate and communicate a planned downtime period to affected users and stakeholders.
- Shut Down Current Version: Completely stop all instances of the current application version, typically by shutting down servers or scaling deployments to zero.
- Deploy New Version: Install and configure the new application version across the infrastructure.
- Start New Version: Initialize and start all components of the new version to begin handling user traffic.
- Verify Deployment: Conduct post-deployment testing and monitoring to ensure the new version functions correctly.
✅ Advantages
- Simplicity: Straightforward implementation with minimal complexity in deployment scripts and infrastructure.
- Resource Efficiency: Consumes fewer resources as only one version runs at any given time, eliminating the need for parallel environments.
- Complete Replacement: Ensures a clean state with no residual components from previous versions, avoiding compatibility issues.
- Database Consistency: Simplifies database migrations as there’s no need to maintain backward compatibility during deployment.
- Clear State Transition: Provides a definitive cutover point that clearly separates old and new versions.
⚠️ Challenges
- Downtime: Creates a period of unavailability for users during the transition between versions.
- Business Impact: May lead to revenue loss or user dissatisfaction if deployed during high-traffic periods.
- High Risk: Affects the entire application at once, potentially expanding the impact of any deployment issues.
- Limited Rollback Options: Makes reversing a problematic deployment time-consuming, as it requires repeating the entire process.
- All-or-Nothing Approach: Leaves no room for gradual validation of the new version in production.
💼 Example Use Cases
- Internal Enterprise Applications: Systems where scheduled maintenance windows are acceptable and coordinated with users.
- Development and Testing Environments: Non-production deployments where availability is less critical.
- Batch Processing Systems: Applications that run on schedules rather than requiring constant availability.
- Small Startups: Organizations with limited infrastructure resources that cannot support multiple parallel environments.
- Major Version Upgrades: Situations requiring significant architectural changes that cannot coexist with previous versions.
💁🏼♀️ Best Practices
- Deploy During Low-Traffic Periods: Schedule deployments when user activity is minimal to reduce impact.
- Implement Comprehensive Pre-Deployment Testing: Thoroughly test the new version in staging environments to minimize deployment issues.
- Create Automated Deployment Scripts: Develop automation to minimize manual steps and reduce the downtime window.
- Establish Clear Communication Protocols: Notify stakeholders well in advance of planned maintenance windows.
- Prepare Rollback Plan: Document specific steps for reverting to the previous version if deployment issues occur.