Pontos-chave de Onboarding de Time
Contratar ou rotacionar engenheiros para um produto Solana falha com mais frequência por uma rampa desorganizada: keys antes de conceitos, clients antes de accounts, ou mainnet antes de um hábito de security review. Um bom caminho é ordenado, com versões fixadas e com gates. Novos colegas aprendem como a chain funciona, provam um loop completo em tooling local e devnet, e então adotam regras de review e release antes de authorities de produção.
Esta página é o mapa conceitual de Team Onboarding - integrar desenvolvedores Solana, encaixar setup de ambiente e a Solana Mental Model Ramp nas primeiras semanas, provar prontidão com um primeiro programa e dApp, definir o padrão com code review guidelines, e usar conceitos de checklist para que o caminho seja repetível no Agave 4.1.1 com Solana CLI 3.0.10, Anchor 0.32.1, Rust 1.91.1 e @solana/kit 7.0.0.
Resumo
- Onboarding de time Solana é uma rampa em estágios: conceder acesso seguro, fixar a toolchain, ensinar o modelo de execução account-first, entregar um programa pequeno mais client em devnet, e então praticar code review security-first e hábitos de release do time antes de keys mainnet ou trabalho com upgrade authority.
- Por que importa: Erros em Solana são assimétricos. Um signer ou owner check ausente pode drenar fundos; drift de toolchain queima semanas; começar com hábitos EVM ou frontend puro sem ordem de conceitos produz falsa confiança. Onboarding estruturado é controle de risco, não cerimônia de RH.
- Conceitos-chave: buddy e estágios de acesso, version pins, Environment Setup Checklist, Solana Mental Model Ramp, First Program & dApp, Code Review Guidelines, Onboarding Devs Checklist, apenas devnet e local, LiteSVM / Surfpool, gates de keys mainnet.
- Quando usar este modelo: Primeiras duas semanas para contratações Solana, contractors, engenheiros frontend entrando em time de programa, engenheiros Rust novos em Sealevel, ou re-onboarding após licença quando CLI e Anchor mudaram.
- Limitações / trade-offs: Ordem fixa é mais lenta que "clone e hotfix" no dia um. Esse trade-off é intencional: velocidade sem literacia em validação de accounts e cultura de review é cara depois. Atalhos por papel existem, mas segurança e disciplina de cluster ainda se aplicam.
- Tópicos relacionados: Onboarding Devs Checklist, Environment Setup Checklist, The Solana Mental-Model Ramp, First Program & dApp, Code Review Guidelines.
Fundamentos
Onboarding de desenvolvedores Solana não é "instalar Rust e abrir o monorepo." Ele constrói três competências juntas:
- Literacia de runtime - accounts guardam estado, programs são executáveis, transactions declaram account metas, PDAs e CPIs compõem sistemas, compute units e fees medem e agendam trabalho.
- Fluência de toolchain - as mesmas ferramentas Agave, versão Anchor e client SDK que o CI usa, mais um validator local ou caminho LiteSVM para feedback rápido.
- Segurança de time - como esta org revisa PRs, armazena keys, nomeia program IDs, regenera IDLs e promove de devnet para mainnet.
Sem (1), constraints parecem corretas e falham sob accounts adversariais. Sem (2), "funciona na minha máquina" briga com CI. Sem (3), indivíduos fortes ainda entregam cluster config errado ou pulam testes negativos.
Páginas irmãs dividem o trabalho:
| Página irmã | Papel na rampa | Timing típico |
|---|---|---|
| Environment Setup Checklist | Verificar Rust, Agave/CLI, Anchor, Node, validator local | Dias 1-2 |
| The Solana Mental-Model Ramp | Conceitos ordenados e exercícios antes de código de produção | Dias 2-5 |
| First Program & dApp | Capstone: programa Anchor + client @solana/kit em devnet | Dias 5-10 |
| Code Review Guidelines | O que "pronto para merge" significa para PRs de programa e client | PR semana 1 + shadow semana 2 |
| Onboarding Devs Checklist | Orquestração de duas semanas e gates do buddy | Rampa inteira |
Acesso antes de authority. Semana 0 inclui git, logs de CI, docs, vault para secrets de dev e RPC devnet. Exclui keys de deploy mainnet, upgrade authorities e wallets de produção compartilhadas.
Version pins são onboarding. Alinhe 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, mais Surfpool 0.12.0 e LiteSVM 0.6.x para realismo local e testes unitários. Alinhe com rust-toolchain.toml, Anchor.toml e CI para que falhas de build sejam bugs reais, não quebra-cabeças de versão.
Modelo buddy. Atribua um buddy nos primeiros cinco dias úteis para problemas de PATH, feedback do primeiro PR e dois sign-offs: fim da semana 1 (PR de programa pequeno) e fim da semana 2 (demo do capstone mais shadow de review). Times assíncronos substituem perguntas no corredor por checklists escritos e um walkthrough gravado de First Program & dApp.
Mecânica e interações
Onboarding é um pipeline. Cada estágio tem uma condição de saída antes de acesso de escrita mais amplo.
Week 0 Access & orientation
| git, CI read, docs, devnet faucet, no mainnet keys
v
Week 1 Toolchain + concepts + tiny program change
| env green -> concept ramp -> LiteSVM tests -> first PR
v
Week 2 Client, capstone, review culture, team practices
| kit client -> verifiable build awareness -> shadow review -> demo
v
Gate Buddy sign-off (checklist + security habits)
v
Eligible for broader write / mainnet-adjacent work (org policy)Setup de ambiente
O Environment Setup Checklist prova que um laptop consegue buildar o que o CI builda:
- Rust 1.91.1;
cargo build-sbf, fmt e clippy disponíveis. - Solana CLI 3.0.10 no Agave 4.1.1; cluster padrão devnet.
- Anchor via
avmem 0.32.1, alinhado aoanchor-langdo template. - Caminho Node/TypeScript para clients @solana/kit 7.0.0.
- Validator local ou caminho Surfpool/LiteSVM do time; airdrop e saldo em devnet.
- Tipos no editor (rust-analyzer) para constraints legíveis em contexto.
Saída: versões imprimem corretamente, anchor build do template passa, testes do repo verdes. Registre quirks de shell e Apple Silicon no runbook do time.
Ordem de conceitos
Antes de feature work em programas compartilhados, percorra a Solana Mental Model Ramp: accounts e ownership, programs como executáveis, instructions e signers, transactions e blockhashes, PDAs (seeds e bumps), CPIs e validação, compute units e priority fees, depois clients (@solana/kit / CLI).
Tópicos posteriores assumem os anteriores. Wallet UI ou codegen de IDL primeiro produz engenheiros que enviam transactions que não conseguem explicar. Combine exercícios de CLI (solana account, transfer, solana confirm -v) com structs de account do Anchor.
Saída: o buddy pode perguntar quem assina, quem paga rent, onde o estado vive e por que uma account é writable, e obter respostas precisas para uma instruction simples.
Primeiro programa e dApp
O caminho First Program & dApp é prova de integração: template do time ou anchor init, build e test, deploy em devnet, depois um client mínimo @solana/kit 7.0.0 que lê e escreve estado. Espere um a dois dias focados após a rampa de conceitos.
Este estágio força sync IDL/client, program IDs e URLs de cluster em tabelas env, uso normal de simulation e logs, e o mesmo caminho de deploy usado depois sem blast radius de mainnet.
Saída: program id em devnet no registry do time, testes para happy path e pelo menos um caso negativo, demo curta do layout de PDA ou account.
Code review guidelines
Desde o primeiro PR, a ordem de review Solana difere de review web geral. Estilo depois; primeira passada:
- Lista de accounts e constraints (ou equivalentes manuais).
- Flags de signer e writable.
- Checks de owner e program id.
- Seeds de PDA e bumps canônicos.
- Aritmética e quantidades de token.
- Alvos de CPI e privilege escalation.
- Compute unit e ruído de logs.
- Testes (LiteSVM 0.6.x mais negativos).
- Impacto em IDL e client.
Onboarding inclui uma mudança pequena de instruction e shadow de um review sensível a segurança. Engenheiros aprendem blockers: seeds de vault authority ausentes, mint mismatches, remaining accounts sem check, drift silencioso de IDL.
Conceitos de checklist
O Onboarding Devs Checklist transforma o caminho em buckets numerados por semana:
- Semana 0 - acesso, leitura básica, vault dev e RPC, clone, testes verdes.
- Semana 1 - env checklist, sem mainnet, programa template, rampa de conceitos, mudança pequena + PR, debug de logs.
- Semana 2 - client kit ou AnchorPy, First Program & dApp, verifiable build uma vez, registry de program id, shadow de review, práticas de time, hábito Surfpool/test-validator, demo de PDA.
Conceitos que managers e buddies aplicam:
- Ordem cronológica - não pule segurança e testes para recuperar features.
- Disciplina de cluster - local e devnet até sign-off do buddy.
- Evidência - output de versão, testes verdes, links de PR e uma demo vencem verbal "estou pronto."
- Variantes por papel - contratações frontend ainda completam seções de conceito e client; aprofundam menos itens de programa. Contractors recebem acesso com prazo e revogação de keys após a demo.
- Re-onboarding - após licença, reexecute toolchain, uma mudança pequena testada, codegen de client e verifiable build porque toolchains driftam.
Considerações avançadas e aplicações
Rampas moldadas por papel
| Papel | Enfatizar | Aliviar (não apagar) | Gate ainda exigido |
|---|---|---|---|
| On-chain / full-stack | Rampa de conceitos completa, Anchor, negativos LiteSVM, ordem de review | Design systems frontend profundos | Até shadow de security review |
| Frontend / product UI | Accounts, txs, wallets, signing kit, cluster match | Internals de entrypoint nativo | Estágios de conceito para accounts/signers + capstone de client |
| Backend / indexers | Accounts, events/IDL, correção de RPC | Micro-tuning de priority fee | Sem keys mainnet até data path validado |
| Contractor | Repo com escopo, keys revogáveis, subset de checklist | Docs de ownership de longo prazo | Demo + cronograma de revogação |
| Rust experiente, novo em Solana | Rampa de conceitos + cultura de validação | Drills básicos de Rust | Sem mainnet até hábitos de review demonstrados |
Tamanho da org e sinais de prontidão
Times pequenos ainda precisam de version pins, ordem de review e gate de keys mainnet; podem colapsar cerimônia em um buddy, um checklist e um template starter. Times maiores adicionam CODEOWNERS por programa, lane de segurança para mudanças que movem tokens e runbook escrito de upgrade authority. Agências devem dividir ownership cedo: agência possui toolchain e templates; cliente possui keys de produção, registry de program id e promoção mainnet.
Sinais objetivos de prontidão:
- Versões de toolchain coincidem com pins do CI.
- Consegue explicar ownership e um PDA usado no primeiro programa.
- Consegue landar um PR de programa pequeno com testes negativos.
- Consegue ler uma simulation falha ou log de
solana confirm -vcom um par. - Fez shadow de um review focado em signers, owners e CPI.
- Client capstone fala com o program id devnet da própria contratação.
Critérios de falha para estender semana 1: não consegue explicar onde o estado vive, ou não consegue deployar e chamar um programa simples em devnet. Não disfarce isso com mais tickets de UI.
Após a rampa de duas semanas, práticas permanentes do time assumem: CI build e test em todo PR, sem drift silencioso de IDL, keys separadas por ambiente, verifiable builds e soak antes de mainnet. Ensine quando LiteSVM 0.6.x (units rápidos) versus Surfpool 0.12.0 ou fork tests (estado tipo mainnet) se aplicam para que incidentes posteriores não inventem processo do zero.
Equívocos comuns
- "Generalistas fortes não precisam de rampa específica Solana." Account locks, PDAs e owner checks não são portáveis de backends CRUD típicos.
- "Acesso mainnet no dia um prova confiança." Confiança é testes verdes, bons reviews e disciplina de cluster. Keys mainnet são privilégio após gates.
- "Setup de ambiente é opcional se Docker funcionou uma vez." Drift de versão local ainda quebra
anchor build, targets sBPF e codegen de client. - "A rampa de conceitos é só para juniores." Contratações EVM ou backend sênior frequentemente precisam mais porque modelos anteriores enganam (contracts como storage, descoberta implícita de accounts).
- "First Program & dApp é busywork se um monorepo existe." O capstone prova que esta contratação consegue deployar, registrar program id e conectar kit sob seu CI e layout de secrets.
- "Code review é estilo e percentual de coverage." Para programas, constraints ausentes e CPI authority ruim dominam risco.
- "Checklists são teatro de compliance." Um checklist cronológico com sign-off do buddy aplica ordem e gates mainnet sob pressão de produto.
- "Contratações frontend podem pular accounts." Elas ainda escolhem accounts writable, fee payers e clusters.
- "Coincidir major version do Anchor basta." Pins de patch (0.32.1 vs linhas antigas) e majors de kit importam para forma de IDL e APIs.
- "Uma vez onboarded, nunca reexecute setup." Após upgrades de OS, licença ou bumps de toolchain, re-verifique versões e rebuild.
FAQs
Quanto tempo o onboarding Solana completo deve levar?
Cerca de duas semanas com suporte de buddy. Engenheiros Rust experientes frequentemente chegam ao capstone de client em 5-7 dias mas ainda devem completar itens de security review antes de elegibilidade mainnet.
Qual é a atividade de maior alavancagem na primeira semana?
Setup de ambiente contra versões fixadas, depois a Solana Mental Model Ramp com exercícios de CLI antes de PRs grandes de feature. Toolchain mais literacia de accounts desbloqueiam todo o resto.
Quando uma nova contratação pode tocar keys mainnet?
Após sign-off do buddy nos itens de checklist até segurança e práticas de time (tipicamente fim da semana 2), mais qualquer treinamento de segurança da org. Até lá: apenas local e devnet.
Como contratações apenas frontend devem usar esta seção?
Mantenha acesso, env focado em client, estágios de conceito para accounts/transactions/signers, trabalho de client kit e hábitos de review para PRs de client. Alivie itens profundos de programa nativo; nunca pule disciplina de cluster ou segurança de signing.
Por que exigir First Program & dApp se o produto já existe?
Prova o loop completo de cluster seguro: build, test, deploy, read/write de client, registry de program id e debug de logs. Um tour de monorepo sozinho não prova fluência de deploy e IDL.
Como é um bom primeiro PR?
Uma mudança pequena de instruction ou campo de account com coverage LiteSVM ou anchor test, incluindo pelo menos um caso negativo, revisada sob Code Review Guidelines com checks de segurança antes de estilo.
Como lidamos com contractors?
Acesso com prazo a repo e vault, mantenha-os em keys devnet, aplique a mesma barra de review para código de programa e revogue credenciais após a demo da semana 2 ou fim do engagement.
Quais ferramentas de teste local o onboarding deve introduzir?
LiteSVM 0.6.x para testes unitários rápidos, anchor test / test-validator para integração, e Surfpool 0.12.0 quando estado de account tipo mainnet importa. Documente a pirâmide no README do repo.
Como version pins interagem com setups pessoais de laptop?
Ferramentas pessoais podem existir, mas trabalho de projeto segue rust-toolchain.toml, Anchor 0.32.1 via avm, CLI 3.0.10 e versão kit do repo. CI vence quando versões discordam.
Quais checkpoints de manager importam?
Fim da semana 1: primeiro PR pronto, env e rampa de conceitos feitos. Fim da semana 2: demo do capstone, shadow de review, sign-off de checklist. Escale cedo se condições de saída escorregarem.
Certificação oficial Solana é obrigatória?
Não. Sign-off do buddy no Onboarding Devs Checklist mais hábitos de review demonstrados é o padrão prático para a maioria dos times.
O que atualizar quando versões de stack mudam?
Bumpe pins em arquivos de toolchain e CI, atualize comandos do Environment Setup Checklist, reexecute smoke anchor build e typecheck kit, e exija que engenheiros re-verifiquem versões no próximo onboarding ou higiene trimestral.
Related
- Onboarding Devs Checklist - rampa cronológica de duas semanas e gates do buddy
- Environment Setup Checklist - instalação de Rust, Agave/CLI, Anchor e validator local
- The Solana Mental-Model Ramp - ordem de conceitos antes de trabalho de programa de produção
- First Program & dApp - programa Anchor guiado mais client kit em devnet
- Code Review Guidelines - ordem de review de PR security-first para código Solana
Stack versions: This page was written for 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, and LiteSVM 0.6.x.