Il modo migliore per gestire un sistema senza una fase di accettazione / test dell'utente [chiuso]

0

Storicamente sono stato in grado di cavarmela apportando piccole modifiche a un sistema di helpdesk interno che utilizzava uno stack LAMP e facevo solo un backup prima del montaggio.

Questo non ha alcuna fase di accettazione / test degli utenti e io lavoro direttamente sui file .php live.

Tuttavia ora è sorto il requisito che richiederà un po 'più di programmazione, e ovviamente non sono particolarmente contento di apportare queste modifiche senza un framework per supportarmi.

Quale sarebbe la migliore strada da percorrere? Potrei fare un altro backup, suppongo.

    
posta billy.bob 11.04.2011 - 17:22
fonte

3 risposte

2

Ciò che hai fatto può essere pericoloso, ma sei stato in grado di cavartela perché il pubblico di destinazione del sito era così piccolo e comprensivo. La migliore analogia a cui riesco a pensare è camminare su un filo alto senza rete. Potresti essere bravo, ma basta una brutta caduta per terminare la tua carriera (almeno con quel cliente). Per lo meno si desidera separare il proprio ambiente di sviluppo dal proprio ambiente distribuito.

Definitivamente fare un backup del tuo sito prima di iniziare. Se non lo hai già, ti consiglio vivamente qualche forma di controllo della versione. È un modo efficace per eseguire backup a grana fine e mantenere la versione corretta del software laddove necessario. Per il tuo ambiente particolare, potresti voler guardare Mercurial o Git (controllo della versione distribuita). Il vantaggio è che è possibile importare il codice esistente sul server e quindi estrarne una copia su un'altra macchina in cui iniziare a lavorare. Una volta terminate le modifiche, è possibile reinserire tali modifiche sul server. Quando aggiorni il repository sul server, tutto è aggiornato. Se hai bisogno di tornare indietro nel tempo, usa lo strumento per ottenere una versione precedente.

Devi eseguire il backup del database e ripristinarlo nel tuo ambiente di sviluppo. Idealmente inizierai con un nuovo database e aggiungerai solo quelle funzionalità di cui hai bisogno, ma in questo caso sono abbastanza sicuro che potresti non avere gli script correnti per configurare correttamente un database iniziale. Configura il tuo ambiente di sviluppo locale per lavorare con la tua copia locale del database. Dovrai creare i dati di test se questo non è un miglioramento insignificante, e in questo modo i tuoi utenti non ti urleranno per aver creato i dati falsi.

Mentre lavori, esegui spesso commit nel tuo repository locale, ma non spingere sul server finché non completi l'operazione non banale. Ciò rende più facile sperimentare, ma se non ti piace il modo in cui è andato il tuo esperimento, puoi ripristinare il punto che hai fatto senza dover ripetere tutto. Una volta che sei soddisfatto di tutto, puoi inviarlo al server e aggiornare lì il repository locale.

La linea di fondo è che una volta che hai effettuato questa separazione, puoi aggiungere un test separato o un'istanza di anteprima dell'applicazione a volontà in modo che le persone possano interagire senza rovinare l'installazione di produzione.

    
risposta data 11.04.2011 - 17:37
fonte
1

In primo luogo, suggerirei di creare un repository in [software di controllo sorgente di tua scelta] per tenere traccia delle modifiche, questo dà molto più di un backup se stai modificando diversi file, ed è una buona pratica per quasi tutti ogni occasione. Includi con questo script SQL per creare lo schema del database (qualcosa che molti progetti web sembrano trascurare nel controllo del codice sorgente).

Suggerirei quindi di creare un elenco delle modifiche / nuove funzionalità desiderate. Lavora su uno alla volta, stendi le modifiche e chiedi ad almeno due persone che richiedono modifiche per il feedback. A seconda di quanto sono bravi, dovresti essere in grado di entrare in un ciclo in cui il tuo lavoro sulla funzione A, impegnarlo, lavorare sulla funzione B, eseguirne il commit e quindi avere il feedback pronto per la caratteristica A.

    
risposta data 11.04.2011 - 17:35
fonte
0

Come altri hanno già detto, devi veramente avere il codice sorgente in un repository di qualche forma.

Suggerirei anche che è necessario un ambiente di gestione temporanea; Cioè una copia dell'intero sistema che non viene utilizzato dagli utenti dal vivo. Questo potrebbe essere un grande sforzo, ma è un investimento che vale la pena fare, ti permetterà quindi di testare le tue modifiche senza rischi per il sistema live.

I prodotti e il team più grandi avranno più ambienti di staging, in particolare uno isolato per il team di test. Sembra che tu possa farla franca con uno per ora.

    
risposta data 11.04.2011 - 17:46
fonte

Leggi altre domande sui tag