Contattaci

    Seleziona un argomento
    Accetta la nostra Privacy Policy

    AEP Ticketing Solutions

    AEP-Ticketing Solution

    Collaborazione

     Una delle collaborazioni più longeve che abbiamo il piacere di aver creato e consolidato, è proprio quella con la realtà di AEP Ticketing Solutions, che progetta e produce da oltre vent’anni sistemi ed apparati per la bigliettazione elettronica destinati al trasporto pubblico. AEP è tra le aziende italiane del settore più conosciute nel mondo.

    Insieme abbiamo portato e stiamo portando avanti molti progetti cross-service che abbracciano, infatti, sia il nostro servizio “Prodotto o Tecnologia da evolvere” che “Supporto alla Transizione digitale”.

    Esigenze

     AEP Ticketing Solutions ha da sempre la necessità di far convivere le sue due anime: progettazione di device altamente funzionali ed innovazione del software. Le esigenze per cui Giuneco ha dato il suo supporto, dedicando ad AEP un nostro team on site, toccano entrambi gli aspetti.

    Vediamo le principali necessità che abbiamo cercato di supportare:

    • Organizzare il processo di sviluppo e i flussi interni per automatizzare e certificare il rilascio degli applicativi ai clienti.
    • Per poter ottenere il risultato di automazione di cui sopra abbiamo aiutato all’evoluzione dei prodotti andando a suddividere in componenti atomici le parti importanti del prodotto. Questo è stato indispensabile per garantire una corretta distribuzione delle responsabilità e per rendere trasparente ad ogni componente dell’azienda gli impatti delle evoluzioni. Infatti, aver implementato SemVer come modello di versioning comunica immediatamente l’entità del cambiamento su ogni componente e quindi fornisce una prima indicazione sulla “difficoltà” di portare in campo ogni evoluzione del prodotto

    Obiettivi

    Automazione flussi

    Il processo di automazione è stato introdotto per gestire due diversi aspetti:

    • certificare la versione installata in campo su ogni cliente. Automatizzando il processo di creazione degli asset e anche la successiva installazione in campo abbiamo ottenuto il risultato di ridurre notevolmente il tempo di verifica dell’esito dell’installazione andando quindi a ridurre lo spreco dovuto a falsi errori di configurazione o “bug” di installazione
    • automatizzare l’installazione presso il cliente evitando possibili “dimenticanze” o errori in una fase così critica e garantendone una riproducibilità rispetto all’ambiente di test, ottenendo quindi anche una riduzione del tempo impiegato
    • Introduzione della cultura DevOps in cui ogni team è responsabile, non solo della realizzazione del software, ma anche del suo versionamento e soprattuto dell’installazione

    Evoluzione di un prodotto

    Apparati embedded

    La parte più importante nella modularizzazione è stata quella di suddividere le applicazioni in C/C++ in componenti versionati e disponibili su un repository aziendale condiviso.

    Per fare questo abbiamo utilizzato vari strumenti: ad esempio, per permettere il rilascio delle singole parti, abbiamo utilizzato CONAN uno strumento che permette di impostare le catene di dipendenze dei pacchetti anche in relazione alle architetture in cui poi verrà compilato il programma definitivo (Windows, Linux, ARM, …). Conan ci ha permesso infatti di nominare il singolo pacchetto e la versione in modo univoco, per garantire poi la possibilità di evitare problemi nella procedura automatizzata e di poterci muovere, se necessario, tra le varie versioni (univocità dei pacchetti, immodificabile, e garantito).

    Questo strumento ci ha garantito di poter identificare in modo univoco i singoli moduli che ci hanno permesso di ricomporre il blocco di codice originale, per poterli esternalizzare su di un sistema di controllo comodo ed efficace come BitBucket.

    Per quanto riguarda, invece, la gestione delle versioni delle singole librerie abbiamo utilizzato SemVer

    Grazie all’automazione del processo di sviluppo è stato possibile evitare i classici rischi che poteva creare la frammentazione del software originale. È stato infatti gestito tutto in modo chiaro e veloce senza risentire dell’onerosità dei singoli pacchetti.

    Servizi e applicazioni web

    Lo stesso schema di processo adottato per i dipositivi embedded è stato utilizzato anche sui servizi e applicazioni web.

    In questo caso l’ecosistema .NET è più ricco e offre funzionalità che sono da considerarsi standard “de-facto”, come ad esempio nuget. Siamo andati quindi ad aggredire aspetti più legati al processo di rilascio, configurazione e qualità degli artefatti. In particolare, la parte di deploy necessita di configurazioni molto più sofisticate rispetto agli apparati embedded e impone vincoli sia tecnologici che contrattuali.

    Il primo passo è stato quello di descrivere e implementare la metodologia con cui una nuova release di un qualsiasi componente viene portata a bordo del server. Per fare questo abbiamo creato dei building block che utilizzano Ansible e la relativa descrizione dello stato atteso sul server, ovvero abbiamo creato un repository che descrive per ogni cliente, la lista di componenti e relative versioni che devono essere installate. Questo si traduce in una sorta di “contratto” col cliente, che molto spesso decide di mantenere la governance della sua infrastruttura.

    Per poter ottenere questo “contratto” è importante che esista un flusso certificato che produce e versiona ogni pacchetto/componete. È in questo momento che abbiamo introdotto la cultura DevOps, in cui ogni team è responsabile sia di sviluppare il software che di preoccuparsi di come esso sarà installato in campo. Il paradigma implementato è quello di Infrastructure as code, ovvero ogni componente dichiara, sfruttando i building block descritti sopra, come deve essere installato sul server e quali tipo di configurazioni specifiche o condivise servono. Per esempio, un microservizio X, insieme al sorgente del codice, potrà contenere la descrizione del runner (IIS, NGINX, Docker) gli eventuali asset privati (immagini, ecc.), le configurazioni globali (connessione al DB, indirizzi di altri servizi) e gli eventuali parametri privati (chiavi di accesso, feature toggle, …).

    Per evitare errori umani nella creazione dei pacchetti/componenti abbiamo introdotto le pipeline di continuous integration, in questo modo possiamo certificare e rendere riproducibile la creazione di un componente. Per realizzare questo abbiamo usato TeamCity come strumento di Continuous Integration e Nexus come unico repository da cui è possibile scaricare un componente da installare. Ovviamente, per cercare di evitare regressioni, le pipeline di Continuous Integration eseguono unit test ed eventuali integration tests.

    SFIDE

    • Supportare i team nella gestione dei cambiamenti, fornendo dove necessario: strumenti, formazione o aiuto pratico
    • Modularizzare il codice preesistente che avrebbe impedito di effettuare l’automazione
    • Selezionare gli strumenti adatti per implementare il processo
    • Ridurre il tempo di installazione di un sistema, andando quindi a liberare risorse preziose
    • Evitare il collo di bottiglia dei Senior che possiedono la conoscenza del sistema, ovvero rendere il processo di deploy ripetibile
    • Certificare la versione dei componenti installati per fornire ai clienti e ai vari escrow una certezza di riproducibilità
    • Evitare regressioni

    Benefici ottenuti con modularizzazione e automazione

     

    Benefici lato tecnico

     

    • Automazione della compilazione su differente architettura X86, ARM e Android
    • Possibilità di sviluppare e testare il software embedded senza usare il device fisico poiché, grazie agli Unit Test e alla certificazione del processo di build (CONAN), non è necessario perdere tempo a reimpostare gli ambienti di sviluppo specifici
    • Automazione della parte dei prerequisti lato server (runtime, iis, RabbitMQ, etc.)
    • Gestione del software “a prodotto” e non a progetto specifico dedicato al singolo cliente. Adesso quando si sviluppano feature richieste da un cliente, possiamo riproporre la sua distribuzione in modo semplice e funzionale anche sugli altri clienti
    • Installazione ex-novo di servizi e applicazioni web, lavoro che prima impiegava alcune giornate dei developer, ridotto a qualche ora di una “macchina” con conseguente aumento della produttività interna.
    • Archiviazione unica e certificata dei componenti (Nexus) in grado di integrarsi con moltissimi tipi di build environment (Maven, Nuget, Conan, Ansible, etc.)
    • Automatizzazione dell’invio di notifiche a tutti coloro che sono interessati agli aggiornamenti (responsabili dei clienti), tramite liste di distribuzione precompilate, attraverso un Changelog auto-costruito dal build server. Ciò avviene collegandosi con Jira e recuperando le informazioni delle user stories incluse nella release. Questo, insieme all’implementazione di SemVer, aiuta chi è a contatto con i clienti di essere consapevoli di cosa l’aggiornamento permette di risolvere e dove va ad impattare. Così facendo le persone a contatto col cliente sono responsabilizzate e sempre informate in maniera automatica (questo processo non deve comunque inibire il colloquio, ma solo renderlo più snello e focalizzato sulle parti importanti).

     

    Benefici lato Business

     

    • Velocizzazione nel lavoro quotidiano permettendo di ricompilare solo ciò su cui sta lavorando: il sistema in autonomia si occupa di ricomporre il resto e quindi sveltisce sensibilmente il lavoro.
    • Maggior libertà e sicurezza nel fare modifiche ed evolvere il prodotto, grazie al fatto che resta “fotografato” nel tempo quando un problema può essere nato e dove
    • Lo scripting dei processi porta a facilitare la creazione di una documentazione delle modalità di rilascio, rendendo l’azienda indipendente dal singolo sviluppatore. Gli script di installazione sono infatti una guida passo-passo che porta da un sistema vuoto ad un sistema perfettamente funzionante, garantendone anche un aggiornamento costante (più di quello che purtroppo avrebbe una documentazione tecnica)
    • Recupero di ore lavorative di risorse esperte
    • Migliore time to market per le nuove funzionalità

    Il progresso tecnologico e l’evoluzione di prodotti e software ha, come possiamo vedere in questo caso, un profondo impatto su tantissimi e disparati aspetti aziendali. Aver eliminato le versioni multiple e l’incertezza circa la validità dell’ultima versione è stato un importante motore per favorire il lavoro di squadra, creare un’identità di team con modalità di lavoro coese e collaborative rendendole anche in grado di supportare al meglio e velocizzare sensibilmente i tempi di ingresso di nuove risorse.

    ticket_aep_case_studies

    Tools utilizzati

    Teamcity (build server)

    Repository Git (Bitbucket)

    Conan (gestore di pacchetti, risolutore dipendenze)

    Nexus (Archivio multiformato)

    Teams mail (comunicazioni)

    Jira (gestione dei task)

    Ansible (strumento di automazione per il deploy)

    #devops

    #infrastructureAsCode

    Image credits

    Affari foto creata da javi_indy – it.freepik.com