Promoción de Devnet a Mainnet
Promocionar un programa y dApp de Solana de devnet a mainnet-beta es un proceso de compuertas escalonadas: cada clúster tiene diferentes economías, material de claves y riesgos. Omitir una etapa introduce sorpresas a escala.
Receta
Tarjeta de receta de referencia rápida - lista para copiar y pegar.
anchor build --verifiable
anchor test
solana program deploy --url devnet target/deploy/my_program.so
# Después de la lista de verificación: desplegar el mismo hash .so en mainnet a través de multisigCuándo usar esto:
- Primer despliegue en mainnet después de completar funciones en devnet
- Migración de RPC o ID de programa entre entornos
- Revisión de aprobación/rechazo de la semana de lanzamiento
- Solicitudes de auditoría de evidencia de paridad de entorno
- Repromoción de compilación parcheada post-incidente
Ejemplo de Trabajo
#!/usr/bin/env bash
set -euo pipefail
PROGRAM_SO="target/deploy/vault.so"
DEVNET_HASH=$(solana-verify get-executable-hash "$PROGRAM_SO")
anchor deploy --provider.cluster devnet
echo "Prueba de humo en Devnet..."
pnpm run smoke:devnet
echo "Hash para promoción a mainnet: $DEVNET_HASH"
# La propuesta de Squads adjunta este hashLo que esto demuestra:
- Hash de compilación verificable registrado antes de mainnet
- Despliegue en devnet y prueba de humo como compuerta dura
- El mismo artefacto promocionado - no se recompila en una máquina diferente
- La propuesta multisig hace referencia al hash ejecutable
Análisis Profundo
Etapas de Promoción
| Etapa | Clúster | Propósito |
|---|---|---|
| 1 | Surfpool / localnet | CI rápida, reproducción de exploits |
| 2 | Devnet | Integración, pruebas de airdrop |
| 3 | Mainnet-beta | Economías y tarifas reales |
Paridad de Entorno
- Estrategia de ID de programa: nuevo par de claves por entorno o el mismo ID con ruta de actualización documentada en ADR
- Archivos
.env:RPC_URL,PROGRAM_ID,CLUSTERnunca se copian ciegamente entre entornos - Pares de claves de billetera: archivos separados; claves de mainnet solo en HSM o Squads
Trampas
- Recompilar en una máquina diferente - El bytecode difiere; el hash de auditoría no es válido. Solución: Promoción de artefactos de CI.
- Dependencia del airdrop de Devnet - Mainnet necesita un plan de financiación real con SOL. Solución: Presupuestar el pagador de tarifas y las billeteras de despliegue.
- Misma clave de administrador en devnet y mainnet - La clave de devnet filtrada agota mainnet. Solución: Jerarquía de claves distinta.
- Omitir prueba de carga - Devnet vacío; las tarifas de mainnet se disparan. Solución: Pruebas de tarifas prioritarias antes del lanzamiento.
- Frontend todavía apunta a devnet - Los usuarios firman el clúster incorrecto. Solución: Validación de entorno en tiempo de compilación.
Alternativas
| Alternativa | Usar cuando | No usar cuando |
|---|---|---|
| Despliegue sombra en Mainnet | Canary de solo lectura | Primer despliegue |
| Salto inmutable de devnet | Demostración desechable pequeña | Cualquier fondo de usuario |
| Mainnet con feature-flag | Exposición gradual al usuario | Lógica central sin probar |
Preguntas Frecuentes
¿Cuánto tiempo en devnet antes de mainnet?
Mínimo un sprint completo con pruebas de integración; protocolos de alto riesgo añaden auditoría externa.
¿Mismo ID de programa en todos los clústeres?
Generalmente IDs diferentes por entorno; documentar el mapeo en ADR.
¿Quién aprueba mainnet?
Líder técnico + seguridad + producto; firmantes multisig para el despliegue.
¿Qué pruebas de humo se ejecutan?
Los flujos de usuario principales se simulan y envían en devnet con la billetera de CI.
¿Inestabilidad de Devnet?
Usar Surfpool 0.12.0 para CI; devnet para QA manual cuando sea necesario.
¿Cómo financiar el despliegue de mainnet?
Billetera de operaciones prefinanciada; alerta por debajo del umbral.
¿IDL en mainnet?
Publicar el mismo hash de IDL que la versión de compilación verificable.
¿Plan de reversión?
Requerido en el ticket de promoción - enlazar runbook.
¿Momento del lanzamiento comunitario?
Coordinar despliegue, frontend y comunicaciones en una ventana de cambio.
¿Coincidencia de versión de Agave?
Validador y CLI alineados a 4.1.1 según manifiesto.
Relacionado
- Estrategia de Actualización de Programas - buffers y autoridad
- Mejores Prácticas de Entrega - compuertas de lanzamiento
- Depuración de Transacciones Fallidas - triaje post-promoción
Versiones de Stack: Esta página fue escrita para Agave 4.1.1, Solana CLI 3.0.10, Anchor 0.32.1, anchor-lang 0.32.1, Rust 1.91.1, @solana/kit 7.0.0, Surfpool 0.12.0, y LiteSVM 0.6.x.