7 Motivi per Implementare la Continuos Delivery
In questo post vedremo 7 motivi per cui se hai a che fare con lo sviluppo software è fondamentale implementare un processo di Continuos Delivery.
Partiamo subito
- Un deploy manuale ha bisogno di essere documentato. La documentazione ha il brutto vizio di diventare obsoleta ed è impegnativo mantenerla aggiornata. Inoltre per la sua corretta tenuta è necessario coinvolgere molte persone, per cui la documentazione è o obsoleta o incompleta. Uno processo automatico di deploy invece può funzionare oppure no. Se funziona è aggiornato e completo altrimenti si riesce subito a capire cosa non va e sistemarlo subito. Il processo stesso costituisce documentazione.
- Quando il processo di deploy non è automatizzato esso non è ripetibile o affidabile, è quindi necessario sprecare tempo per assicurarsi che sia avvenuto nel modo corretto
- Quando il processo di deploy non è automatizzato esso genera errori, non si tratta di stabilire se genera errori, si tratta di stabilire la gravità e l’impatto degli errori che si genereranno di certo e questo comporta uno spreco di tempo
- Il deploy automatizzato incoraggia la collaborazione e la conoscenza perché è basato sull’esecuzione di uno script o di automatismi che tutti conoscono. La documentazione invece è scritta da chi ha una certa comprensione del processo ed è difficile trasferire questa conoscenza ad altri membri del team
- Il deploy manuale è affidato generalmente ad alcuni esperti, se questi per qualche motivo non sono disponibili non è possibile rilasciare l’applicazione
- Per eseguire un deploy manuale è necessaria un’alta competenza per gestire quello che potrebbe succedere nel mentre, al contempo è un’attività molto noiosa e ripetitiva. Usare personale altamente addestrato per compiti ripetitivi è il modo di assicurarsi malumore nelle persone (con conseguente aumento della percentuale di errore) e spreco delle competenze per compiti che possono essere automatizzabili
- L’unico modo per testare un processo di deploy manuale è quello di eseguirlo, mentre un deploy automatico è facilmente testabile
Essenzialmente abbracciare la continuos delivery porta solo vantaggi, primo fra tutti il Time To Market del prodotto.
Lavorare in questo modo infatti riesce a mettere velocemente davanti all’utente finale il software e nel caso ci sia bisogno di aggiustamenti si hanno feedback veloci dall’utente (caposaldo dello sviluppo Agile).
Si preferisce quindi la possibilità di avere un feedback veloce da parte dell’utente finale e produrre solo quelle funzionalità che desidera e che gli sono utili piuttosto che produrre un software che potrebbe non incontrare il favore del pubblico perché si sono mal interpretati i requisiti e purtroppo viene alla luce solo alla fine del progetto.
Sono un sviluppatore web.
La tecnologia che uso è quella di Microsoft (.NET MVC, .NETCore…)
Nella mia carriera ho ricoperto varie funzioni all’interno del team di sviluppo a partire dalla parte grafica con AngularJs/Angular8 e finendo con il coordinare il team da Business Owner (Agile/Scrum).
Ho tenuto diversi corsi di formazione e avvicinamento alla professione per giovani talenti; ho scoperto con stupore di avere una naturale propensione a questo tipo di attività a cui sicuramente darò seguito.
Nel team attualmente sono un developer, un po’ perché mi piace, un po’ perché così riesco a tenere sempre aggiornate le mie competenze.
Lavoro solo in consulenza e a progetto.
