L'emergenza coronavirus ha avuto importanti effetti su tutti i campi dell'IT. È forse ancora più importante considerare che alcuni di questi impatti non saranno confinati al picco dell'emergenza che stiamo vivendo ora. Saranno estesi nel tempo e
prenderanno la forma di nuove abitudini di vita e di lavoro. Un "new normal" che interessa molte figure aziendali. Tra gli altri,
anche gli sviluppatori e chiunque faccia parte di un ciclo DevOps.
È innegabile che molte imprese cercheranno, di loro volontà o perché spinte dalle decisioni dei vari Governi, di
incrementare il telelavoro e lo smart working. Per mesi, e probabilmente per tutto il 2020, alle persone che possono lavorare da casa verrà chiesto di farlo il più possibile. Per molte funzioni questo rappresenterà un limite. Ma
per chi si occupa di sviluppo? Con i giusti strumenti, probabilmente no. Quantomeno, non troppo.
Intendiamoci, la figura dello sviluppatore "macinacodice" che lavora blindato nel suo ufficio per non sforare le deadline è giusto una macchietta. Plausibile solo per chi di sviluppo software non se ne è mai occupato.
Anche lo sviluppo è una attività creativa e collaborativa. Un aspetto, quest'ultimo, che negli anni è anzi aumentato. Ma è vero che una forma prolungata di distanziamento sociale ha meno impatti sullo sviluppo software di quanti ne ha, poniamo, sul marketing.
Questa fase di semi-isolamento aziendale potrebbe anzi, come per tutto lo smart working, rafforzare nuove e positive modalità di lavoro. Che non vanno considerate unicamente "da sviluppatori", quindi limitate ad ambiti ristretti delle imprese. E magari non di tutte. Perché
lo sviluppo software è sempre più pervasivo e i suoi cambiamenti sono applicabili anche ad attività collegate. Come in primo luogo la gestione delle infrastrutture IT in cloud e virtualizzate.
Verso la code collaboration
Se in queste settimane abbiamo visto molte aziende lanciare piattaforme, applicazioni ed app mobili in qualche modo collegate all'emergenza Covid-19, è perché
la produttività degli sviluppatori non è stata granché ridotta dal social distancing. Volendo essere cinici, potremmo dire che proprio la semi-quarantena forse ha tolto ai team di sviluppo le distrazioni "da ufficio" che impattano sulla produttività.
Questo non vuol dire, come abbiamo accennato, che gli sviluppatori e i team Devops non abbiano bisogno di interazioni, scambi e contatti sociali. Ma sono più abituati ad utilizzare i
tool di collaborazione che si sono ampiamente diffusi sul mercato. Da Slack a Skype passando ovviamente per le piattaforme e gli strumenti di co-sviluppo consolidati. Il pensiero va immediatamente a GitHub, ma non è certamente il solo.
ImpresaCity e Red Hat hanno organizzato un webinar dedicato allo sviluppo per i team distribuiti. A questa pagina maggiori informazioni.
Va tenuto presente, infatti, che il mondo dello sviluppo è
già ampiamente abituato ad avere processi collaborativi che non richiedono la presenza fisica costante del team di sviluppo in un medesimo ambiente. Anche il semplice flusso pull-push-commit di Git è
un esempio di questo approccio. O una pipeline di CI/CD in stile Jenkins. A seconda degli strumenti e delle piattaforme che si usano, un flusso del genere può essere più articolato ed esteso. In funzione delle proprie necessità.
Sino ad arrivare a una vera e propria
"code collaboration" in tempo reale, abilitata dagli strumenti di ultima generazione che permettono a più sviluppatori di operare sul medesimo codice. Una possibilità che ha i suoi vantaggi ma che non serve probabilmente a tutti. E che richiede comunque cicli chiari di approvazione e finalizzazione del codice stesso.
Serve apertura
Il principale segnale che viene dal campo, ossia dalla platea degli sviluppatori e dei team DevOps, è che tutti gli strumenti utili per lo sviluppo "moderno"
devono essere il più possibile standard ed aperti. Ogni team di sviluppo può avere le sue preferenze, certo. Ma per avere la massima interoperabilità - anche indipendentemente dal come e dal dove si lavora - serve un elevato grado di standardizzazione.
Tutto questo vale a maggior ragione se si considera che lo sviluppo oggi è
sempre meno orientato alle applicazioni monolitiche e sempre più, per non dire quasi esclusivamente,
verso quelle cloud-native. Con tutto ciò che questo comporta in termini di integrazione tra codice e infrastruttura as-a-Service.
Tanto che il modello DevOps si sta trasformando, in diversi ambiti, in un modello che è più corretto definire
GitOps. Questo non perché si usa Git, e piattaforme come GitHub, come repository per tutto ciò che serve ad un progetto. Il termine GitOps va piuttosto letto come la possibilità di usare
una singola "fonte affidabile" dichiarativa per tutto quello che riguarda l'infrastruttura e le applicazioni che questa supporta.
In questa visione la componente infrastrutturale - quindi oggi essenzialmente il mondo
Kubernetes e la sua gestione, ma non solo - si fonde con l'application delivery. Un approccio tutto basato sul concetto di
infrastructure-as-code e sulla Continuous Delivery, quindi non immediatamente applicabile a qualsiasi azienda. Ma è la direttrice verso cui molte hanno deciso di puntare.