1. 6
  1.  

  2. 1

    oddio, questa branching strategy non la conoscevo. Dall’articolo però non si capisce esattamente quali siano i problemi che ha creato.

    1. 1

      mi sa che non sono riuscito a comunicare il disagio che sto provando allora! Devo imparare a splittare le sedute di scrittura, alla fine arrivo sempre cotto e mi perdo i pezzi.

      Quello che succede è che nessuno capisce bene dove andare a sviluppare le proprie feature, non si sa poi dove si devono deployare i branch per farli testare, per non parlare poi dei merge back sulle release precedenti (ieri ci ho messo un pomeriggio intero). Ci sono poi tutti i problemi legati alle librerie interne che usiamo, che seguono un sistema di branching ancora diverso.

      Come dicevo nell’articolo, abbiamo tutte le regole necessarie per aiutarci, in teoria, ma farle assorbire da un team di 15 persone è… impegnativo :)

      1. 1

        sì, in effetti se non hai più un match tra branch ed environment, e immagino non ci sia un’infrastruttura che sa tirar su un environment on-demand per ogni branch, dove testate?

        1. 1

          purtroppo la realtà di Sky è molto complessa su tema testing. Questo perchè interagiamo con molti sistemi diversi (crm vari, middleware vari, cms vari) con anche loro ambienti separati, dati anche in outsourcing. Quindi orchestrare tutta la fase di testing è veramente complesso, non per niente esiste una bella fetta di governance che fa esclusivamente questo.

          Detto ciò, la soluzione a cui siamo arrivati sta un po’ in piedi con il nastro adesivo: ci siamo detti che il testing viene fatto deployando una certa release in un ambiente già pronto in un certo lasso di tempo nel quale tutte le componenti devono avere una versione concordata. Ti lascio immaginare la quantità di bachi dovuti a versioni di sistemi sbagliate :)