Questo articolo è disponibile anche in:
Questo articolo è tradotto usando un traduttore automatico. Potrebbe contenere alcuni errori o traduzioni che suonano strane. Pensiamo lo stesso che possa esserti utile leggere questo articolo nella tua lingua madre. Facci sapere se ti è stato di aiuto, o facci avere il tuo feedback, in fondo all'articolo.

Distinguiamo tre tipi di cambiamenti: bug, caratteristiche e modifiche all'infrastruttura o alla manutenzione del sistema. La fase iniziale è diversa per ogni cambiamento, ma condividono tutti lo stesso processo di sviluppo, test e distribuzione.

Bug segnalati dai clienti.
Ogni volta che un bug viene segnalato al nostro servizio clienti, quel bug viene segnalato al nostro service desk interno. Dal service desk interno il bug viene convalidato dal team QA. I bug validi vengono poi escalati 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 sono selezionate per lo sviluppo sono scritte in criteri di accettazione dal product manager. Prima che la caratteristica sia implementata, viene discussa e rifinita 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.
I cambiamenti nell'infrastruttura/sistema sono necessari per migliorare il nostro prodotto o i processi di lavoro.

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

Processo di sviluppo
Il processo ha le seguenti fasi:

Discussione: I criteri di accettazione sono scritti/migliorati per il cambiamento previsto. Questo assicura che tutti coloro che stanno lavorando sulla caratteristica/modifica sappiano qual è il risultato finale previsto. Puntiamo a fare molti piccoli miglioramenti rispetto ai grandi cambiamenti.
Sviluppo: almeno due sviluppatori lavorano sul codice. Usiamo lo sviluppo guidato dai test. Testiamo il nostro codice con test automatici di unità, integrazione, funzionali e di accettazione. Tutti i test nuovi ed esistenti devono essere superati prima di passare alla fase di revisione del codice.
Revisione del codice: tutte le modifiche sono riviste da almeno un altro sviluppatore che non ha lavorato sul codice. Qui verifichiamo se il codice è conforme agli standard. Usiamo l'OWASP top102 per controllare le vulnerabilità. Il cambiamento non può passare alla fase successiva fino a quando tutti i feedback sono risolti e tutte le modifiche al codice sono state riesaminate.
Garanzia di qualità: Le modifiche sono testate dal team QA. Se i cambiamenti 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:
Mettiamo l'ultima versione di sviluppo sul nostro ambiente di staging per i test.
Eseguiamo il test di accettazione sull'intera applicazione.
Se tutto passa, distribuiamo tutte le modifiche in 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 OWASP top10 è una lista delle vulnerabilità più comuni. Un elenco può essere trovato sul sito web di OWASP: https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project||
È stato utile questo articolo?
Annulla
Grazie!