Questo articolo è disponibile anche in:
Distinguiamo tre tipi di modifiche: bug, caratteristiche e modifiche alle infrastrutture o alla manutenzione del sistema. La fase iniziale è diversa per ogni modifica, ma condividono tutti lo stesso processo di sviluppo, test e distribuzione.

I clienti hanno segnalato bug
Ogni volta che un bug viene segnalato al nostro servizio clienti, quel bug viene segnalato nel nostro service desk interno. Dal service desk interno il bug viene convalidato dal team di QA. I bug validi vengono poi portati al nostro team devsupport1 che gestisce i bug. Da quel momento in poi, seguono lo stesso processo di sviluppo delle nuove funzionalità.

Caratteristiche
Le caratteristiche della road map che vengono selezionate per lo sviluppo sono scritte nei criteri di accettazione dal product manager. Prima che la funzione venga implementata, la funzione viene discussa e perfezionata da tutti i team coinvolti.

Manutenzione dell'infrastruttura e/o del sistema
Ci sono diverse ragioni che causano un cambiamento nella nostra infrastruttura/sistema.

Ci sono aggiornamenti di sicurezza per software di terze parti da cui dipende il nostro prodotto.
Ci sono nuove versioni per software di terze parti da cui dipende il nostro prodotto.
Sono necessari cambiamenti nell'infrastruttura/sistema per migliorare il nostro prodotto o i processi di lavoro.

Questi cambiamenti che vengono selezionati per lo sviluppo vengono poi discussi e poi implementati dal nostro team di sviluppo, allo stesso modo in cui vengono fatte le caratteristiche. Data la nostra politica di sviluppo sicuro, diamo priorità agli aggiornamenti di sicurezza.

Processo di sviluppo
Il processo ha le seguenti fasi:

Discussione: I criteri di accettazione sono stati scritti/migliorati per la modifica prevista. Questo assicura che tutti coloro che stanno lavorando sulla caratteristica/modifica sappiano quale sia il risultato finale previsto. Il nostro obiettivo è quello di apportare molti piccoli miglioramenti rispetto ai grandi cambiamenti.
Sviluppo: almeno due sviluppatori lavorano sul codice. Utilizziamo lo sviluppo guidato da test. Testiamo il nostro codice con test automatizzati di unità, integrazione, funzionali e di accettazione. Tutti i test nuovi e quelli esistenti devono essere superati prima di passare alla fase di revisione del codice.
Revisione del codice: tutti i cambiamenti sono rivisti da almeno un altro sviluppatore che non ha lavorato sul codice. Qui si verifica se il codice è all'altezza degli standard. Utilizziamo la OWASP top102 per verificare la presenza di vulnerabilità. La modifica non può passare alla fase successiva fino a quando tutti i feedback non sono stati risolti e tutte le modifiche al codice sono state riesaminate.
Garanzia di qualità: Le modifiche sono testate dal team QA. Se le modifiche non soddisfano i criteri di accettazione, gli standard di accessibilità o hanno altri problemi, l'intero processo ritorna alla fase di sviluppo.
Fusione: Tutte le modifiche vengono fuse nella versione di sviluppo del nostro prodotto.
Rilascio: Rilasciamo una nuova versione del nostro software ogni giorno:
1. Mettiamo l'ultima versione di sviluppo nel nostro ambiente di staging per i test.
2. Eseguiamo il test di accettazione su tutta l'applicazione.
3. Se tutto passa, implementiamo tutte le modifiche alla produzione.

Note
Il team di devsupport è un team di sviluppatori che aiuta con il supporto del nostro prodotto. La maggior parte dei nostri bug sono risolti da questo team.
La top10 di OWASP è una lista delle vulnerabilità più comuni. Una lista può essere trovata sul sito web di OWASP: https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project|||
È stato utile questo articolo?
Annulla
Grazie!