Sistema di compilazione Python

Invece di pensare ai potenziali benefici di un potenziale strumento, pensa ai problemi reali e ai colli di bottiglia che incontri nel tuo flusso di lavoro, solo allora dovresti concentrarti sugli strumenti che effettivamente risolvono questi problemi.

Ad esempio, potresti avere un ciclo di feedback lento tra sviluppatori e controllo qualità . Immagina che uno sviluppatore impegni le modifiche lunedì alle 17:00; la giornata lavorativa termina alle 18:00 Il commit contiene una regressione. Lo sviluppatore potrebbe conoscere questa regressione pochi minuti dopo ed essere in grado di lavorare su una correzione quando il codice è ancora fresco nella sua testa? O forse domattina, quando lei arriva al lavoro e ricorda ancora, anche se non molto bene, cosa ha fatto ieri? O forse solo il venerdì, quando non ha assolutamente idea di cosa stesse facendo il giorno in cui è apparsa la regressione?

Eseguendo i test unitari, le piattaforme di compilazione consentono di ridurre il ciclo tra il momento in cui viene introdotta la regressione e il momento in cui gli sviluppatori ne vengono avvisati. Il selezionatore, meglio è. Se sono trascorsi alcuni secondi dall'introduzione del codice "cattivo", ottimo (questo è il vantaggio della compilazione in background in alcuni IDE). Se è questione di minuti, può funzionare. Se è una settimana, è probabile che stai sprecando ore di doloroso debugging.

O forse vuoi conoscere lo stato di salute del progetto : un aumento delle build fallite di solito indica un problema. Un sistema di compilazione di solito consente di identificare visivamente tali tendenze per giorni o mesi o per l'intera vita del progetto.

Oppure potresti notare che gli sviluppatori impiegano tempo a lavorare sull'aggiunta di funzionalità, mentre ci sono problemi di blocco . Commettono codice non funzionante, i loro colleghi controllano questo codice e non sono in grado di progredire o lavorare efficacemente. All'improvviso, la maggior parte dei membri del team viene trovata con un codice che non viene compilato e tutti cercano di risolvere allo stesso tempo lo stesso problema, portando a ore sprecate e un pasticcio.

Una piattaforma di compilazione sarebbe d'aiuto in questo caso, fornendo una visuale dei guasti di costruzione. Se una build fallisce, questa dovrebbe essere una risposta immediata di una squadra: gli altri membri dovrebbero evitare di aggiornare la revisione problematica; l'autore del commit che ha causato il fallimento della build dovrebbe concentrarsi sulla correzione della build (eventualmente chiedere aiuto alle coppie).

Forse vuoi semplicemente dare alle persone QA e Ops la possibilità di tornare a una revisione precedente per verificare se un bug esiste già o perché la revisione più recente introduce una regressione di blocco in produzione. In questo caso, un sistema di build accoppiato con un repository di risorse consente di passare con facilità tra diverse revisioni, senza dover contattare gli sviluppatori.

Questi sono quattro casi di eventuali problemi che potrebbero essere risolti da una piattaforma di build. Guarda i problemi reali che incontri e:

• Cerca lo strumento o modifica il tuo flusso di lavoro che risolve il problema,

• O descrivi questi problemi su Programmers.SE, chiedendo cosa dovrebbe essere fatto per risolverli.

Potrebbe essere che tu abbia effettivamente bisogno di un build server o di una piattaforma di integrazione continua. O forse hai bisogno di introdurre DevOps nella tua organizzazione. O un semplice piccolo cambiamento nel modo in cui le cose sono fatte è in gran parte sufficiente. Ricordati di concentrarti sui tuoi problemi, indipendentemente dallo strumento attuale:

“If all you have is a hammer, everything looks like a nail.”

Che tipo di sistema di costruzione come Bazel potrebbe darti?

• Generazioni self-contained con tutte le dipendenze, comprese tutte le dipendenze delle estensioni binarie, inserite in un unico pacchetto (vedere py_binary ). Ciò aiuta inoltre a mantenere il minor numero possibile di cose installate su una macchina prod. limitando la superficie di attacco.
• Test unitari facilmente richiamati in diversi ambienti.
• Compilare e imballare qualsiasi altra cosa, come il tuo JS, CSS o binari personalizzati, lungo la strada.

Ci vuole tempo e fatica per l'installazione. Paga con progetti più grandi; potrebbe essere eccessivo per i progetti più piccoli. (Ho usato Bazel su Google, dove l'infrastruttura era già predisposta per me, non ho mai provato a configurare Bazel da solo ma non sembra un pezzo di torta completo.)

Esiste un certo numero di sistemi di costruzione più piccoli, con diversi obiettivi e approcci. Le app Python non sono così difficili da distribuire; il tuo gestore di pacchetti del sistema operativo preferito potrebbe essere sufficiente (abbiamo creato semplici pacchetti Debian su un'altra grande azienda di Internet, oggi considererei anche guix).

Quello che mi piacerebbe che tu pensassi è piuttosto:

• Hai build riproducibili e qual è il modo più semplice per raggiungerli? (Bazel, tra gli altri, va bene per quello, ma non è necessario.)
• È possibile eseguire distribuzioni click-to-button riproducibili? (Bazel aiuta a raggiungerlo, ma non necessariamente nel modo più veloce o più semplice possibile.)
• Le tue build sono veloci? (Bazel esegue un lavoro ragionevole con build incrementali.)
• Le tue implementazioni sono veloci? (Bazel non aiuta né preclude questo.)
• Il tuo ambiente di sviluppo / test / QA è sufficientemente simile all'ambiente prod?

Dopo aver risposto a queste domande (forse l'hai già fatto), vedrai se Bazel, o qualsiasi altro strumento di compilazione, è adatto al tuo flusso di lavoro e / o quali sono le qualità di uno strumento di costruzione per te .