Flujo de trabajo: Localnet vs. Devnet
Un flujo de trabajo paso a paso para elegir entre localnet (solana-test-validator), devnet, Surfpool o mainnet para una tarea de desarrollo determinada.
//
Busca en todas las páginas de la documentación
Un flujo de trabajo paso a paso para elegir entre localnet (solana-test-validator), devnet, Surfpool o mainnet para una tarea de desarrollo determinada.
provider de Anchor.toml.Si la respuesta es sí - reservas de pool activas, precios de oráculos o versiones de programas de producción - ve al Paso 2. Si la respuesta es no - tú controlas todas las cuentas y programas - ve al Paso 5.
--clone?Si la respuesta es sí - clona pubkeys específicos en solana-test-validator - usa localnet con clones (Clonación de Cuentas de Mainnet).
Si la respuesta es no - se necesita un gráfico DeFi amplio o una actualización frecuente del estado - ve al Paso 3.
Si la respuesta es sí - usa Surfpool 0.12.0 para bucles de simulación de fork de mainnet (Surfpool). Si la respuesta es no - ve al Paso 4.
Si la respuesta es sí - usa devnet con programas públicos y financiación de faucet. Si la respuesta es no - regresa al Paso 2 y expande la lista de clones o adopta Surfpool.
Si la respuesta es sí - usa localnet con anchor test y fixtures (Carga de Programas y Fixtures).
Si la respuesta es no - demostraciones de billetera del cliente o uso compartido entre varios equipos - ve al Paso 6.
Si la respuesta es sí - devnet despliega con el ID de programa documentado en README. Si la respuesta es no - cada ingeniero usa el despliegue de localnet con IDs locales o archivos de clave sincronizados.
Si la respuesta es sí - localnet en GitHub Actions con --reset y fixtures confirmados - evita los límites de tasa de devnet.
Si la respuesta es no - un trabajo de humo opcional en devnet cada noche es aceptable.
Si la respuesta es sí - devnet es una señal débil; usa devnet + tarifas de prioridad para verificaciones básicas, luego pequeñas sondas en mainnet con SOL real (Configuración de Tarifas de Prioridad). Si la respuesta es no - quédate en localnet/devnet de los pasos anteriores.
Si la respuesta es sí - devnet con URL RPC estable y billetera de demostración financiada.
Si la respuesta es no - localnet funciona con adaptadores de billetera apuntando a localhost:8899.
Si la respuesta es sí - detente - usa mainnet con cantidades mínimas y solo confirmación finalizada. Si la respuesta es no - nunca uses mainnet para esta tarea; regresa al camino localnet/devnet elegido.
Registra la URL del clúster, los IDs de programa, las versiones de fixtures y los pines de la cadena de herramientas (Agave 4.1.1) en el PR para reproducibilidad.
Los límites de tasa, el estado inestable compartido y la iteración más lenta perjudican el desarrollo diario de programas; localnet es más rápido y determinista.
Carece de efectos de red en vivo, validadores peer y congestión realista; las sondas en devnet/mainnet aún importan antes del lanzamiento.
Debajo de este flujo de trabajo para pruebas unitarias de Rust; no se requiere clúster RPC (LiteSVM).
Sí - empieza local, gradúa a devnet para demostraciones de billetera, luego sondas en mainnet - actualiza solana config y las variables de entorno cada vez.
http://127.0.0.1:8899 con RPC personalizado de la billetera - no todas las billeteras admiten localhost limpiamente; devnet puede ser más fácil para demostraciones.
Versiones de la pila: 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.
Revisado por Chris St. John·Última actualización: 16 jul 2026