sfondo

Sto lavorando in un team che sta cercando di implementare distribuzioni a zero-downtime. Stiamo programmando di utilizzare una strategia di distribuzione blu / verde per raggiungere questo obiettivo. Una delle cose che sto realizzando nel fare la ricerca è quanto sia complicato apportare modifiche al database. Una semplice operazione come rinominare una colonna può richiedere 3 cicli di rilascio completi fino al completamento!

Mi sembra che avere il pieno lancio di una modifica richieda più cicli di rilascio introduce un grande potenziale di errore umano. Nell'articolo collegato mostra che sono necessarie modifiche al codice per 2 versioni e una migrazione al database per 3 versioni.

Quello che sto cercando

Attualmente, se vogliamo ricordare di fare qualcosa, possiamo creare un ticket nel nostro sistema di gestione dei problemi, che crea disordine e potrebbe anche essere spostato in uno sprint successivo o nel backlog dalla direzione; oppure possiamo creare un commento TODO, che probabilmente sarà completamente dimenticato.

Quello che sto cercando è un modo in cui un commento TODO può avere una scadenza contro di esso, e il nostro sistema di integrazione continua (attualmente indeciso che useremo) rifiuterebbe la build se questa scadenza fosse scaduta.

Ad esempio, se rinominiamo una colonna, potremmo creare la migrazione iniziale per essa, quindi due commenti TODO per garantire che vengano create le restanti due migrazioni:

// TODO by v55: Create migration to move constraints to new column, remove references to old column in app
// TODO by v56: Create migration to drop old column

Sembra abbastanza semplice da implementare, ma mi chiedo se esiste già qualcosa del genere, perché non voglio reinventare la ruota.

Pensieri aggiuntivi

Mi sento come se potessi soffrire di problemi XY qui, dato che le distribuzioni in rotazione e le distribuzioni blu / verde sono considerate una buona pratica, sembra strano che non riesca a trovare una soluzione per rendere gli aggiornamenti del database meno dolorosi. Se pensi che sto esaminando completamente la cosa sbagliata, per favore fammi sapere in un commento! Detto questo, l'esempio di database che ho fornito è solo un esempio e penso che i commenti TODO con scadenze sarebbero utili anche in altre situazioni, quindi anche se mi sto avvicinando a questa situazione specifica, mi piacerebbe davvero rispondere alle mie domanda reale anche. Grazie!

EDIT: ho appena pensato a un'altra situazione in cui questo potrebbe essere utile. Se usi Toggle Feature per attivare parti dell'app quando sono pronte, devi fare attenzione a ripulirle, altrimenti potresti finire con Toggle Debt . I commenti con scadenze potrebbero essere un buon modo per ricordare questo.

Questa domanda è davvero due domande in una.

Commenta Todo

Di tutti i modi per tenere traccia degli oggetti d'azione, questo è il peggiore. I commenti di TODO sono utili durante il lavoro attivo o come suggerimento per un manutentore, "ecco qualcosa che potrebbe essere migliorato in futuro". Ma se fai affidamento sui commenti TODO per portare a termine il lavoro, sei destinato a fallire.

Cosa fare al riguardo

I commenti TODO sono fondamentalmente debiti tecnici, quindi dovrebbero essere gestiti come qualsiasi altro debito tecnico. Affrontali subito, se hai tempo, o mettili nel backlog in modo che possano essere monitorati e prioritari.

In generale, e questo è totalmente supponente e aperto al dibattito, i commenti TODO potrebbero essere considerati un odore di codice. Se un commento su TODO arriva al punto di essere controllato nel controllo della versione, devi chiederti, lo farai davvero in questo momento? In caso contrario, va bene. Sii onesto con te stesso e mettilo nel backlog.

Il modo in cui gestite questo arretrato dipende dal processo aziendale, dalla politica aziendale e forse da una certa autonomia personale. Ma hai ancora bisogno di un backlog monitorato e prioritario per assicurarti che accada.

Modifiche al database

Sì, le modifiche al database sono complicate con una politica di downtime zero. Alcuni trucchi per contribuire a renderlo meno doloroso:

Processo post-distribuzione

Creare un processo post-distribuzione che viene eseguito come parte della stessa versione. Comunque tu voglia che funzioni. Sull'ultimo sistema su cui ho lavorato, ho progettato una distribuzione in 4 fasi:

1. script di database preapp
2. app web
3. script di database postapp
4. script del database delle finestre di manutenzione

L'idea era che, ove possibile, avremmo messo in preapp il maggior numero possibile di modifiche al database.

Postapp era riservato ai casi insoliti in cui dovevamo apportare modifiche allo schema incompatibili. In questi casi, preapp avrebbe apportato abbastanza modifiche per rendere compatibile il nuovo codice dell'applicazione (magari creando una vista temporanea per la compatibilità) e postapp avrebbe ripulito tali artefatti temporanei.

La fase della finestra di manutenzione era riservata alle modifiche che richiedevano veramente tempi di inattività o in cui il rischio o il costo di una distribuzione live non valeva la pena. Ad esempio, gli script che modificano enormi quantità di dati potrebbero dover bloccare un'intera tabella.

Distribuire frequentemente

Se si distribuiscono nuove versioni abbastanza frequentemente, è possibile raggiungere un punto in cui portare una modifica tra 2 o 3 versioni è banale. Cicli di rilascio lunghi amplificano il costo delle modifiche al database.

Non utilizzare TODO. Hai già un elenco TODO nel tuo progetto. Si chiama tracker dei problemi.

Penso che il vero problema sia in questa frase:

possiamo creare un ticket nel nostro sistema di gestione dei problemi, che crea disordine e potrebbe anche essere spostato in uno sprint successivo o nel backlog dalla direzione.

Se il tracker dei problemi crea molta confusione, trova il modo di risolverlo. Forse un tipo / tag di problema speciale che comporta meno cerimonia. Forse sotto-problemi. Forse meno cerimonia del tutto. Non possiamo davvero dirlo. Ma se il tracker dei problemi crea così tanto lavoro, che le persone preferiscono formulare una domanda elaborata su un forum pubblico piuttosto che aggiungere semplicemente quel problema, qualcosa è seriamente sbagliato.

Se la tua gestione ritarda indebitamente l'ultima parte di un'attività hai due opzioni:

1. parla con il tuo management perché questa è una cattiva idea.

2. gestirlo come una singola attività. Questa potrebbe essere la soluzione standard di riferimento. In un mondo perfetto dovresti essere in grado di apportare le tre modifiche necessarie in ogni passaggio. Applicane uno al ramo principale, lascialo compilare e distribuire. Nel frattempo applica il secondo al ramo principale, lascialo compilare e distribuire e così via in modo che tutto accada nello stesso sprint e, in caso contrario, non è fatto. Forse anche qualcosa di automatico ha senso dove logicamente fai una distribuzione, ma in realtà è divisa in 3.

Quello che sto cercando è un modo in cui un commento TODO può avere una scadenza contro di esso, e il nostro sistema di integrazione continua (attualmente indeciso che useremo) rifiuterebbe la build se questa scadenza fosse scaduta.

Ciò che chiedi è fattibile se sei disposto a fare il lavoro e seguirlo.

// TODO by v55: crea la migrazione per spostare i vincoli in una nuova colonna, rimuovi i riferimenti alla vecchia colonna nell'app // TODO by v56: crea la migrazione per eliminare la vecchia colonna

grep per //TODO by v55quando è il momento di distribuire v55. Deploy build esegue uno script che lo fa come test di integrazione.

Puoi collegare 55 al monitoraggio della versione o semplicemente richiederlo.

Diventa interessante se vuoi controllare // TODO entro la v54 quando fai 55. Piuttosto allora cerca nella base di codice 55 volte cerca solo // TODO per. Quindi filtrare quel risultato da 1 a 55. Ora 56 non attiverà un errore.

Potresti pensare "oh non ne avremo bisogno. Ripareremo questi ogni volta finché avremo il controllo". No. No, non lo farai.

Abbiamo avuto un problema molto simile nel nostro team. Per risolvere questo, abbiamo scritto un controllo di analisi statica che gestisce questi TODO controllando il problema JIRA o Git Issue a cui fanno riferimento. La nostra build fallisce quando il problema specificato passa oltre la colonna "In sviluppo".

Pertanto possiamo comodamente avere TODO senza preoccuparci che vengano dimenticati.

Ho creato un'implementazione open source di questo, in Java. Sì, una dichiarazione di non responsabilità è che ho scritto questo, ma come ho detto, è completamente open source e concesso in licenza.

Lo strumento si chiama Westie e un esempio della verifica dei problemi di Jira è su README.md. Vedi anche GitIssueAnalyser.

Per evitare l'autopromozione se hai ulteriori domande, inviami un messaggio. Se decidi di usarlo e hai qualche suggerimento, ti preghiamo di sollevare problemi su github.

Non fare. Fallo ora.

TLDR: scrivere (e testare) gli script DB ora, non più tardi; basta codificarli in modo che la loro esecuzione dipenda dalla versione DB.

Esempio

Per un esempio, immaginiamo che desideri cambiare il nome di una colonna da SSNa TaxID, un requisito comune quando si diventa internazionali.

Per far sì che ciò accada, forse avrai temporaneamente sia una TaxIDche una SSNcolonna. E pur supportando entrambe le versioni, avrai un trigger per aggiornare l'una dall'altra. Ma non vuoi mantenere quel grilletto all'infinito, quindi più tardi, quando la compatibilità con le versioni precedenti non è più necessaria, vuoi che il grilletto venga rimosso (e la SSNcolonna rilasciata). Codificheremo tutto ciò in anticipo senza la necessità di articoli ToDo.

Nel nostro esempio, distribuiremo la build 102 (che ha la nuova colonna) mantenendo la compatibilità con la build 101 (che non ha).

Ecco i passaggi.

1. Configurare la tabella delle versioni

1. Aggiungi una singola tabella chiamata Configurationcon due colonne Namee Value.

2. Aggiungi una riga con Name"TargetVersion" e imposta Valuela versione della nuova build da distribuire.

3. Aggiungi una riga con a Namedi "CompatibleWith" e imposta il Valuenumero di versione minimo con cui la distribuzione deve essere compatibile.

Ispezionare e aggiornare queste righe prima di ogni distribuzione.

2. Modifica gli script di distribuzione

1. Aggiungi uno script che crea una nuova colonna di TaxIDfianco a fianco SSNe la popola dalla SSNcolonna. Racchiudere questo codice in Ifun'istruzione che controlla TargetVersion; se la versione di destinazione è troppo bassa (ovvero TaxIDnon è ancora necessaria), salta.

   SELECT @TargetVersion = TargetVersion FROM Configuration
   IF @TargetVersion < '102' THEN RETURN
   ALTER TABLE Customer ADD COLUMN taxID VarChar(12) NOT NULL
   UPDATE Customer SET TaxID = SSN
   

2. Aggiungi uno script che crea un trigger che viene popolato TaxIDdurante l'inserimento o l'aggiornamento SSNe viceversa. Racchiudere questo codice in Ifun'istruzione che controlla la versione di destinazione e la versione compatibile; salta se TargetVersion è troppo basso ( TaxIDnon è necessario) o se la versione CompatibleWith è troppo alta (il SSNcampo non è necessario).

   SELECT @TargetVersion  = TargetVersion,
          @CompatibleWith = CompatibleWith 
   FROM Configuration
   IF @TargetVersion  < '102' THEN RETURN
   IF @CompatibleWith > '101' THEN RETURN
   CREATE TRIGGER SSNAndTaxIDTrigger ON Customer etc.
   

3. Aggiungi uno script per rimuovere la SSNcolonna. Racchiudere in Ifun'istruzione che rimuove la colonna solo se la versione di CompatibleWith è sufficientemente alta ( SSNnon è più necessaria).

   SELECT @CompatibleWith = CompatibleWith FROM Configuration
   IF @CompatibleWith <= '101' THEN RETURN
   IF OBJECT_ID('SSNAndTaxIDTrigger') IS NOT NULL DROP TRIGGER SSNAndTaxIDTrigger
   IF EXISTS (SELECT * FROM syscolumns c JOIN sysobject o ON o.id = c.is WHERE o.Name = 'Custeomr' AND c.Name = 'SSN') BEGIN
       ALTER TABLE Customer DROP COLUMN SSN
   END
   

3. Test

Assicurati di testare la tua distribuzione con qualsiasi combinazione di numeri di versione Blu / Verde che desideri supportare nella produzione. Puoi testare non appena il codice è pronto, manipolando la Configurationtabella nel tuo ambiente QA.

4. Nel tuo playbook di distribuzione

Aggiungi un passaggio per un tecnico per aggiornare la versione CompatibleWith e le righe TargetVersion. Se si sta eseguendo la distribuzione su Blue, impostare TargetVersion sul numero di versione di Blue e la versione Compatibile con il numero di versione di Green; invertirli se stai distribuendo Green.

insidie

È corretto che gli script di distribuzione facciano riferimento e facciano affidamento su quei numeri di versione contenuti nella tabella DB. NON codice di runtime.

Se inizi a scrivere il tuo codice di runtime per ispezionare i numeri di versione, stai introducendo un nuovo livello di complessità nella tua applicazione che potrebbe potenzialmente diventare un enorme problema di manutenibilità. Ogni percorso di esecuzione del runtime deve essere testato; se porti avanti queste condizioni in futuro, il QA dovrà mettere insieme una matrice di dolore per convalidarle con ogni singolo rilascio. Il mio consiglio è di mantenere condizioni come queste solo negli script di distribuzione.

Il risultato di tutto questo

Alla fine, dovresti essere in grado di scrivere tutto il codice in anticipo (e testarlo anche) senza timore che verrà eseguito troppo presto. Inoltre, il codice pulirà il trigger di compatibilità con le versioni precedenti quando arriva il momento senza che tu debba preoccuparti ulteriormente.

In questo modo puoi scrivere e testare tutto il codice in anticipo, quando ci stai pensando, e non hai bisogno di occuparti di quei commenti disordinati.

Stai ricevendo un sacco di respingimenti sulla tua idea di TODO, ma personalmente non vedo alcun problema. Alla fine, il modo migliore (e più semplice) per assicurarsi che la migrazione entri in produzione è fallire un test unitario se non lo fa. Ci vorrà letteralmente meno di un minuto per spegnere una funzione di migrazione vuota che genera un'eccezione se la versione è 55 o più (o qualunque siano i requisiti).

Quindi se provi a rilasciarlo, finirai con un test fallito e qualcuno dovrà trasformare quell'eccezione in un vero codice di migrazione.

Nessuno sembra concentrarsi sulla radice della sua lamentela, ovvero il fatto che le modifiche al database possono richiedere troppi cicli di rilascio. Vuole proseguire con il suo programma di distribuzione blu / verde e la soluzione dovrebbe già essere lì, ma a meno che non mi manchi qualcosa la sua descrizione sembra indicare che esiste un solo database condiviso da entrambi i sistemi. Non è un vero sistema blu / verde se questo è il caso. Dal momento che sembra che il database sia il polo lungo nella tenda, dovrebbe essere duplicato anche in modo tale che, indipendentemente dal tempo o dal numero di cicli di rilascio necessari per implementare le modifiche al database sul sistema offline, non diventano attive fino al completamento e completamente testato. Nel frattempo gli script di sistema offline possono mantenere il database offline completamente aggiornato quotidianamente.