Quali passi posso fare per assicurarmi di integrare con successo nuove funzionalità a un'app esistente?

1

Potrei potenzialmente avere del lavoro per implementare nuove funzionalità per l'applicazione web esistente di un cliente. (Non ho scritto l'app originale).

Non ho mai creato un'app che non sia stata scritta da zero e sono preoccupata di integrare le nuove funzionalità senza interrompere il servizio troppo a lungo (o affatto).

Non penso che il client abbia impostato un repository di codice esistente.

Stavo pensando che il mio processo di sviluppo dovrebbe seguire il seguente percorso:

  • Crea un repository SVN e memorizza tutto il codice corrente, includendo (o rendendoli se necessario) i file SQL che sarebbero necessari per creare la struttura attuale del database.
  • Ottieni l'app del client funzionante come su un server di prova con dati fittizi nel database del server di test.
  • Lavora il più possibile in cicli per scrivere il codice per una funzione alla volta e poi esegui la migrazione sull'app live. Questo è il punto su cui sono più insicuro. Ci sarà un breve periodo di tempo in cui caricherò alcuni nuovi file e gli utenti probabilmente avranno problemi di usabilità (arresti anomali). Devo solo visualizzare una pagina "working on the server" mentre sto facendo questo? Come potrei farlo?
  • Inoltre, mi sembra che aggiungere una funzione alla volta possa causare problemi, perché alcuni di loro si aspettano che altre funzioni siano lì per funzionare correttamente. Suppongo che la risposta a questo è solo aggiungere una raccolta di funzionalità che possono essere considerate come un modulo autonomo.
  • Ovviamente testerei il nuovo codice al massimo prima di eseguirne la migrazione.

Sarei grato per eventuali suggerimenti o trucchi o commenti su ciò che ho scritto sopra. Voglio davvero che tutto funzioni senza problemi per il mio cliente (e per me!)

Saluti

    
posta Joe 21.07.2011 - 14:54
fonte

2 risposte

4

Il tuo flusso di lavoro di base sembra completamente sensato. Ottenendo in particolare il codice sotto controllo di revisione e assicurandoti di poter ricreare l'app e il database da quella fonte.

Suggerirei di non aggiornare il sito live mentre è in esecuzione. A seconda di come funziona il sito probabilmente hai altre due opzioni;

  1. Imposta una nuova versione del sito su un indirizzo IP diverso e migra il DNS dopo aver verificato che funzioni. Funziona solo se non ci sono contenuti dinamici creati dall'utente, es. se il database non cambia a seguito di azioni dell'utente o se è possibile disabilitare temporaneamente tali azioni. Questo può funzionare bene per riprogettazioni complete o siti statici in quanto consente al client di avere un gioco con il sito Web e anche beta test con un piccolo gruppo prima del lancio. È probabile che tu faccia schifo con qualsiasi sito web guidato dall'utente, a meno che tu non possa lasciare lo schema del database invariato.

  2. Porta il sito offline brevemente durante l'aggiornamento. Generalmente configurerei un sito di manutenzione come un sito separato e poi contemporaneamente abbattere il sito principale e far apparire il sito di manutenzione sullo stesso dominio. È quindi possibile richiamare il nuovo sito Web su un altro IP o porta e testarlo sul server di produzione. Una volta che sei soddisfatto, puoi rimuovere il sito di manutenzione e ripristinare il sito di produzione.

Se si desidera minimizzare l'interruzione, è possibile determinare facilmente dai registri del server quando è il momento meno dannoso per farlo. Ovviamente questo potrebbe essere il 4:00 locale, nel qual caso si tratta di una negoziazione tra te e il cliente su quando eseguire gli aggiornamenti.

Sono d'accordo con il commento di @ Ramhound. Raggruppa le caratteristiche in pietre miliari autonome e atomiche e rilascialo in modo indipendente. Cerca di bilanciare i rischi e i tempi di inattività dell'aggiornamento del server di produzione contro i rischi derivanti dall'introduzione di enormi cambiamenti in un'unica soluzione. Le pietre miliari durante il processo possono anche fornire un punto utile per fatturare il cliente per quella sezione di lavoro e dimostrare al cliente che stai facendo progressi.

Raccomanderei anche prima di eseguire la distribuzione sul server di produzione per testare la distribuzione.

  • Duplica il server di produzione (incluso il contenuto del database se possibile) sul server di prova.

  • Eseguire l'aggiornamento sul server di test esattamente come si intende sul server di produzione, inclusi eventuali passaggi di migrazione dei dati.

  • Verifica la versione del server di test come faresti sul server di produzione.

Una volta che si è soddisfatti del corretto funzionamento, è possibile eseguire l'installazione sul server di produzione. Trovo questo, un po 'paranoico, un approccio utile per cogliere eventuali problemi dell'ultimo minuto con pacchetti mancanti o problemi che si verificano solo con i dati nel database del server di produzione.

Buona fortuna, sembra che tu stia pensando attentamente a tutto, quindi sono sicuro che lo farai.

    
risposta data 21.07.2011 - 15:51
fonte
2

Il test di integrazione automatizzato è tuo AMICO.

Vai a cercare Selenium, un'applicazione di test del sito web automatizzata. Configura una suite completa di test che esercita completamente la funzionalità ATTUALE del sito. Quindi, periodicamente mentre sviluppi, esegui i test e verifica che le tue modifiche non abbiano infranto nulla.

Inoltre (come è stato menzionato) farlo su un server di staging, non sul server di produzione live. E usa il controllo della versione - generalmente raccomando git, dato che le sue capacità di ramificazione si prestano perfettamente a questo tipo di processo di sviluppo.

    
risposta data 22.07.2011 - 15:28
fonte

Leggi altre domande sui tag