Estrategias de despliegue y reversión
Despliegue blue-green de prompts, indicadores de funcionalidades y reversión ante regresiones.
Estrategias de despliegue y reversión es una lección gratuita de AI Prompt Engineering en CoddyKit. Esta es la lección 3 de 4. Puedes leer la lección completa abajo gratuitamente — luego la practicas en el navegador con un editor de código integrado y un tutor de IA 24/7. Forma parte de la ruta de aprendizaje de AI Prompt Engineering, y tu progreso se sincroniza en la web y la app de CoddyKit. El curso de AI Prompt Engineering incluye 4 lecciones en total.
Desafíos de implementar prompts
Implementar una nueva versión de un prompt en producción conlleva un riesgo real: un cambio que mejora la calidad media puede perjudicar casos límite, provocar picos de latencia o confundir a los usuarios. Las estrategias de implementación controlada gestionan este riesgo al limitar el alcance del impacto y permitir un rollback rápido.
Implementación blue-green de prompts
La implementación blue-green mantiene dos entornos: blue (producción actual) y green (nueva versión). El tráfico se cambia atómicamente de blue a green después de la validación. Si green falla, el cambio se revierte al instante.
- Cambios sin tiempo de inactividad
- Ambas versiones permanecen listas simultáneamente
- El rollback consiste en un único cambio de configuración, no en una nueva implementación
# prompt_router.py — blue/green traffic control
class PromptRouter:
def __init__(self):
self.slots = {
'blue': None, # {'prompt_id': ..., 'version': ...}
'green': None,
}
self.active_slot = 'blue'
def load_slot(self, slot, prompt_id, version, template):
self.slots[slot] = {
'prompt_id': prompt_id,
'version': version,
'template': template
}
print(f'Loaded {prompt_id}@{version} into {slot} slot')
def switch_to(self, slot):
if not self.slots[slot]:
raise ValueError(f'Slot {slot} is empty')
self.active_slot = slot
info = self.slots[slot]
print(f'Traffic now routed to {slot}: {info["prompt_id"]}@{info["version"]}')
def get_active_template(self):
return self.slots[self.active_slot]['template']División del tráfico para un despliegue gradual
En lugar de cambiar el 100 % del tráfico de una vez, aumente gradualmente la proporción que se envía a la nueva versión. Una progresión habitual es: 1 % → 5 % → 10 % → 25 % → 50 % → 100 %, con supervisión de la calidad en cada paso.
import random
class TrafficSplitter:
def __init__(self):
# version_weights: {version_id: percentage}
self.version_weights = {
'v1.1.0': 90,
'v1.2.0': 10
}
def select_version(self):
versions = list(self.version_weights.keys())
weights = list(self.version_weights.values())
return random.choices(versions, weights=weights, k=1)[0]
def update_split(self, new_weights):
assert sum(new_weights.values()) == 100, 'Weights must sum to 100'
self.version_weights = new_weights
print(f'Traffic split updated: {new_weights}')
# Usage
splitter = TrafficSplitter()
for _ in range(5):
print(splitter.select_version())
# Ramp to 25%
splitter.update_split({'v1.1.0': 75, 'v1.2.0': 25})Feature flags para el despliegue de prompts
Las feature flags permiten habilitar una nueva versión de un prompt para usuarios o segmentos específicos (usuarios beta, personal interno) antes del despliegue completo. Esto combina la seguridad de un despliegue gradual con pruebas específicas en casos de uso reales.
# Feature flag-based prompt selection
BETA_USER_IDS = {'user_123', 'user_456', 'user_789'}
def select_prompt_version(user_id, prompt_id, registry):
# Check if user is in beta cohort
if user_id in BETA_USER_IDS:
# Try to get a beta version tagged for this prompt
beta = registry.get_version_by_tag(prompt_id, tag='beta')
if beta:
return beta
# Default: serve active (stable) version
return registry.get_active(prompt_id)
# Example: LaunchDarkly-style flag check
def select_prompt_ld(user_id, ld_client, registry):
use_new = ld_client.variation(
'use-summarize-v2', {'key': user_id}, default=False
)
version = 'v2.0.0' if use_new else 'v1.1.0'
return registry.get_version(prompt_id='summarize-article', version=version)Supervisión de la calidad de la nueva versión
Después de dirigir el tráfico a una nueva versión, supervise estas señales en tiempo real:
- Tasa de errores: errores de API, salidas con formato incorrecto y fallos de análisis
- Latencia: tiempo de respuesta P95 (los prompts nuevos pueden ser más largos y lentos)
- Puntuación de calidad: puntuación de evaluación automatizada de un evaluador basado en LLM o de una métrica
- Señales de los usuarios: tasa de votos negativos, tasa de reintentos y abandono de sesiones
from collections import defaultdict
import time
class VersionMonitor:
def __init__(self):
self.metrics = defaultdict(lambda: {
'calls': 0, 'errors': 0,
'latency_sum': 0, 'quality_sum': 0
})
def record(self, version, latency_ms, quality_score, error=False):
m = self.metrics[version]
m['calls'] += 1
m['latency_sum'] += latency_ms
m['quality_sum'] += quality_score
if error:
m['errors'] += 1
def report(self, version):
m = self.metrics[version]
n = m['calls'] or 1
return {
'version': version,
'calls': m['calls'],
'error_rate': round(m['errors'] / n, 3),
'avg_latency_ms': round(m['latency_sum'] / n),
'avg_quality': round(m['quality_sum'] / n, 2)
}Rollback automático ante una regresión de calidad
El rollback manual es demasiado lento para los incidentes de producción. Defina disparadores de rollback: umbrales que reviertan automáticamente a la versión anterior cuando se incumplan.
ROLLBACK_THRESHOLDS = {
'error_rate': 0.05, # > 5% errors trigger rollback
'avg_latency_ms': 10000, # > 10s avg latency triggers rollback
'avg_quality': 3.5 # < 3.5 quality score triggers rollback
}
def check_and_rollback(monitor, registry, version, previous_version):
report = monitor.report(version)
triggers = []
if report['error_rate'] > ROLLBACK_THRESHOLDS['error_rate']:
triggers.append(f'error_rate={report["error_rate"]}')
if report['avg_latency_ms'] > ROLLBACK_THRESHOLDS['avg_latency_ms']:
triggers.append(f'latency={report["avg_latency_ms"]}ms')
if report['avg_quality'] < ROLLBACK_THRESHOLDS['avg_quality']:
triggers.append(f'quality={report["avg_quality"]}')
if triggers:
print(f'ROLLBACK TRIGGERED: {triggers}')
registry.activate_version('summarize-article', previous_version)
alert_oncall(f'Prompt auto-rolled back to {previous_version}: {triggers}')
return True
return FalsePatrón de implementación canary
Un canary es una pequeña fracción del tráfico (1-5 %) que recibe primero la nueva versión del prompt. Si el canary se mantiene estable tras un período de observación, el tráfico se desplaza gradualmente. Si no, solo se ven afectados los usuarios del canary.
import time
def canary_deploy(registry, splitter, monitor, new_version, prev_version,
soak_minutes=30, stages=[1, 5, 25, 50, 100]):
for pct in stages:
splitter.update_split({
prev_version: 100 - pct,
new_version: pct
})
print(f'Stage: {pct}% canary. Soaking for {soak_minutes} min...')
time.sleep(soak_minutes * 60) # wait soak period
should_rollback = check_and_rollback(
monitor, registry, new_version, prev_version
)
if should_rollback:
splitter.update_split({prev_version: 100})
print('Canary aborted. Fully reverted to', prev_version)
return False
print(f'Stage {pct}% passed quality check.')
print(f'Canary complete. {new_version} now at 100%.')
return TrueOrquestación del pipeline de implementación
Un pipeline completo de implementación de prompts integra la validación, el inicio del canary, el ciclo de supervisión y la promoción final o el rollback, todo automatizado y con puntos de aprobación humana en las etapas clave.
# deploy_prompt.py — full pipeline
import argparse
def deploy(prompt_id, new_version, prev_version, dry_run=False):
print(f'=== Deploying {prompt_id}: {prev_version} -> {new_version} ===')
# 1. Validate new version exists in registry
artifact = registry.get_version(prompt_id, new_version)
print(f'Found artifact: {artifact["version"]}')
# 2. Run offline eval suite
score = run_eval_suite(artifact['template'])
if score < 0.90:
raise RuntimeError(f'Eval score {score} below threshold 0.90')
print(f'Eval passed: {score}')
if dry_run:
print('Dry run complete. Not deploying.')
return
# 3. Canary deploy with automatic rollback
success = canary_deploy(
registry, splitter, monitor,
new_version, prev_version,
soak_minutes=15, stages=[1, 5, 25, 100]
)
print('Deployment', 'SUCCEEDED' if success else 'FAILED')
if __name__ == '__main__':
parser = argparse.ArgumentParser()
parser.add_argument('--new', required=True)
parser.add_argument('--prev', required=True)
parser.add_argument('--dry-run', action='store_true')
args = parser.parse_args()
deploy('summarize-article', args.new, args.prev, args.dry_run)Procedimiento de rollback manual
Cuando el rollback automático no se activa, pero una persona detecta problemas de calidad, un runbook de rollback manual garantiza una actuación rápida y coherente.
# RUNBOOK: Manual Prompt Rollback
# Estimated time to execute: 2-3 minutes
# Step 1: Identify current and target versions
python manage.py prompt list-versions --prompt-id summarize-article
# Output:
# v1.2.0 [ACTIVE] 2024-08-15 alice
# v1.1.0 [stable] 2024-07-01 alice
# Step 2: Activate previous stable version
python manage.py prompt activate --prompt-id summarize-article --version v1.1.0
# Output: Activated summarize-article@v1.1.0
# Step 3: Verify traffic is serving old version
python manage.py prompt verify --prompt-id summarize-article
# Output: Active version: v1.1.0 Serving: 100%
# Step 4: Log the incident
python manage.py incident create \
--title 'Prompt rollback: summarize-article v1.2.0 -> v1.1.0' \
--severity P2 \
--reason 'Quality score dropped from 4.1 to 3.2 after v1.2.0 deploy'Configuración de la implementación como código
Defina la configuración de la implementación en archivos bajo control de versiones para que todas las decisiones de implementación sean auditables y reproducibles.
# deployments/summarize-article.yaml
prompt_id: summarize-article
current_stable: '1.1.0'
canary_config:
stages: [1, 5, 25, 50, 100]
soak_minutes_per_stage: 15
rollback_thresholds:
error_rate_max: 0.05
latency_p95_max_ms: 8000
quality_score_min: 3.5
feature_flags:
beta_group: [user_123, user_456]
alerts:
pagerduty_key: 'PD_KEY_PLACEHOLDER'
slack_channel: '#prompt-alerts'
# Load and apply with a deploy script
import yaml
with open('deployments/summarize-article.yaml') as f:
config = yaml.safe_load(f)
print('Deploying with config:', config['canary_config'])Runbooks de guardia y análisis post mortem
Después de cualquier rollback o incidente, redacte un post-mortem que documente: qué ocurrió, la causa raíz, la cronología y las acciones pendientes. Los runbooks deben hacer referencia al post-mortem y actualizarse con las lecciones aprendidas.
# Post-mortem template (stored in docs/post-mortems/)
## Incident: summarize-article v1.2.0 quality regression
## Date: 2024-08-15
## Severity: P2
## Duration: 47 minutes (09:15 - 10:02 UTC)
### What happened
Deployed v1.2.0 of summarize-article. At 5% canary, quality score dropped
from 4.1 to 3.0 for articles over 2000 words.
### Root cause
New prompt template removed the explicit length constraint instruction.
Long articles caused the model to generate overly verbose summaries.
### Timeline
09:15 v1.2.0 deployed to 5% canary
09:28 Quality monitor detected avg_quality < 3.5
09:29 Auto-rollback triggered to v1.1.0
09:32 Incident acknowledged by on-call
10:02 Post-mortem drafted
### Action items
- [ ] Add length regression test to eval suite
- [ ] Update canary monitoring to separate metrics by article length
- [ ] Add changelog requirement: 'length behavior' fieldComprobación rápida
En un despliegue de prompts blue-green, ¿qué ocurre cuando el slot green no supera las comprobaciones de calidad?
Resumen de estrategias de despliegue
El despliegue de prompts en producción requiere estrategias estructuradas para gestionar el riesgo:
- Blue-green: dos entornos activos, cambio atómico instantáneo
- Canary: aumento gradual del tráfico del 1 % → 5 % → 25 % → 100 %, con comprobaciones de calidad en cada etapa
- Feature flags: dirigir primero la implementación a usuarios beta antes del despliegue general
- Rollback automático: reversión activada por umbrales (tasa de errores, latencia, calidad)
- Runbooks: procedimientos documentados de rollback manual para ingenieros de guardia
- Post-mortems: mejora continua después de cada incidente
Preguntas frecuentes
¿La lección «Estrategias de despliegue y reversión» es gratis?
Sí — el texto completo de «Estrategias de despliegue y reversión» es gratis para leer aquí en la web. Para practicarla de forma interactiva (editor de código integrado y tutor de IA 24/7) y desbloquear el resto del curso de AI Prompt Engineering, actualiza a CoddyKit PRO. El curso de AI Prompt Engineering incluye 4 lecciones en total.
¿Qué aprenderé en «Estrategias de despliegue y reversión»?
Despliegue blue-green de prompts, indicadores de funcionalidades y reversión ante regresiones. Practicas AI Prompt Engineering con código real que ejecutas directamente en el navegador, y un tutor de IA 24/7 responde tus preguntas mientras trabajas en la lección.
¿Necesito experiencia previa para empezar AI Prompt Engineering?
No se requiere experiencia previa. AI Prompt Engineering en CoddyKit está estructurado para principiantes hasta estudiantes avanzados, así que puedes empezar aquí o desde el inicio y avanzar a tu ritmo. Esta es la lección 3 de 4.
¿Cuánto tiempo toma la lección «Estrategias de despliegue y reversión»?
La mayoría de las lecciones de CoddyKit toman alrededor de 5–10 minutos. Cada una es compacta e interactiva, así que avanzas constantemente y retomas exactamente por donde dejaste en la web y la app.
¿Puedo escribir y ejecutar código en esta lección de AI Prompt Engineering?
Sí. Cada lección de AI Prompt Engineering incluye un editor de código integrado, así que escribes y ejecutas código real directamente en tu navegador y obtienes retroalimentación instantánea de IA — sin configuración local necesaria.
Todas las lecciones de este curso
- Arquitectura de un registro de prompts
- Control de versiones para prompts
- Estrategias de despliegue y reversión
- Monitorización del rendimiento de prompts en producción