Linee guida per sviluppare il proprio sistema di release management per il vostro progetto di metin2, così da organizzare al meglio il processo di sviluppo.
1 Introduzione
Tra le varie cause di fallimento di un progetto di server privato di metin2 c’è sicuramente la scarsa organizzazione dei lavori di sviluppo e configurazione del gameplay che possono sfociare in rallentamenti, maggiori spese e nei casi peggiori anche al fallimento del progetto.
Il mondo informatico fa passi da giganti e uno dei più grandi strumenti che aiuta enormemente lo sviluppo di nuove tecnologie è quello dell'efficienza dei processi di collaborazione e sviluppo dei software. C’è un grande sforzo nella creazione di questi processi utilizzando metodologie sempre migliori e in continua evoluzione.
Perché questa grande attenzione e investimenti in questi processi? La motivazione principale che spinge le aziende ad investire anche in questo aspetto è quello economico, ovviamente
.Un processo ben oliato e specifico può ridurre gli sforzi dei vari dipartimenti IT nello sviluppo e gestione del software, nonché riduce notevolmente la possibilità di avere problemi che impattano il business, senza contare la riduzione dei tempi di risoluzione degli imprevisti.
Esistono ormai diverse metodologie e software a corredo che aiutano nella progettazione e realizzazione del proprio processo di sviluppo, riducendo costi e aumentando la qualità.
In questa guida cercherò di darvi qualche linea guida per permettervi di ideare il processo di sviluppo del vostro server privato di metin2.
2 Metodologia
Per prima cosa conviene scegliere una metodologia già esistente come base, per poi adattarla al nostro caso.
Una tattica che tra le più gettonate e che potrebbe agganciarsi bene al nostro piccolo progetto è quella dell’implementazione della cultura DevOps utilizzando in particolare il metodo CI/CD.
Se implementato correttamente ci permetterà di sviluppare il fix o la feature con un ciclo definito a priori sia in team che singolarmente, aiutando nella tracciabilità delle modifiche e test efficienti per poi applicare tali modifiche in maniera veloce e sicura.
Andando più nello specifico ci serve un sistema di sviluppo, test e installazione continuo.
3 Esempio
Facciamo quindi un esempio pratico di quello che sarà la tipica gestione di un bug:
- Il team di supporto in game (GM, Helper etc.) riceve la segnalazione di un'anomalia e nel riprodurlo conferma che si tratta di un bug nel codice.
- Questa segnalazione viene passata al team di sviluppo (interno, esterno o ibrido) che incomincia a trovare la causa e a sviluppare la fix.
- I progressi vengono tracciati in una branch di sviluppo sul repository GIT del progetto che contiene il codice e le configurazioni del gioco.
- Gli sviluppatori vogliono quindi testare rapidamente quello che hanno modificato sia per aiutare nell’identificazione della parte di codice errata (debugging), sia nel verificare che il problema sia stato effettivamente risolto con quel bugfix. Il sistema di CI/CD si occuperà automaticamente del controllo della qualità del codice (sintassi, best practice ecc. ), della build a partire dal codice (es. compilazione sorgenti) e infine dell’installazione nell’ambiente dedicato (ambiente di sviluppo o “dev”).
- Lo sviluppatore testerà in game nel suo ambiente privato in totale sicurezza e senza disturbi la modifica, se non è contento ripeterà il processo dal punto 3.
- Una volta che il team di sviluppo dichiarerà il bugfix pronto, verrà unito il codice nuovo a quello che poi andrà in live (produzione) che sarà la nuova versione. Questa versione potrebbe contenere altri sviluppi, non solo quel bugfix.
- La nuova versione viene controllata, buildata e deployata automaticamente nell’ambiente di test dedicato.
- Il team adibito ai test, solitamente diverso dagli sviluppatori (GM, Helper, Beta tester) eseguirà delle serie di test sia specifiche per la modifica eseguita, sia generiche per identificare l’eventuale introduzione di nuovi bug (es. per risolvere un bug ne causo altri 3), chiamati test di non regressione (non-regression tests).
- Dichiarato tutto apposto avviene la promozione della nuova versione alla produzione, andando quindi ad installare il codice finale nell’ambiente di produzione automaticamente dove è possibile, seguendo il relativo piano di manutenzione (es. avviso all’utenza del riavvio in data e ora prestabilita).
- Ulteriore check post deploy per verificare che tutto sia in ordine e ripresa della normale operatività. Qualora si identifica un problema si decide se eseguire un rollback reinstallando la versione precedentemente oppure si ripete il processo dal punto 1 come un nuovo problema.
Lo stesso ciclo è valido anche per l’implementazione di una nuova funzionalità.
4 Strumenti
Come anticipato, il mercato ci offre tanti strumenti per poter applicare al meglio il nostro processo senza dover sviluppare tool specifici.
Un’ottima suite che potrebbe essere la vostra base è Gitlab.
Questa piattaforma web vi permette di versionare e condividere con il vostro team e collaboratori il codice e le configurazioni del vostro progetto tramite GIT, con la comodità di una web UI, gestione accessi e permessi, tracking issue, motore CI/CD tutto in un unico prodotto che potrete installare sui vostri sistemi o utilizzando la versione cloud, gratis.
Per sfruttare il tutto al meglio si può sfruttare un qualunque public cloud provider, come OVH, con la possibilità di creare, modificare, stoppare e distruggere istanze automaticamente, utilizzando le nostre pipeline CI/CD con Gitlab. Inoltre potremo usare servizi con fatturazione oraria, così da pagare solo per il reale utilizzo delle nostre istanze di test o dev, che non necessitano di una disponibilità 7x24 e quindi avere un netto risparmio.
Inoltre è utile versionare anche le configurazioni dei nostri sistemi così da avere tutto sotto controllo ma anche ricreare i nostri ambienti da 0 in pochi istanti senza doverci ricordare di quello che abbiamo fatto prima. Questo ha anche il vantaggio di installare un ambiente funzionante a causa di qualche problema con il precedente ambiente di produzione. Ad esempio se succede un imprevisto nel nostro ambiente di produzione come l’indisponibilità di un datacenter o qualche modifica errata ai sistemi è possibile ricreare l'intero ambiente da 0 in pochi istanti tutto automaticamente.
Questo lo potremmo fare sempre grazie a Gitlab aggiungendo anche un sistema di configuration management come Ansible
5 Git strategy
Abbiamo detto che il nostro codice, nonché le configurazioni del game e dei sistemi verranno tracciate tramite GIT. E’ importante quindi definire alcune regole per utilizzare al meglio le potenzialità di questo strumento.
Lo scopo è quello di avere un metodo comune a tutto il team, in particolare sviluppatori e managers, per le varie fasi di sviluppo e versionamento, così da avere meglio sotto controllo i progressi e le modifiche apportate o che vogliamo apportare. Inoltre ci permetterà di identificare meglio la causa di problemi lato codice ed eventualmente correggerle o semplicemente ripristinare una vecchia versione in pochi istanti.
Ecco un esempio di git workflow:
Ogni riga corrisponde a un branch. In dettaglio abbiamo:
- Main: Corrisponde al codice attualmente in produzione. La nostra sorgente di verità, con il game testato e funzionante.
- Test: Questo è il codice in fase di test approfonditi da parte del team preposto. Esso contiene le feature e fix dichiarati pronti dagli sviluppatori.
- Feature: Quando il progetto ha bisogno di aggiungere nuove funzionalità (implementazioni) si dovrà aprire un branch di sviluppo dedicato a quella specifica issue. La feature verrà testata con ripetuti deploy nell'ambiente di sviluppo da parte degli stessi sviluppatori. Una volta che gli sviluppi vengono dichiarati completati si procederà ad eseguire una merge nella branch di test per i test più approfonditi assieme alle altre eventuali feature prima di andare in produzione.
- Bugfix: il processo è uguale alle feature, con la differenza che il codice contiene una correzione ad un bug.
- Hotfix: vengono considerate hotfix dei fix per bug particolarmente urgenti che devono andare al più presto in produzione. Appena il fix è pronto e testato in ambiente di dev, si procede all’installazione della singola fix, indipendentemente da eventuali altri lavori in corso come bugfix e feature.
E’ buona norma creare un tag per identificare una specifica versione del nostro progetto, così da semplificare eventuali installazioni di vecchie versioni o semplicemente visualizzare il codice di una vecchia versione.
Un’altra cosa che può aiutare nel tracciamento dei lavori e collaborazione tra più persone sono le issue. Funziona come un ticket in una piattaforma di supporto, dove descrivi il bug o la feature e gli sviluppatori partiranno da lì a tracciare le modifiche e progressi, per poi chiudersi alla fine del processo.
6 Pipeline
Con pipeline CI/CD si intende una serie di step, detti job, ordinati dipendenti tra loro con finalità comune.
Un esempio classico di pipeline è la build, delivery e deploy su un ambiente dei file game dopo una modifica.
Di seguito degli esempi di pipeline per gli ambienti di sviluppo (dev), test e produzione (prod)
Partiamo dalla pipeline che viene eseguita per lo sviluppatore a seguito di una modifica del codice su repository git in una branch dedicata.
Lo scopo è quello di controllare il codice, buildarlo, preparare il server per i test e infine installare la versione temporanea del game, così da permettere allo sviluppatore di testare il proprio lavoro in un ambiente pulito e dedicato a lui. Finiti i test è sufficiente lanciare la procedura di spegnimento e distruzione dell’ambiente di sviluppo temporaneo, così da pagare solo per il reale tempo dei test. Inoltre sarà possibile creare più ambienti di sviluppo nel caso in cui si stia lavorando a più modifiche contemporaneamente.
Per quanto riguarda l’ambiente di test dove testare l’insieme delle modifiche che andranno a formare la nuova versione e dare l’accesso al team preposto per i test più approfonditi, la pipeline è molto simile. In questo caso, sempre tramite git, si unirà (merge) le varie modifiche sviluppate e testate dagli sviluppatori nel branch di test preposto e da lì si eseguirà la pipeline che controllerà il nuovo codice nel suo insieme e installerà, configurerà e applicherà il nuovo codice sulle nuove istanze di test che compongono l’ambiente di test, così da permettere al team di testare in un ambiente preposto e con tranquillità la nuova versione. Una volta che tutto sarà verificato e approvato si potrà distruggere l’ambiente di test.
Ora che la nuova versione del game è pronta e ben testata si può pianificare la finestra di manutenzione per applicare la nuova versione, sempre in automatico. Con questo sistema il processo di aggiornamento sarà molto più veloce, per cui la finestra di manutenzione sarà di pochi minuti.
Anche qua andrebbe inserito lo step di creazione delle istanze per l’ambiente di produzione in maniera automatica, così da avere lo stesso metodo per gli altri ambienti. Il vantaggio principale è la stessa configurazione e caratteristiche degli ambienti precedenti, così da non avere differenze in termini di sistema e infrastruttura che potrebbero invalidare i test.
