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,.nvmrcconfirmados. - 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-verifypublicado. - 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
¿Tamaño mínimo del equipo?
Las prácticas se escalan hacia abajo: mantén las secciones de seguridad y fijación de versiones incluso para 3 ingenieros.
¿Equipos remotos/asíncronos?
Listas de verificación escritas y demostración grabada del proyecto final del Primer Programa reemplazan el emparejamiento informal.
¿Agencia + equipo cliente?
Prácticas divididas: la agencia es propietaria de la documentación de la cadena de herramientas, el cliente es propietario de las claves y la aprobación de mainnet.
¿Frecuencia de auditoría?
Lanzamiento importante o cambio material de CPI, no cada corrección de error tipográfico.
¿Tiempo para deuda técnica?
Asignar un porcentaje fijo del sprint para actualizaciones de dependencias y optimizaciones de CU.
¿Presión del producto?
Ticket explícito de aceptación de riesgo al omitir el período de prueba o la recomendación de auditoría.
¿Múltiples programas?
Propietarios por programa listados en CODEOWNERS con ruta de escalada.
¿Alineación con el equipo de datos?
Compartir esquemas de IDL/eventos cuando los indexadores consumen tus programas.
¿Código abierto?
Las prácticas de seguridad aún se aplican: redactar claves en plantillas de problemas públicos.
¿Métricas?
Rastrear la frecuencia de despliegue, la tasa de tx fallidas, el tiempo medio de revisión; adaptar de DORA según sea necesario.
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.