Indipendentemente dai progressi compiuti il giorno prima da Thomas Lawless, senior software engineer in IBM, o dal suo team, ogni nuova giornata di lavoro iniziava invariabilmente allo stesso modo: controllando se c'era o meno del codice da rivedere. “Ci sentivamo come se stessimo ricominciando lo stesso processo ogni mattina”, confida.
Lawless è responsabile della supervisione della produzione, dell'implementazione e della distribuzione di alcune delle più importanti applicazioni intranet di IBM. “Le mie attività comprendono lo sviluppo di software, l'integrazione continua, l'automazione dei test e della distribuzione e le operazioni”, spiega. “Questo significa che lavoro con 40 o 50 persone diverse ogni giorno, tutte provenienti da team diversi.”
“Abbiamo quello che ci piace definire un “flusso di consegna end-to-end”, che inizia con il codice sorgente e arriva fino alla distribuzione in produzione”, afferma Lawless. “Ora Slack è integrato in ogni fase importante di questo processo.”
Un aspetto importante del lavoro di Lawless è introdurre tecniche di sviluppo e servizi per migliorare le operazioni e ridurre i tempi di consegna. Ha iniziato a utilizzare Slack con altri team in IBM come piattaforma conversazionale più di un anno fa, ma presto ha scoperto che Slack è utile anche per raccogliere comunicazioni non umane, come avvisi di sistema e notifiche da altri servizi.
“Abbiamo quello che ci piace definire un “flusso di consegna end-to-end”, che inizia con il codice sorgente e arriva fino alla distribuzione in produzione”, afferma Lawless. “Ora Slack è integrato in ogni fase importante di questo processo.”
Gestire i processi di creazione e distribuzione in Slack
In IBM, i team preferiscono i canali pubblici di Slack (#development-team, ad esempio) perché consentono ai membri di discutere apertamente i problemi e agli esperti di altri team di partecipare al dibattito e dare il proprio contributo.
I canali di team contengono messaggi di persone reali, ma anche avvisi di sistema provenienti dalle numerose applicazioni utilizzate. Supponiamo, ad esempio, che uno sviluppatore invii una user story per la revisione nel codice sorgente. Il sistema attiva una notifica nel canale Slack del team per far sapere a tutti che c'è un nuovo codice da rivedere. Il revisore può quindi accedere al sistema per rivedere il codice direttamente dal messaggio di Slack.
“Prima che adottassimo Slack, uno sviluppatore doveva trovare la persona che riteneva dovesse eseguire la revisione, quindi inviarle un’e-mail o avviare una chat individuale”, sottolinea Lawless.
Poiché i workflow sono integrati in Slack, i team possono concentrarsi sul lavoro sapendo che riceveranno una notifica se è necessario eseguire delle revisioni singole di codice e che potranno gestirle direttamente da Slack.
Riunire i team in caso di avvisi di sistema per una migliore gestione degli incidenti
Ecco una rapida panoramica dei canali di team più popolari in IBM, con esempi delle conversazioni o notifiche che possono contenere:
#help-services: raccoglie notifiche di richieste pull per facilitare le revisioni automatizzate del codice e avvisa tutti quando la richiesta è stata approvata, evitando ai membri del team di passare da un'applicazione all'altra per accedere all'ultima versione aggiornata. Il team si affida inoltre all'integrazione Jenkins/Travis CI per avvisare gli interessati quando cambia lo stato di una build.#help-deployments: i membri del team vengono informati degli errori di distribuzione mentre le modifiche al codice passano attraverso l'automazione dei test.#help-tasks: posta notifiche quando si verifica un errore nei processi di elaborazione batch.#starfleet-monitoring: per il monitoraggio in fase di runtime e la gestione degli incidenti, le notifiche di NewRelic, Splunk e PagerDuty vengono pubblicate qui.
“In un certo senso, il canale funge da registro di controllo”, afferma Lawless. “Utilizziamo questi canali dedicati agli incidenti come base della nostra analisi per i post-mortem. Nulla è lasciato al caso perché tutta la storia dell'incidente è a portata di mano.”
Lawless spiega che quando una notifica di un errore o di un incidente viene pubblicata in Slack, i membri del team interessati creano un canale dedicato a quell'incidente in cui possono discutere potenziali soluzioni e invitare altri esperti se necessario.
Una volta risolto il problema, il team dispone di un registro completo dell'intero incidente, inclusi tutti i file, le schermate, i messaggi di errore e gli avvisi utilizzati durante il processo di risoluzione.
“In un certo senso, il canale funge da registro di controllo”, afferma Lawless. “Utilizziamo questi canali dedicati agli incidenti come base della nostra analisi per i post-mortem. Nulla è lasciato al caso perché tutta la storia dell'incidente è a portata di mano.”
Più recentemente, Lawless e il suo team hanno iniziato a usare Slack per comunicare con i fornitori dei vari servizi che utilizzano. Hanno così scoperto che la maggior parte delle aziende è felice di condividere un canale privato di Slack per discutere tutti i tipi di problemi e domande che sorgono, evitando infiniti scambi tra le diverse persone coinvolte.
Ridurre i passaggi aggiuntivi per migliorare la produttività
Lawless e il suo team hanno integrato Slack in ogni fase del processo di sviluppo, dalla scrittura e il test del codice sorgente iniziale fino alla distribuzione finale. Niente più mattine trascorse alla ricerca di nuovo codice da rivedere, tutti possono riprendere il lavoro da dove lo avevano interrotto il giorno prima.
“Ogni volta che trovavo una nuova integrazione di Slack, la attivavo”, dichiara Lawless. “Ha apportato un grande valore aggiunto e ci ha aiutato ad aumentare incredibilmente l’efficienza dei nostri processi.”
