Strumenti per sviluppatori

Cosa c’è in questa categoria

Gli ingranaggi che stanno attorno alla scrittura e al rilascio del codice: editor, hosting del codice, code review, integrazione continua, registry di pacchetti, strumenti per gli ambienti e gestione dei rilasci.

I prodotti qui li comprano le persone che li usano, il che rende la categoria insolitamente onesta. Gli sviluppatori abbandonano gli strumenti che fanno perdere tempo, e nessun processo d’acquisto tiene in vita a lungo uno strumento sbagliato.

Osservare il software in produzione appartiene a monitoraggio. Il lavoro sulle interfacce per le API sta in API e integrazioni. La programmazione assistita da modelli è in strumenti di IA.

La pipeline è il prodotto

Gran parte di ciò che un team sente giorno per giorno viene dal percorso che una modifica compie tra un portatile e la produzione.

Quel percorso ha quattro punti di controllo: revisione, test automatici, un artefatto di build e un deployment. Ogni prodotto di questa categoria ne migliora uno o ne collega due.

La velocità è la metrica che cambia i comportamenti. Una pipeline che finisce in quattro minuti viene usata di continuo. Una da quaranta cambia la frequenza dei push, incoraggia modifiche più grandi e peggiora la revisione. Quando confronti i servizi di integrazione continua, misura una build vera del tuo repository invece di leggere un benchmark.

Conta altrettanto l’affidabilità. Una suite di test che fallisce a caso insegna a tutti a rieseguire invece di indagare, e una volta che l’abitudine esiste la suite ha smesso di proteggere qualsiasi cosa.

Hosting del codice e revisione

La piattaforma di hosting decide più di dove vive il codice. Stabilisce come funziona la revisione, cosa gira in automatico, chi può approvare e come appare la cronologia un anno dopo.

Controlla branch protetti, verifiche obbligatorie, assegnazione dei revisori e se le approvazioni possono essere imposte e non solo suggerite. Poi controlla l’ergonomia ordinaria: come viene mostrata una modifica grande, se i commenti sopravvivono a un rebase e quanto è facile scoprire perché una riga è stata scritta in quel modo.

La migrazione tra piattaforme è possibile e mai gratuita. Il codice si sposta in modo pulito, mentre issue, cronologia delle pull request e automazioni di solito arrivano in condizioni peggiori di come sono partite.

Cosa guardare nel resto della toolchain

• Registry di pacchetti, privati per le librerie interne e con cache per quelle pubbliche, così un’interruzione altrove non ferma la tua build.
• Ambienti, riproducibili su un portatile e nella pipeline senza una pagina di istruzioni di configurazione.
• Segreti, iniettati al momento della build e mai committati, con rotazione possibile senza downtime.
• Artefatti, versionati e conservati abbastanza a lungo da tornare alla settimana scorsa e non solo a ieri.
• Strumenti di rilascio, che siano feature flag, rilasci graduali o un semplice deploy con tag.

I feature flag meritano una nota. Rendono i rilasci più tranquilli e diventano debito tecnico se nessuno li rimuove, quindi chiedi come lo strumento gestisce il ritiro e non la creazione.

Prezzi che riflettono l’uso, non il numero di persone

L’integrazione continua è fatturata a minuti, a concorrenza o per collaboratore. Le macchine più veloci costano di più al minuto e spesso meno per build, ed è per questo che il confronto utile è il costo per build riuscita alla dimensione del tuo repository.

Lo spazio per artefatti, cache e immagini di container si accumula in silenzio, e i valori predefiniti di conservazione di solito sono generosi per il fornitore. Le piattaforme a utente fanno pagare chiunque abbia accesso in scrittura, quindi gli account dormienti vanno rivisti ogni trimestre.

I piani gratuiti qui sono insolitamente buoni, soprattutto per il lavoro aperto, e insolitamente facili da superare in un solo mese intenso. L’insieme più ampio dei contatori silenziosi compare in cosa nascondono le pagine dei prezzi.

Cosa provare prima di impegnarsi

Sposta un repository vero, con i suoi test e la sua build più lenta, e fai passare una settimana intera di lavoro normale.

Poi rompi qualcosa di proposito: un test che fallisce, un deployment respinto, un rollback. Come si comporta uno strumento in una brutta giornata è la parte che stai davvero comprando, e non compare mai nella dimostrazione.

Ordine d’acquisto per un team in crescita

Un team di due ha bisogno di hosting del codice con revisione e di una pipeline che esegua i test. Tutto il resto può aspettare, e aggiungerlo presto costa attenzione che sarebbe meglio spendere sul prodotto.

A cinque o dieci persone la pressione si sposta su tempi di build, coerenza degli ambienti e un registry privato per il codice condiviso. Sono i punti in cui l’attrito comincia a moltiplicarsi nel team invece di riguardare una sola persona.

Oltre, le domande diventano gestione dei rilasci: flag, rilasci graduali, conservazione degli artefatti e la capacità di rispondere a cosa stia girando esattamente in produzione in questo momento.

Resisti alla tentazione di comprare per il team che prevedi di avere. Gli strumenti adottati prima che servano diventano una configurazione che nessuno ricorda di aver fatto, e rimuoverli dopo è più difficile di quanto sarebbe stato aggiungerli.