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.
Cómo usar este flujo de trabajo
- Comienza en el Paso 1 para cada nueva característica o plan de pruebas.
- Registra el clúster elegido en la descripción de tu PR y en el bloque
providerdeAnchor.toml. - Vuelve a visitarlo cuando el alcance de la integración cambie (por ejemplo, al agregar CPI de mainnet).
- Por defecto, usa localnet para CI; devnet para demostraciones compartidas, a menos que este árbol indique lo contrario.
Paso 1: ¿Necesitas un estado realista de mainnet?
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.
Paso 2: ¿Es suficiente un conjunto pequeño de --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.
Paso 3: ¿Necesitas simulación de fork persistente?
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.
Paso 4: ¿Puedes probar en devnet con contrapartes desplegadas?
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.
Paso 5: ¿El trabajo consiste en pruebas unitarias/de integración solo de programas?
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.
Paso 6: ¿Necesitan los compañeros de equipo el mismo ID de programa desplegado entre sus portátiles?
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.
Paso 7: ¿Es la fiabilidad de CI la principal preocupación?
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.
Paso 8: ¿Estás probando el aterrizaje de transacciones bajo congestión?
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.
Paso 9: ¿Necesitas demostraciones públicas con billeteras (Phantom, etc.)?
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.
Paso 10: ¿Los usuarios gastarán dinero real en esta prueba?
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.
Paso 11: Documenta la decisión
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.
Preguntas Frecuentes
¿Por qué no usar siempre devnet?
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.
¿Por qué no usar siempre localnet?
Carece de efectos de red en vivo, validadores peer y congestión realista; las sondas en devnet/mainnet aún importan antes del lanzamiento.
¿Dónde encaja LiteSVM?
Debajo de este flujo de trabajo para pruebas unitarias de Rust; no se requiere clúster RPC (LiteSVM).
¿Puedo cambiar de clúster a mitad de una característica?
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.
¿Qué URL RPC para Phantom local?
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.
Relacionado
- Conceptos básicos de desarrollo local - introducción al bucle local
- solana-test-validator - cómo usar localnet
- Surfpool - opción de fork
- Proveedores RPC - calidad de RPC en devnet/mainnet
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.