Puntos Clave para la Incorporación de Equipos
Contratar o rotar ingenieros en un producto de Solana falla con mayor frecuencia debido a una incorporación desordenada: claves antes que conceptos, clientes antes que cuentas, o mainnet antes que un hábito de revisión de seguridad. Un buen camino es ordenado, con versiones fijadas y restringido. Los nuevos compañeros aprenden cómo funciona la cadena, demuestran un ciclo completo en herramientas locales y de devnet, y luego adoptan reglas de revisión y lanzamiento antes de las autoridades de producción.
Esta página es el mapa conceptual para la Incorporación de Equipos - la incorporación de desarrolladores de Solana, integrando la configuración del entorno y la Rampa del Modelo Mental de Solana en las primeras semanas, demostrando la preparación con un primer programa y dApp, estableciendo el estándar con pautas de revisión de código y utilizando conceptos de lista de verificación para que el camino sea repetible en Agave 4.1.1 con Solana CLI 3.0.10, Anchor 0.32.1, Rust 1.91.1 y @solana/kit 7.0.0.
Resumen
- La incorporación de equipos en Solana es una rampa escalonada: otorgar acceso seguro, fijar la cadena de herramientas, enseñar el modelo de ejecución centrado en cuentas, lanzar un pequeño programa más cliente en devnet, luego practicar la revisión de código centrada en la seguridad y los hábitos de lanzamiento del equipo antes de las claves de mainnet o el trabajo de autoridad de actualización.
- Por Qué Importa: Los errores en Solana son asimétricos. Un verificador de firmante o propietario faltante puede agotar fondos; la deriva de la cadena de herramientas quema semanas; comenzar desde hábitos de EVM o frontend puro sin un orden de conceptos produce una falsa confianza. La incorporación estructurada es control de riesgos, no una ceremonia de RR. HH.
- Conceptos Clave: etapas de compañero y acceso, versiones fijas, Lista de Verificación de Configuración del Entorno, Rampa del Modelo Mental de Solana, Primer Programa y dApp, Pautas de Revisión de Código, Lista de Verificación de Incorporación de Desarrolladores, solo devnet y local, LiteSVM / Surfpool, restricciones de claves de mainnet.
- Cuándo Usar Este Modelo: Las primeras dos semanas para contrataciones de Solana, contratistas, ingenieros de frontend que se unen a un equipo de programa, ingenieros de Rust nuevos en Sealevel, o para reincorporarse después de una licencia cuando la CLI y Anchor se hayan actualizado.
- Limitaciones / Compensaciones: El orden fijo es más lento que "clonar y corregir sobre la marcha" el primer día. Esa compensación es intencional: la velocidad sin alfabetización en validación de cuentas y cultura de revisión es costosa más adelante. Existen atajos de roles, pero la seguridad y la disciplina del clúster aún se aplican.
- Temas Relacionados: Lista de Verificación de Incorporación de Desarrolladores, Lista de Verificación de Configuración del Entorno, La Rampa del Modelo Mental de Solana, Primer Programa y dApp, Pautas de Revisión de Código.
Fundamentos
Incorporar desarrolladores de Solana no es "instalar Rust y abrir el monorepo". Construye tres competencias juntas:
- Alfabetización en tiempo de ejecución - las cuentas contienen estado, los programas son ejecutables, las transacciones declaran metadatos de cuentas, los PDA y CPI componen sistemas, las unidades de cómputo y las tarifas miden y programan el trabajo.
- Fluidez en la cadena de herramientas - las mismas herramientas de Agave, versión de Anchor y SDK de cliente que usa CI, además de un validador local o una ruta LiteSVM para retroalimentación rápida.
- Seguridad del equipo - cómo esta organización revisa los PR, almacena claves, nombra IDs de programa, regenera IDLs y promueve de devnet a mainnet.
Sin (1), las restricciones parecen correctas y fallan bajo cuentas adversarias. Sin (2), las luchas de "funciona en mi máquina" contra CI. Sin (3), los individuos fuertes aún lanzan la configuración de clúster incorrecta o omiten pruebas negativas.
Páginas hermanas dividen el trabajo:
| Página hermana | Trabajo en la rampa | Momento típico |
|---|---|---|
| Lista de Verificación de Configuración del Entorno | Verificar Rust, Agave/CLI, Anchor, Node, validador local | Días 1-2 |
| La Rampa del Modelo Mental de Solana | Conceptos y ejercicios ordenados antes del código de producción | Días 2-5 |
| Primer Programa y dApp | Culminación: programa Anchor + cliente @solana/kit en devnet | Días 5-10 |
| Pautas de Revisión de Código | Qué significa "listo para fusionar" para los PR de programas y clientes | PR de la semana 1 + sombra de la semana 2 |
| Lista de Verificación de Incorporación de Desarrolladores | Orquestación de dos semanas y aprobaciones de compañeros | Rampa completa |
Acceso antes que autoridad. La Semana 0 incluye git, registros de CI, documentación, una bóveda para secretos de desarrollo y RPC de devnet. Excluye claves de despliegue de mainnet, autoridades de actualización y billeteras de producción compartidas.
Las versiones fijas son incorporación. Coincidir con 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, más Surfpool 0.12.0 y LiteSVM 0.6.x para realismo local y pruebas unitarias. Alinear con rust-toolchain.toml, Anchor.toml y CI para que los fallos de compilación sean errores reales, no acertijos de versiones.
Modelo de compañero. Asignar un compañero durante los primeros cinco días hábiles para problemas de PATH, retroalimentación del primer PR y dos aprobaciones: fin de la semana 1 (PR de programa pequeño) y fin de la semana 2 (demostración de culminación más sombra de revisión). Los equipos asíncronos reemplazan las preguntas de pasillo con listas de verificación escritas y una demostración grabada del Primer Programa y dApp.
Mecánica e Interacciones
La incorporación es un pipeline. Cada etapa tiene una condición de salida antes de un acceso de escritura más amplio.
Semana 0 Acceso y orientación
| git, lectura de CI, docs, faucet de devnet, sin claves de mainnet
v
Semana 1 Cadena de herramientas + conceptos + cambio de programa pequeño
| entorno en verde -> rampa de conceptos -> pruebas LiteSVM -> primer PR
v
Semana 2 Cliente, culminación, cultura de revisión, prácticas de equipo
| cliente kit -> conciencia de compilación verificable -> revisión en sombra -> demo
v
Puerta Aprobación del compañero (lista de verificación + hábitos de seguridad)
v
Elegible para trabajo de escritura más amplio / adyacente a mainnet (política de la organización)Configuración del entorno
La Lista de Verificación de Configuración del Entorno demuestra que una computadora portátil puede compilar lo que CI compila:
- Rust 1.91.1;
cargo build-sbf, fmt y clippy disponibles. - Solana CLI 3.0.10 en Agave 4.1.1; clúster predeterminado devnet.
- Anchor a través de
avmen 0.32.1, coincidiendo con la plantillaanchor-lang. - Ruta Node/TypeScript para clientes @solana/kit 7.0.0.
- Validador local o ruta Surfpool/LiteSVM del equipo; airdrop y saldo de devnet.
- Tipos de editor (rust-analyzer) para que las restricciones sean legibles en contexto.
Salida: las versiones se imprimen correctamente, la plantilla anchor build tiene éxito, las pruebas del repositorio están en verde. Registrar las peculiaridades de shell y Apple Silicon en el manual del equipo.
Orden de conceptos
Antes del trabajo de características en programas compartidos, recorra la Rampa del Modelo Mental de Solana: cuentas y propiedad, programas como ejecutables, instrucciones y firmantes, transacciones y bloques, PDA (semillas y bumps), CPI y validación, unidades de cómputo y tarifas de prioridad, luego clientes (@solana/kit / CLI).
Los temas posteriores asumen los anteriores. La interfaz de usuario de la billetera o la generación de código IDL primero produce ingenieros que envían transacciones que no pueden explicar. Emparejar ejercicios de CLI (solana account, transferencia, solana confirm -v) con estructuras de cuenta Anchor.
Salida: el compañero puede preguntar quién firma, quién paga el alquiler, dónde vive el estado y por qué una cuenta es escribible, y obtener respuestas precisas para una instrucción simple.
Primer programa y dApp
La ruta del Primer Programa y dApp es una prueba de integración: plantilla del equipo o anchor init, compilar y probar, desplegar en devnet, luego un cliente mínimo de @solana/kit 7.0.0 que lee y escribe estado. Espere uno o dos días enfocados después de la rampa de conceptos.
Esta etapa fuerza la sincronización de IDL/cliente, IDs de programa y URLs de clúster en tablas de entorno, uso normal de simulación y registros, y la misma ruta de despliegue utilizada más tarde sin el radio de explosión de mainnet.
Salida: ID de programa de devnet en el registro del equipo, pruebas para un caso feliz y al menos un caso negativo, demostración corta del diseño de PDA o cuenta.
Pautas de revisión de código
Desde el primer PR, el orden de revisión de Solana difiere de la revisión web general. Estilo más tarde; primera pasada:
- Lista de cuentas y restricciones (o equivalentes manuales).
- Indicadores de firmante y escribible.
- Verificaciones de propietario y ID de programa.
- Semillas de PDA y bumps canónicos.
- Aritmética y cantidades de tokens.
- Objetivos de CPI y escalada de privilegios.
- Unidades de cómputo y ruido de registro.
- Pruebas (LiteSVM 0.6.x más negativos).
- Impacto de IDL y cliente.
La incorporación incluye un pequeño cambio de instrucción y la observación de una revisión sensible a la seguridad. Los ingenieros aprenden los bloqueadores: semillas de autoridad de bóveda faltantes, discrepancias de acuñación, cuentas restantes sin verificar, deriva silenciosa de IDL.
Conceptos de lista de verificación
La Lista de Verificación de Incorporación de Desarrolladores convierte el camino en cubos semanales numerados:
- Semana 0 - acceso, lectura de conceptos básicos, bóveda de desarrollo y RPC, clonar, pruebas en verde.
- Semana 1 - lista de verificación de entorno, sin mainnet, programa de plantilla, rampa de conceptos, cambio pequeño + PR, depuración de registros.
- Semana 2 - cliente kit o AnchorPy, Primer Programa y dApp, compilación verificable una vez, registro de ID de programa, sombra de revisión, prácticas de equipo, hábito de Surfpool/test-validator, demo de PDA.
Los gerentes de conceptos y compañeros imponen:
- Orden cronológico - no omitir seguridad y pruebas para ponerse al día con las características.
- Disciplina de clúster - local y devnet hasta la aprobación del compañero.
- Evidencia - salida de versiones, pruebas en verde, enlaces de PR y una demostración superan el "estoy bien" verbal.
- Atajos de roles - los contratistas de frontend aún completan las secciones de conceptos y clientes; profundizan menos en los elementos nativos del programa. Los contratistas obtienen acceso limitado en el tiempo y revocación de claves después de la demostración.
- Reincorporación - después de una licencia, volver a ejecutar la cadena de herramientas, un pequeño cambio probado, generación de código de cliente y compilación verificable porque las cadenas de herramientas se desvían.
Consideraciones Avanzadas y Aplicaciones
Rampas adaptadas a roles
| Rol | Enfatizar | Aligerar (no eliminar) | Puerta aún requerida |
|---|---|---|---|
| On-chain / full-stack | Rampa de conceptos completa, Anchor, negativos de LiteSVM, orden de revisión | Sistemas de diseño frontend profundos | A través de la sombra de revisión de seguridad |
| Frontend / UI de producto | Cuentas, txs, billeteras, firma kit, coincidencia de clúster | Internos de puntos de entrada nativos | Etapas de conceptos para cuentas/firmantes + culminación de cliente |
| Backend / indexadores | Cuentas, eventos/IDL, corrección de RPC | Microajustes de tarifas de prioridad | Sin claves de mainnet hasta que se valide la ruta de datos |
| Contratista | Repositorio acotado, claves revocables, subconjunto de lista de verificación | Documentación de propiedad a largo plazo | Demo + horario de revocación |
| Rust experimentado, nuevo en Solana | Rampa de conceptos + cultura de validación | Ejercicios básicos de Rust | Sin mainnet hasta que se demuestren hábitos de revisión |
Tamaño de la organización y señales de preparación
Los equipos pequeños aún necesitan versiones fijas, un orden de revisión y una puerta de claves de mainnet; pueden colapsar la ceremonia a un compañero, una lista de verificación, una plantilla de inicio. Los equipos más grandes agregan CODEOWNERS por programa, un carril de seguridad para cambios que mueven tokens y un manual de ejecución de autoridad de actualización escrito. Las agencias deben dividir la propiedad desde el principio: la agencia posee la cadena de herramientas y las plantillas; el cliente posee las claves de producción, el registro de ID de programa y la promoción a mainnet.
Señales objetivas de preparación:
- Las versiones de la cadena de herramientas coinciden con las fijaciones de CI.
- Puede explicar la propiedad y un PDA utilizado en el primer programa.
- Puede enviar un pequeño PR de programa con pruebas negativas.
- Puede leer un registro de simulación fallida o
solana confirm -vcon un colega. - Ha observado una revisión centrada en firmantes, propietarios y CPI.
- El cliente de culminación habla con el ID de programa de devnet del contratado.
Criterios de fallo para extender la semana 1: no puede explicar dónde vive el estado, o no puede desplegar y llamar a un programa simple en devnet. No lo tape con más tickets de UI.
Después de la rampa de dos semanas, las prácticas del equipo permanente se hacen cargo: compilación y prueba de CI en cada PR, sin deriva silenciosa de IDL, claves separadas por entorno, compilaciones verificables y pruebas exhaustivas antes de mainnet. Enseñe cuándo se aplican LiteSVM 0.6.x (unidades rápidas) frente a Surfpool 0.12.0 o pruebas de fork (estado similar a mainnet) para que los incidentes posteriores no inventen procesos desde cero.
Conceptos Erróneos Comunes
- "Los generalistas fuertes no necesitan una rampa específica de Solana." Los bloqueos de cuentas, los PDA y las verificaciones de propietario no son portátiles de los backends CRUD típicos.
- "El acceso a mainnet el primer día demuestra confianza." La confianza son pruebas en verde, buenas revisiones y disciplina de clúster. Las claves de mainnet son un privilegio después de las puertas.
- "La configuración del entorno es opcional si Docker funcionó una vez." La deriva de versiones locales todavía rompe
anchor build, los objetivos de sBPF y la generación de código del cliente. - "La rampa de conceptos es solo para principiantes." Los contratados experimentados de EVM o backend a menudo la necesitan más porque los modelos previos inducen a error (contratos como almacenamiento, descubrimiento implícito de cuentas).
- "El Primer Programa y dApp es trabajo de rutina si ya existe un monorepo." El recorrido por el monorepo por sí solo no demuestra fluidez en el despliegue y la IDL.
- "La revisión de código es estilo y porcentaje de cobertura." Para los programas, las restricciones faltantes y la autoridad de CPI incorrecta dominan el riesgo.
- "Las listas de verificación son teatro de cumplimiento." Una lista de verificación cronológica con aprobación de compañero impone orden y puertas de mainnet bajo presión del producto.
- "Los contratados de frontend pueden omitir las cuentas." Aún eligen cuentas escribibles, pagadores de tarifas y clústeres.
- "Coincidir con la versión principal de Anchor es suficiente." Las fijaciones de parches (0.32.1 frente a líneas más antiguas) y las versiones principales de kit importan para la forma de la IDL y las API.
- "Una vez incorporado, nunca vuelvas a ejecutar la configuración." Después de actualizaciones del sistema operativo, licencias o cambios en la cadena de herramientas, vuelva a verificar las versiones y reconstruya.
Preguntas Frecuentes
¿Cuánto tiempo debe durar la incorporación completa a Solana?
Aproximadamente dos semanas con apoyo de un compañero. Los ingenieros experimentados de Rust a menudo alcanzan la culminación del cliente en 5-7 días, pero aún deben completar los elementos de revisión de seguridad antes de ser elegibles para mainnet.
¿Cuál es la actividad de mayor impacto en la primera semana?
Configuración del entorno contra versiones fijadas, luego la Rampa del Modelo Mental de Solana con ejercicios de CLI antes de grandes PR de características. La cadena de herramientas más la alfabetización en cuentas desbloquean todo lo demás.
¿Cuándo puede un nuevo contratado tocar las claves de mainnet?
Después de la aprobación del compañero en los elementos de la lista de verificación a través de la seguridad y las prácticas de equipo (típicamente al final de la semana 2), más cualquier capacitación de seguridad de la organización. Hasta entonces: solo local y devnet.
¿Cómo deben usar esta sección los contratados de solo frontend?
Mantener el acceso, el entorno centrado en el cliente, las etapas de conceptos para cuentas/transacciones/firmantes, el trabajo del cliente kit y los hábitos de revisión para los PR del cliente. Aligerar los elementos profundos del programa nativo; nunca omitir la disciplina del clúster o la seguridad de la firma.
¿Por qué se requiere el Primer Programa y dApp si el producto ya existe?
Demuestra el ciclo completo del clúster seguro: compilar, probar, desplegar, leer/escribir cliente, registro de ID de programa y depuración de registros. Un recorrido por el monorepo por sí solo no demuestra fluidez en el despliegue y la IDL.
¿Cómo se ve un buen primer PR?
Un pequeño cambio de instrucción o campo de cuenta con cobertura de LiteSVM o anchor test, incluyendo al menos un caso negativo, revisado bajo las Pautas de Revisión de Código con verificaciones de seguridad antes que estilo.
¿Cómo manejamos a los contratistas?
Limitar el tiempo de acceso al repositorio y la bóveda, mantenerlos en claves de devnet, aplicar el mismo nivel de revisión para el código del programa y revocar credenciales después de la demostración de la semana 2 o el final del contrato.
¿Qué herramientas de prueba locales debe introducir la incorporación?
LiteSVM 0.6.x para pruebas unitarias rápidas, anchor test / test-validator para integración, y Surfpool 0.12.0 cuando el estado de cuenta similar a mainnet importa. Documentar la pirámide en el README del repositorio.
¿Cómo interactúan las versiones fijas con las configuraciones de las computadoras portátiles personales?
Las herramientas personales pueden existir, pero el trabajo del proyecto sigue rust-toolchain.toml, Anchor 0.32.1 a través de avm, CLI 3.0.10 y la versión del kit del repositorio. CI gana cuando las versiones difieren.
¿Qué puntos de control del gerente son importantes?
Fin de la semana 1: primer PR listo, configuración y rampa de conceptos completadas. Fin de la semana 2: demostración de culminación, sombra de revisión, aprobación de la lista de verificación. Escalar temprano si las condiciones de salida se retrasan.
¿Se requiere una certificación oficial de Solana?
No. La aprobación del compañero en la Lista de Verificación de Incorporación de Desarrolladores más los hábitos de revisión demostrados es el estándar práctico para la mayoría de los equipos.
¿Qué debemos actualizar cuando cambian las versiones de la pila?
Actualizar las fijaciones en los archivos de la cadena de herramientas y CI, refrescar los comandos de la Lista de Verificación de Configuración del Entorno, volver a ejecutar la compilación de humo anchor build y la verificación de tipos del kit, y exigir a los ingenieros que vuelvan a verificar las versiones en la próxima incorporación o en la higiene trimestral.
Relacionados
- Lista de Verificación de Incorporación de Desarrolladores - rampa cronológica de dos semanas y puertas de compañero
- Lista de Verificación de Configuración del Entorno - instalación de Rust, Agave/CLI, Anchor y validador local
- La Rampa del Modelo Mental de Solana - orden de conceptos antes del trabajo de programa de producción
- Primer Programa y dApp - programa Anchor guiado más cliente kit en devnet
- Pautas de Revisión de Código - orden de revisión de PR centrado en la seguridad para código de Solana
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.