Processo di sviluppo applicazioni Web - Controllo versione, Monitoraggio dei bug, Test unità, Distribuzione

Question

Descrivere il processo che si utilizza per sviluppare applicazioni Web a un livello non troppo elevato, concentrandosi su VC, bug tracking, QA, unit test, deployment e qualsiasi altra cosa simile (meno la pianificazione/comunicazione client delle cose).

Sono nuovo in questo settore, quindi il mio rozzo esempio (leggi: non ho usato questo processo) è senza dubbio un po 'disagiato, per così dire - fa notare che è un difetto quindi posso imparare.

Es.

1. Creare il repository del progetto sul server SVN locale.
2. Creare script batch/shell per i mapping DNS.
3. Verificare il progetto, iniziare a lavorare sulla copia di lavoro locale.
4. Sviluppa funzionalità come diramazioni.
5. Traccia bug con Mantis (il collegamento si impegna a bug attraverso la sua integrazione SVN (nessuna idea se esiste)).
6. Documento man mano che vai.
7. Do QA sulla filiale.
8. Unisci al tronco quando è stabile.
9. Test dell'unità?
10. Accedere al repository quando la funzione è implementata e stabile.
11. Copia le versioni sui tag nel repository. Per esempio./project/tags/rel-123/
12. Utilizza Phing per caricare sul server di gestione temporanea. (Qualcuno potrebbe chiarire esattamente ciò che un server di gestione temporanea viene utilizzato per 'test' oltre?)
13. Usa Phing di preparazione del sito dal vivo per l'aggiornamento, istituito DB/distribuire, ecc

Answer 1

molto approssimativamente:

1. Crea il repository SVN in
2. Controllo copia di lavoro locale per ambiente di sviluppo
3. Aggiornamento/commit Frequenti cambiamenti
4. Deploy di mettere in scena da SVN TR Lo Zio utilizzando personalizzato distribuire lo script
5. test QA sul palco, rapporti bug in Mantis
6. sviluppatori correggere i bug, segno di come deliberato
7. Re implementare mettere in scena
8. test QA bug, si chiude se fisso
9. QA è finito, fare test di regressione
10. Deploy per la produzione utilizzando personalizzato distribuire lo script
11. fare un po 'di danza

Creiamo anche succursali per future versioni o funzionalità. Questi alla fine vengono uniti nel bagagliaio.

Manteniamo le nostre strutture db sincronizzate con uno strumento di confronto db personalizzato che viene eseguito durante i deploy.

Answer 2

1. Crea/checkout versione TESTA ("ramo principale")
2. Sviluppare un codice e la sincronizzazione con il ramo principale -at ai minimi quotidiana
3. Dopo lo sviluppo è fatto, scrivere e unità di eseguire i test
4. Go attraverso la revisione del codice e inviare codice/modifiche al ramo principale
5. Lasciate costruttore continua eseguire tutti i test unitari e test di sistema/integrazione sul ramo principale
6. Quando si è pronti, ciliegio raccogliere le revisioni e di integrarli al ramo QA
7. Esegui test di integrazione e di sistema, corregge bug segnalati o ripristina se necessario; questo ripete i passi 4-7
8. Dopo QA signoff, integrare il cambiamento QA di rilasciare ramo
9. unit test Run, sistema/i test di integrazione sul ramo di release
10. Deploy per la produzione ed eseguire test di sanità mentale.

Un server di gestione temporanea è una copia dell'ambiente di produzione che è il più aggiornata possibile. Nel mio progetto attuale, siamo in grado di mantenere ogni versione indipendente l'una dall'altra, quindi il nostro "server di staging" è il nostro server di produzione, accessibile solo da un URL diverso.

Note e discreprencies:

Tutti i passaggi sono qualche variazione a seconda delle dimensioni del vostro progetto. Più grande è il tuo progetto, migliore sarà il beneficio derivante dalla selezione delle ciliegie e dalla separazione dell'ambiente. Nei progetti più piccoli, questi possono semplicemente essere time sink e sono spesso ignorati o ignorati.

Per chiarire, c'è uno stack di sviluppo, uno stack di controllo qualità e uno stack di gestione temporanea. A seconda delle dimensioni del progetto, il controllo qualità potrebbe essere la gestione temporanea, la produzione potrebbe essere la messa in scena o una combinazione delle stesse. La separazione degli stack Dev e QA è la più importante.

Nei passaggi precedenti, suppongo che sia il codice che i dati rilevanti siano sottoposti a controllo di versione o tracciamento. Avere un processo di rilascio e creazione che tenga conto dei dati di controllo rende molto semplice la pubblicazione.

In un progetto di piccole-medie dimensioni, potrebbe esserci o meno un ramo di rilascio; dipende dalla frequenza del cambio di codice. Inoltre, in base alla frequenza di modifica del codice e alle dimensioni del progetto, è possibile integrare il ramo QA completo al ramo Rilascio oppure selezionare revisioni specifiche da integrare nel ramo di rilascio.

FWIW, ho trovato "script di migrazione" di scarso valore. Sono sempre uno script unico con un piccolo riutilizzo e rendono i rollback un rompicapo. È molto più facile, direi meglio, rendere l'applicazione compatibile all'indietro. Dopo alcune versioni (quando un rollback è ridicolo), la pulizia dei dati dovrebbe essere eseguita, se necessario.

Answer 3

Vecchio post, ma domanda interessante!

Alla mia azienda ora:

1. Creare un nuovo Github repo
2. Configura Jenkins
3. Clone localmente
4. Avviare un ramo
5. Sviluppare e aggiungere test (server, client e 2 lati)
6. Confermare per ogni passaggio e recuperare + rebase per mantenere il ramo sincronizzato
7. Una volta pronto, spingere il ramo sul server: un controllo pre-commit lint e verifica e blocca se non ok
8. Creare una richiesta di pull per il ramo
9. Qui, jenkins esegue automaticamente i test sul ramo e lo contrassegna come "verde" o "test non funzionanti" direttamente nella richiesta pull
10. Avere almeno 2 colleghi esaminare la richiesta pull e correggere i risultati (torna al passaggio 5)
11. Quando tutto è verde e 2 colleghi hanno concordato, l'ultimo unisce la richiesta pull
12. Elimina il ramo sul server
13. Quando pronto, spingere una nuova versione
14. Ultima versione ottenere immediatamente implementato su una piattaforma di prova
15. QA convalidare le correzioni introdotte (ritorna 5 se problema)
16. (TODO) distribuire ad un pre-prod con parametri identici rispetto alla produzione
17. Deploy per la produzione
18. andare a chiedere scusa agli utenti per i bug introdotti;) e li riportano nel gestore problema
19. funzionalità richieste gET e rapporto nel numero di direttore
20. ciclo di riavvio a step 2