Mejores Prácticas de Equipo

Prácticas compartidas que mantienen a un equipo de ingeniería de Solana rápido y seguro en validadores Agave 4.1.1, programas Anchor 0.32.1 y clientes @solana/kit 7.0.0.

Cómo Usar Esta Lista

• Adóptala en el acuerdo de trabajo del equipo durante la semana 2 de incorporación.
• Revísala trimestralmente o después de cualquier incidente en mainnet.
• Asigna un propietario a cada regla (plataforma, seguridad, frontend).

A - Cadena de Herramientas y Repositorios

• Única fuente de verdad para las versiones fijadas. rust-toolchain.toml, Anchor.toml, .nvmrc confirmados.
• CI ejecuta anchor build, pruebas y verificación de tipos de cliente en cada PR. Sin verificación manual únicamente.
• IDs de programa y URLs de clúster en tablas de entorno. No cadenas mágicas dispersas.
• Salidas de IDL y Codama versionadas o regeneradas en CI. Los clientes nunca se desvían silenciosamente.
• Documentar los titulares de la autoridad de actualización en el runbook. El personal de guardia sabe quién puede parchear programas.

B - Flujo de Trabajo de Desarrollo

• Por defecto usar devnet y validadores locales para el trabajo de características. Mainnet requiere una lista de verificación explícita.
• Usar LiteSVM 0.6.x para pruebas unitarias rápidas; validadores de humo para integración. Pirámide documentada en README.
• Simular transacciones en clientes antes de enviarlas en staging. Coincidir con las características de RPC de producción.
• Banderas de características para instrucciones riesgosas hasta que sean auditadas. Gobernanza o multisig donde sea necesario.
• PRs pequeños con planes de prueba en la descripción. Los revisores saben que los casos negativos están cubiertos.

C - Seguridad y Claves

• Separar claves y proveedores de RPC de desarrollo, staging y producción. Sin billetera caliente compartida entre entornos.
• Custodia multisig o de hardware para autoridades de actualización en mainnet. Documentar firmantes.
• Carril de revisión de seguridad obligatorio para cambios en el movimiento de tokens. Regla de dos personas.
• Ejecutar la guía de revisión interna antes de la auditoría externa. Corregir P0s obvios primero.
• Runbook de incidentes enlazado desde el repositorio. Plantillas de reversión, pausa y comunicación listas.

D - Comunicación y Documentación

• Cada cambio de programa actualiza el changelog o la nota de migración para el usuario. Las billeteras y los indexadores dependen de ello.
• Registros de Decisiones de Arquitectura para elecciones de framework. Anchor vs Pinocchio, selecciones de proveedor de RPC.
• Rotación de guardia familiarizada con los comandos de operaciones de Solana CLI 3.0.10. Desplegar, volcar logs, verificar compilaciones.
• Nuevos empleados completan listas de verificación de incorporación con firma de un compañero. Rampa repetible.
• Post-mortems sin culpa con seguimientos registrados. Enlazar pruebas de regresión en tickets.

E - Lanzamiento y Operaciones

• Compilaciones verificables para despliegues en mainnet. Hash de solana-verify publicado.
• Período de prueba en Devnet antes de la promoción a Mainnet. Métricas de tiempo de entrega estilo DORA opcionales.
• Monitorear tasas de error de RPC, tasa de aterrizaje de tx y uso de CU del programa. Dashboards por entorno.
• Pruebas de Surfpool 0.12.0 o fork para características dependientes de mainnet. Antes de grandes lanzamientos.
• Estrategia de reversión documentada por programa. Rutas inmutables vs actualizables explícitas.

Preguntas Frecuentes

Relacionado

• Lista de Verificación de Incorporación de Desarrolladores - incorporación de nuevos empleados
• Directrices de Revisión de Código - profundidad de la revisión de PR
• Mejores Prácticas de Equipo en Estándares - normas de contribución
• Conceptos Básicos de Despliegue - operaciones de lanzamiento

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.