Project Guardrails: scrittura per la produzione
Negli ultimi articoli, ho parlato di un paio di cose (salvate per scrivere effettivamente alla produzione) che aiutano a gestire un progetto di successo:
- I pericoli del " design by comitato "
- Considerazioni per il provisioning di un ambiente.
L’ultima cosa di cui voglio parlare con l’apprendimento che ho sperimentato finora riguarda il mantenimento delle proverbiali chiavi del regno della scrittura e della produzione e il motivo per cui è importante.
Scrivere alla produzione
L’idea di scrivere per la produzione può sembrare il guardrail più dogmatico di quelli menzionati perché di solito va bene per coloro che stanno costruendo la soluzione e conoscono i dettagli di come sta funzionando.
Probabilmente le altre parti interessate non lo fanno (ma se lo fanno e il team di sviluppo è d’accordo con gli altri che usano il controllo della versione per gestirlo, allora provaci).
Chi ha il permesso di amministrare questa roba, davvero?
Ricorda, tuttavia, come accennato in precedenza in questa serie, il modo in cui stiamo implementando i nostri progetti è cambiato ora in modo tale che spesso abbiamo un’implementazione continua e un’integrazione continua.
E spesso, questi servizi sono collegati a un repository di codice sorgente, come GitHub, e un sistema di messaggistica (che, a sua volta, può essere collegato a Slack che trovo utile).
In modo che le persone del team siano a conoscenza di cosa è stato distribuito e quando e sappiano come ottenere il codice (che è dal repository, non dal download tramite S/FTP), se necessario.
Quando è necessario un aggiornamento rapido, dovrebbe esserci ancora una procedura in atto. Forse qualcuno è di guardia ed esiste un processo mediante il quale vengono utilizzati branching, merge, tagging e versioning semantico.
Indipendentemente da ciò, non si tratta tanto di come funziona il processo; è che è a posto e che è seguito.
Naturalmente, queste cose non sono messe in atto per rendere lo sviluppo più complicato (anche se capisco come possa sembrare così). È il contrario. È per una serie di motivi:
- per mantenere una distribuzione continua, sai, continua,
- avere test integrati,
- per misurare continuamente gli standard di codifica o la qualità del codice,
- per impedire la codifica dei cowboy,
- e altro ancora.
Non si tratta tanto di tenere fuori altre persone, ma se è responsabilità degli sviluppatori spingere il codice, allora qualcun altro dovrebbe davvero avere accesso in scrittura al server?
E questa è la linea di fondo: se stai lavorando in un team in cui i processi che hai messo in atto possono minare completamente il lavoro che stai facendo, qual è lo scopo del processo, comunque?
Perché da un momento all’altro può arrivare qualcun altro e questo non tiene conto di tutto ciò che hai fatto. Allora sei almeno:
- bloccato con dover tirare le loro modifiche probabilmente tramite S/FTP,
- confrontalo usando uno strumento diff con un ramo su cui sta lavorando qualcuno,
- implementare le modifiche (scopri perché sono state apportate),
- e poi tornare a lavorare sui requisiti.
Sembra frenetico quando lo metti così, ma è esattamente quello che succede.
L’asporto
Allora, qual è lo scopo degli ultimi post? Se dovessi riassumerlo nel modo più succinto possibile è:
Quando si tratta di un progetto, conosci le tue responsabilità e non uscire da esse. Altrimenti rischi di far deragliare il tutto.
Questo vale per sviluppatori, designer, clienti, esperti di marketing, project manager, ecc. Il modo in cui vengono designati i ruoli non ha molta importanza (voglio dire, di solito è chiaro chi dovrebbe essere chi nei ruoli sopra) ma intendo in termini di chi è l’effettiva persona di riferimento – il proprietario del progetto – per l’intero progetto.
Non essere così.
E a seconda di come va tutto quanto sopra, il progetto può essere un insieme relativamente semplice di lavoro quotidiano.
Per quanto possibile, non vogliamo goderci quello che stiamo facendo