Best Practices Rilascio

di
TheRT0C
il
6 risposte
TheRT0C
TheRT0C
Utente Attivo
Iscritto da
mag, 2020
Messaggi:
101

Best Practices Rilascio

Ciao a tutti,
esistono libri o guide per un buon rilascio? (credo di si, quindi più che altro, potete consigliarmi)

Visto che lavoro su una DateWarehouse, conoscete qualche modo per rendere i test di post rilascio automatizzati?
mi scoccia ogni mattina aprire Bq e lanciare la query per non trovare duplicati o controllare le performance dei flussi su oracle.
Excellone con le query o avevo pensato ad un flusso DD post flusso di prod, che fa i suoi check e a condizione negativa, manda sms/email.

Must have da leggere nel campo dei Database? vorrei crescere e dare un contributo al progetto in modo sostanzioso.
Ad esempio non mi piacciono come sono organizzati gli ambienti di dev e test, sono totalmente inutili, in quanto alla fine ci vedi solo se lo script sql non si rompe. Per me dovrebbero essere ambienti di totale integrazione alla fase di Test, ok vedere se lo script non si rompe ma anche capire se le strutture sono allineati tra prima e post modifica.

6 Risposte

  • +
    +m2+
    Utente Famoso
    Iscritto da
    mag, 2017
    Messaggi:
    3548

    Re: Best Practices Rilascio

    Per quanto mi riguarda programmone (delphi) che fa tante belle cose su una macchina virtuale in cui ripristino il dump mysql (in realtà la copia mariadb dei dati ma vabbè) preso dalla macchina replica (lo slave) per non caricare il master.

    Nota di colore (!)
    Tra l'altro sta entrando la correttezza anche nell'informatica, master e slave sono ormai deprecatissimi perchè contro... le persone di colore.
    Vabbè
  • TheRT0C
    TheRT0C
    Utente Attivo
    Iscritto da
    mag, 2020
    Messaggi:
    101

    Re: Best Practices Rilascio

    +m2+ ha scritto:

    Per quanto mi riguarda programmone (delphi) che fa tante belle cose su una macchina virtuale in cui ripristino il dump mysql (in realtà la copia mariadb dei dati ma vabbè) preso dalla macchina replica (lo slave) per non caricare il master.

    Nota di colore (!)
    Tra l'altro sta entrando la correttezza anche nell'informatica, master e slave sono ormai deprecatissimi perchè contro... le persone di colore.
    Vabbè

    Un punto che ho proprio dimenticato è quello dei dati sensibili, se non posso spostare i dati da prod, come testo n tabelle modificate x n tabelle target? Criptarli n column su n rows? la create su BQ muore dopo 40 minuti.
    Per una questione di performance, ha senso clusterizzare tutte le tabelle o almeno quelle che hanno parecchie logiche?
  • +
    +m2+
    Utente Famoso
    Iscritto da
    mag, 2017
    Messaggi:
    3548

    Re: Best Practices Rilascio

    Clusterizzare le tabelle?
    Criptarle?
  • TheRT0C
    TheRT0C
    Utente Attivo
    Iscritto da
    mag, 2020
    Messaggi:
    101

    Re: Best Practices Rilascio

    Per recuperare qualche secondo da una create, ho visto che hanno aggiunto su BQ Cluster By. Se andassi di coppia su due campi(non a caso naturalmente, colonne che hanno 3-4 valorizzazioni) , dovrei recuperare un po' di tempo e anche di spazio.

    Si encrypt di tutte le colonne di una tabella, ma ha il problema della complessità, non penso giri una query con 15 campi. Potrei al massimo farlo per i dati più sensibili, ma é una buona pratica?

    Come ci lavori con dei dati sensibili se non puoi esportarli fuori dall'ambiente di prod? che poi effettivamente fare delle viste di target con campi crypt e from tabelle su cui testare, tanto senso non ha.
  • +
    +m2+
    Utente Famoso
    Iscritto da
    mag, 2017
    Messaggi:
    3548

    Re: Best Practices Rilascio

    Mah una create che ti frega mica la fai spesso.
    il problema della crittografia è la specifica della password.
    Cripti tutto, e magari la passi in chiaro da uno script
    Sull'ultima frase ti sei autorisposto
  • TheRT0C
    TheRT0C
    Utente Attivo
    Iscritto da
    mag, 2020
    Messaggi:
    101

    Re: Best Practices Rilascio

    +m2+ ha scritto:

    Mah una create che ti frega mica la fai spesso.
    il problema della crittografia è la specifica della password.
    Cripti tutto, e magari la passi in chiaro da uno script
    Sull'ultima frase ti sei autorisposto
    In realtà sono create/replace che fanno all data tutti i giorni. Insomma uno schi**, altrimenti si partizionava per current date risolvendo la questione performance. Se avessi 180 strutture giornaliere dipendenti tra di loro, é un problema come soluzione.
    Per le performance magari una soluzione potrebbe essere quella di affiancargli un nosql, in realtà sto pensando a che pro. Un malus é la spesa sicuramente.



    Ma si, portare tutti i campi in crypt é una brutta soluzione, cioè non avendo altre esperienze, di solito i dati del cliente si lavorano in chiaro, anche in ambiente non di prod? quindi diciamo l'azienda vive sempre sul filo del rasoio
Devi accedere o registrarti per scrivere nel forum
6 risposte