Ferramentas para desenvolvedores

O que há nesta categoria

A maquinaria em volta de escrever e entregar código: editores, hospedagem de versões, revisão de código, integração contínua, registros de pacotes, ferramentas de ambiente e gestão de releases.

Os produtos aqui são comprados por quem os usa, o que torna a categoria incomumente honesta. Os desenvolvedores abandonam ferramentas que desperdiçam o tempo deles, e nenhum processo de compras mantém uma ruim viva por muito tempo.

Observar o software em produção pertence a monitoramento. O trabalho de interface para APIs fica em APIs e integrações. A programação assistida por modelos está em ferramentas de IA.

O pipeline é o produto

Quase tudo o que uma equipe sente no dia a dia vem do caminho que uma mudança percorre entre um notebook e a produção.

Esse caminho tem quatro pontos de controle: revisão, testes automatizados, um artefato de build e uma implantação. Todo produto desta categoria melhora um deles ou conecta dois.

A velocidade é a métrica que muda o comportamento. Um pipeline que termina em quatro minutos é usado o tempo todo. Um que leva quarenta muda a frequência com que as pessoas enviam código, incentiva mudanças maiores e piora a revisão. Ao comparar serviços de integração contínua, meça um build real do seu próprio repositório em vez de ler um benchmark.

A confiabilidade importa tanto quanto. Uma suíte de testes que falha ao acaso ensina todo mundo a rodar de novo em vez de investigar, e, quando esse hábito existe, a suíte deixou de proteger qualquer coisa.

Hospedagem de versões e revisão

A plataforma de hospedagem decide mais do que onde o código mora. Ela define como a revisão funciona, o que roda automaticamente, quem pode aprovar e como é o histórico um ano depois.

Confira branches protegidos, verificações obrigatórias, atribuição de revisores e se as aprovações podem ser impostas, e não apenas sugeridas. Depois confira a ergonomia comum: como uma mudança grande é exibida, se os comentários sobrevivem a um rebase e como é fácil descobrir por que uma linha foi escrita daquele jeito.

A migração entre plataformas é possível e nunca é de graça. O código se move sem problemas, e issues, histórico de pull requests e automações costumam chegar em estado pior do que saíram.

O que olhar no resto da cadeia de ferramentas

• Registros de pacotes, privados para bibliotecas internas e com cache para as públicas, para que uma queda em outro lugar não pare o seu build.
• Ambientes, reproduzíveis num notebook e no pipeline sem uma página de instruções de configuração.
• Segredos, injetados na hora do build e nunca commitados, com rotação possível sem indisponibilidade.
• Artefatos, versionados e mantidos por tempo suficiente para voltar à semana passada e não só a ontem.
• Ferramentas de release, sejam feature flags, lançamentos graduais ou uma implantação simples com tag.

As feature flags merecem uma nota. Elas deixam os lançamentos mais calmos e viram dívida técnica se ninguém as remove, então pergunte como a ferramenta lida com a aposentadoria delas, e não com a criação.

Preço que reflete o uso, não o número de pessoas

A integração contínua é cobrada por minutos, por concorrência ou por colaborador. Máquinas mais rápidas custam mais por minuto e, muitas vezes, menos por build, e é por isso que a comparação útil é o custo por build bem-sucedido no tamanho do seu repositório.

O armazenamento de artefatos, caches e imagens de contêiner se acumula em silêncio, e os padrões de retenção costumam ser generosos com o fornecedor. As plataformas cobradas por usuário cobram por qualquer pessoa com acesso de escrita, então vale revisar trimestralmente as contas inativas.

Os planos gratuitos aqui são incomumente bons, sobretudo para trabalho aberto, e incomumente fáceis de superar em um único mês movimentado. O conjunto mais amplo de medidores silenciosos aparece em o que as páginas de preços escondem.

O que testar antes de se comprometer

Migre um repositório real, com os testes e o build mais lento dele, e passe por ali uma semana inteira de trabalho normal.

Depois quebre algo de propósito: um teste que falha, uma implantação rejeitada, um rollback. Como uma ferramenta se comporta num dia ruim é a parte que você de fato está comprando, e ela nunca aparece na demonstração.

Ordem de compra para uma equipe em crescimento

Uma equipe de duas pessoas precisa de hospedagem de versões com revisão e de um pipeline que rode os testes. Todo o resto pode esperar, e acrescentá-lo cedo custa atenção que seria melhor gasta no produto.

Com cinco a dez pessoas, a pressão passa para o tempo de build, a consistência dos ambientes e um registro privado para código compartilhado. São os pontos em que o atrito começa a se multiplicar pela equipe em vez de afetar uma só pessoa.

Depois disso, as perguntas passam a ser de gestão de releases: flags, lançamentos graduais, retenção de artefatos e conseguir responder o que exatamente está rodando em produção agora.

Resista a comprar para a equipe que você espera ter. A ferramenta adotada antes de ser necessária vira uma configuração de que ninguém lembra ter feito, e removê-la depois é mais difícil do que teria sido acrescentá-la.