1. field 1
1.1. Delivery pipeline (pipeline di consegna/distribuzione)
1.1.1. Sebbene non sia obbligatoria, l'AUTOMAZIONE semplifica il processo ed elimina la possibilità di saltare o manipolare i passaggi garantendo coerenza, prevenendo errori manuali o omissioni durante lo sviluppo e\ndistribuzione
1.1.2. che sia autm.o manuale -> obiettivo = impedire che i bug arrivino a destinazione
1.2. PROTEGGERE IL PROGETTO con Metodologie dei test comuni
1.2.1. TDD Test Driven developm.
1.2.1.1. incentrato su "cosa doverebbe fare il codice"
1.2.1.1.1. LIMITI:
1.2.2. BDD (Beh. driven developm.
1.3. Proteggere il progetto usando UNIT TESTS = STRATEGIA DI TEST COMPLETA (test strategy che comprenda sia comportamenti deiderati che non inderiderati)
1.3.1. fare testing completo è fondamentale per mitigare le vulnerabilità indesiderate
1.3.1.1. Caso studio: ambiente ospedaliero, trasmissione di info sensibili dei pazienti tramite e-mail
1.3.1.1.1. descrizione dello scenario
1.3.1.1.2. sfida (challenge)
1.3.1.1.3. rischi potenziali
1.3.1.1.4. SOLUZIONE:
1.3.1.1.5. Come procediamo nella pratica per rendere sicuro il dominio "EmailAddress" ?
1.3.2. TIPOLOGIE:
1.3.2.1. TESTing su NORMAL BEHAVIOUR (comportamento normale)
1.3.2.1.1. Perchè è preferibile usare questo tipo di testing?
1.3.2.1.2. In pratica nell'esempio:
1.3.2.1.3. Ad esempio, come si fa a sapere se un indirizzo email più lungo di 77 caratteri viene rifiutato o se un indirizzo non può iniziare con un punto? ecco perchè -> altro TIPO DI TESTING: BOUNDARY
1.3.2.2. TESTING su BOUNDARY BEHAVIOUR (comport. al limite)
1.3.2.2.1. perchè si fa questo tipo di test?
1.3.2.2.2. in pratica nell'esempio di EmailAddress
1.3.2.3. TESTING con Input NON VALIDO
1.3.2.3.1. IN SINTESI:
1.3.2.3.2. perchè di fa questo tipo di test?
1.3.2.3.3. A livello di sicurezza
1.3.2.3.4. Nell 'esempio "Email Address"
1.3.2.4. Testing THE EXTREME
1.3.2.4.1. DEFINIZIONE:
1.3.2.4.2. esempio
1.3.2.4.3. Nell'esempio di Email Adderss.. ok
1.4. FEATURE TOGGLES in Software Development
1.4.1. i pro/ a cosa servono
1.4.1.1. - Le migliori pratiche di distribuzione e distribuzione(deployment) continua supportano le F.T. nello sviluppo del software.\n- consente un rapido sviluppo e distribuzione delle funzionalità in modo controllato.\n- strumento efficace ma può diventare complesso se utilizzato eccessivamente
1.4.2. perchè importanza del testing dei f.t.
1.4.2.1. - alterano il comportamento dell'applicazione; quindi, il loro comportamento dovrebbe essere verificato\n\n- test automatizzati sono essenziali per verificare sia il codice funzione che i (toggles) commutatori stessi.
1.4.3. I PERICOLI dei f.t.
1.4.3.1. caso d'esempio
1.4.3.1.1. spiegazione incidente: esposizione di dati sensibili in un'API pubblica. ► I test automatizzati avrebbero potuto impedire l'esposizione di dati sensibili.
1.4.3.1.2. possibili sol. = poss pratiche di sviluppo softw da parte del team (è stata scelta la 2)
1.4.4. Usare FT come tools di sviluppo sw
1.4.4.1. consentono:\n- di attivare/disatt, funzionalità durante sviluppo e testing \n- accesso completo alle nuove funzio. durante svil. & testing.\n- ma si DISATTIVANO in fase di "staginging? o produzione" \n-di controllare quandorendere new funzionalità dispobili agli utenti finali \n\nIMPO: -SUPPORTANO lo sviluppo sui "rami principali" (rispetto sui "rami di funzionalità di lunga durata" \n- si adeguano alle best practices in continuous integration and( continuous )delivery
1.4.4.2. \nNe esistono vari tipi: \n- Alcuni vengono utilizzati per (to toggle feature) attivare/disattivare funzionalità ancora in sviluppo,\n- altri idem ma per a/d funz. in produzione, a seconda dei parametri di runtime come l'ora o la data o di determinati aspetti dell'utente (corrente). \n\n L'implementazione più semplice consist: nel modificare una parte di codiceper includere o escludere determinate parti della codebase (base del codice?)
1.4.4.2.1. Feat. Toggling BY CODE: callOldFunc & callNewFuc.\n
1.4.4.2.2. Feat. Toggli BY CONFIGURATION (+ COMLESSO)
1.4.5. ALTRE COSE DA DIRE SUI TOGGLE soprattutto 4. VERIFICA DEI TOGGLES
1.4.5.1. 1. i HANNO IMPATTO SUL SISTEMA, perchè -> indipende. dal tipo o dal meccanismo alterano il comporamento dell'applicazione\n2. HANNO IMPLICAZIONI PROGETTUALI: perchè sono una "scelta deliberata che consente comportamente 'alternati' " e come altre cose richiedono una verifica tramite test autorizzati \n3. POSSONO AVERE IMPLICAZIONI SULLA SICUREZZA perchè la precisione sull'implementazione è fondamentale per PREVENIRE rischi di sicurezza \n\n4. c'è una NECESSITAì DI VERITICA DEI F.T. \n- possibilmente tramite test automatizzati completi e questi GARANTISCONO funz.lità accurate & identificano potenziali vuln. di sicurezza
1.4.5.1.1. ESEMPI DI METODI PER VERIFICARE I Feature Toggles
1.4.6. "DOMARE I TOGGLES"
1.4.6.1. Utilizzare i ft, introduce complessità: \n [more toggles] => più complessità (soprattutto se i toggle dipendono gli uni dagli atri) \n\nSI DEVE ridurre al minimo il numero (toggles) (quando possibile)\n\nRISCHI: \nLa complessità aumenta la probabilità di commettere errori e, quando si parla di sicurezza, anche un semplice errore può portare a gravi problemi. Ad esempio, l'esposizione di funzionalità non completate in un'API pubblica può portare a una serie di problemi di sicurezza, che vanno dalla perdita economica diretta alla esposizione di dati sensibili.\n\nSUGGERIMENTO :Per ogni (toggle) creato, si crei anche un test per verificare che (il toggle) funzioni come previsto.
1.4.6.2. - i test autm. che verificano i F.T. fungono da rete di sicurezza. cioè = > Garantiscono che i toggles si comportino come previsto e prevengono interruzioni accidentali.\n\n\n• L'esecuzione di ogni build (compilazione) fornisce una verifica continua => questo Agisce come test di regressione, proteggendo così da modifiche involontarie.\n\nESEMPIO INCIDENTE:evidenzia l'importanza dei test automatizzati nella prevenzione degli incidenti. • I test automatizzati avrebbero potuto evitare l'esposizione accidentale degli endpoint API.\n\n\nquindi si dovrebbe: \n\n- Puntare a test automatizzati rispetto a quelli manuali per i F.T.. \n- IMPORTANTE: Riconoscere le eccezioni[Acknowledge exceptions] in cui la verifica automatizzata può essere costosa. perchè: In questi casi => è giusto ricorrere ai test manuali ma anche assicurarsi che siano integrati nella pipeline di distribuzione.\n \n\n• Le fasi di test manuale dovrebbero essere incluse nella pipeline di consegna [in the delivery pipeline ] => in questo modo si riduce il rischio di trascurare (il testing) prima di contrassegnare un prodotto finale come pronto per la produzione.
1.4.7. TEST AUTOMATIZZATI PER FEATURE TOGGLES
1.4.8. ESEMPIO DI OrderService
1.4.9. Affrontare la COMPLESSITA' COMBINATORIA
1.4.9.1. \n1 Impegnarsi per una verifica completa: \n\n• Mirare a verificare tutte le combinazioni di più toggle, soprattutto quelli che si influenzano a vicenda.\n • Testare tutte le combinazioni è fondamentale a causa del \npotenziale accoppiamento indiretto tra i toggles
1.4.9.2. \n2 Complessità dell'accoppiamento indiretto: Indirect Coupling Complexity : \n • L'accoppiamento indiretto può verificarsi durante lo sviluppo. \n• Le sfide combinatorie aumentano con un gran numero di toggles\n \n
1.4.9.3. \n3 Importanza di toggles (limited toggles)"limitati": \n\n• Mantenere basso il numero di toggles è fondamentale (crucial)\n - La maggiore probabilità di errori con un numero maggiore di toggles sottolinea la necessità di test \napprofonditi.
1.4.9.4. 4 . Considerazioni sull'analisi del rischio: risk analy. consideration:\n\n• Argomento contro il test di tutte le combinazioni basato sull'analisi del rischio. [Argument against testing all combinations based on risk analysis.]\n►Presuppone la capacità di valutare difetti di sicurezza sconosciuti,il che è impegnativo.
1.4.9.5. RACCOMANDAZIONE & CONCOUSIONE
1.4.9.5.1. racc.\n• SI suggerisce di verificare tutte le combinazioni di toggles • si sostiene ? (advocates) ridurre la complessità dei toggles nel codebase (nel codice base) per facilitare le testing challenges
1.4.9.5.2. conclus. \n - Una verifica completa è essenziale per i toggles, soprattutto quando ci sono coinvolti più toggles.\n• Dare priorità alla semplicità andando a minimizzare il numero di feature\ntoggles per migliorare l'efficacia dei test [ enhance testing efficacy. ]
1.4.10. Toggle sono soggetti a AUDITING? (verifica)?
1.4.10.1. usare i toggles a runtime => (significa) esporre il meccanismo dei toggles in una maniera sicura \n\n• I toggles modificano il comportamento dell'applicazione in produzione \n• il meccanismo utilizzato per modificare lo stato dei commutatori (togggles) deve essere protetto in modo che sia possibile solo l'accesso autorizzato\n• qualsiasi modifica allo stato di un toggle dovrebbe essere registrata a fini di controllo[should be logged for auditing purposes]\n\nL'uso dei feature toggling sta diventando popolare► Gli sviluppatori considerano i toggles come una parte naturale nello sviluppo del software\n\n • È sempre più importante verificare i toggles in modo automatico e rendere tale verifica parte della pipeline di distribuzione \n• L'utilizzo dei F. T. apporta numerosi vantaggi allo sviluppo del software\n\n"Finché si è consapevoli delle potenziali insidie e di come mitigarle, si ritiene che i benefici superino di gran lunga gli inconvenienti."\n\nIMPORTANTE\nQuando e da chi viene cambiata una levetta (un toggle) nella produzione è una domanda fondamentale a cui si dovrebbe essere in\ngrado di rispondere