Passaggi per iniziare il controllo della versione di un'applicazione web

1

Fino ad ora, non avevamo una strategia di versione dell'applicazione o versione della nostra applicazione. Stiamo pensando di farlo con la nostra prossima versione. Quali sono i compiti minimi necessari per passare a un'applicazione versione-edita? Le risposte sotto forma di punti elenco, non necessariamente in ordine cronologico, sarebbero sufficienti. Va bene mantenerlo di alto livello. Alcuni esempi potrebbero essere:

  • Determina convenzione nome controllo versione Major.Minor.Build.YY ...
  • Rivedi su immagini dello schermo o testo per visualizzare la versione corrente
  • Prepara il modello delle note di rilascio per comunicare nuove versioni agli utenti

Siamo un negozio .Net che usa TFS se questo aiuta. Se non è già evidente, non sono uno sviluppatore. Sono l'esperto di soluzioni / BA che agisce spesso come project manager.

    
posta Drano 07.12.2015 - 21:24
fonte

3 risposte

2

Se il tuo obiettivo è essere in grado di tenere traccia di una versione utilizzata da un cliente quando questo cliente segnala un bug, qualsiasi tecnica potrebbe funzionare. Non appena il numero di revisione (dal controllo della versione) appare in qualsiasi punto della pagina, puoi collegare il bug alla revisione corrispondente.

In .NET, è possibile eseguire automaticamente l'incremento automatico della versione dell'assembly . L'attività rimanente è:

  • Visualizza il numero di versione se ci si aspetta che gli utenti lo segnalino (tramite uno screenshot o manualmente),

  • O semplicemente memorizza nel log quando una determinata versione è stata distribuita su un determinato server: questo renderà possibile determinare la versione ispezionando i log HTTP (particolarmente utile quando si monitorano errori HTTP 500, senza attendere gli utenti finali a segnalarti gli errori.)

Nota aggiuntiva: le note di rilascio vanno bene per i prodotti software. Per le app Web, gli utenti semplicemente non si preoccupano di quale versione usano. Ad esempio, conosci la versione corrente di GMail? Che dire di Office 365? O forse Facebook? O Stack Exchange (sì, si può dare un'occhiata in fondo a questa pagina)? Questo sta effettivamente diventando vero anche per i prodotti software. Google Chrome è un eccellente esempio. Adobe Creative Cloud sta diventando sempre più un altro esempio.

    
risposta data 07.12.2015 - 21:52
fonte
1

Immagina la vita del tuo prodotto come una collana di perle. La stringa sottostante è il costante background in background: processi di definizione del software, processi di gestione dei problemi, processi di sviluppo, ecc. È lo scheletro.

Le perle sono versioni distinte. Alcuni sono colti. Altri sono naturali Ci sono perle di acqua salata e perle d'acqua dolce.

In realtà, questo è un cattivo esempio perché non esiste il concetto di tempo. Il tempo è importante in gestione delle versioni . Questa è la cosa di cui stiamo realmente parlando: miglioramento della gestione delle versioni . Quindi costruiamo una metafora migliore. La vita del tuo prodotto è una corsa di film. Così va meglio. La parte oscura tra le celle - la parte perforata con fori in modo che il proiettore possa tirarla attraverso - questo è il tuo impianto idraulico. Le versioni sono le celle. Si stanno muovendo nel tempo. Il film si sta svolgendo. Lo stiamo guardando.

Ora, il trucco è quello di raccogliere tutto il necessario per creare una cella particolare in modo che si adatti tra i suoi vicini e facciamo fluire la storia senza intoppi. Hai bisogno di un regista, scrittori, attori, sceneggiatori, produttori (i soldi), telecamere, un assistente del regista e forse un direttore della fotografia. Sì, mi piace. Funziona.

  • Cose che entrano in una cella: trama (sviluppo di funzionalità), ottimizzazione delle scene (correzioni di bug), inserimento di prodotti (richieste client inane), struttura di tiro (UX).
  • Devi coordinare perfettamente tutte queste cose in modo che non si adattino solo nella cella, ma anche nel film.
  • Gli azionisti esterni vogliono sapere in quali celle appare il loro materiale.
  • Gli azionisti interni vogliono sapere a quali celle devono contribuire e cosa dovrebbero contribuire.
  • Ecco perché una pianificazione strong (ma flessibile) è d'obbligo. Con i tempi lunghi, una stima approssimativa è adeguata, ma man mano che le celle si avvicinano è importante comunicare con precisione dove appariranno un problema o una caratteristica.
  • Il problema con gli elementi menzionati nella tua domanda e altre risposte è che rappresentano una piccola parte del processo di realizzazione del film. Numeri di versione, visualizzazione del numero di versione, CI ... sono tutte cose importanti ma rappresentano una piccola parte di un film. Forse sono le persone della macchina da presa (sviluppatori) e il direttore della fotografia (architetto). Ricorda che molto altro va in ogni cella.
  • Ancora più importante (ed ecco dove brilla davvero la nostra metafora!), ricorda che una buona storia non viene raccontata con una singola cella in un film. È un mucchio di cellule insieme per formare una scena, un gruppo di scene insieme per formare un atto. Si tratta di tempismo. Non solo tutto deve riunirsi per la cellula, ma le cellule devono essere sequenziate per massimizzare il loro effetto!

Più:

risposta data 08.12.2015 - 07:28
fonte
0

Le etichette sarebbero il punto importante da notare. Scopri come utilizzare la funzionalità integrata di TFS che è simile al tagging in Subversion per essere in grado di estrarre una particolare build del codice.

Ci sono altre idee come l'integrazione continua, il blocco dei codici e la programmazione che possono essere utili ma che non sarebbero necessarie per avere versioni in un'app.

Integrazione continua - si tratta sostanzialmente di eseguire tutti i test ogni volta che qualcuno esegue il commit del codice. Utile per trovare vecchi bug che sono riemersi in quanto i cambiamenti di qualcuno in un posto possono avere effetti collaterali. TFS include parte di questo.

Code Freeze - si tratta essenzialmente di impedire l'aggiunta di nuove funzionalità al trunk principale durante il rilascio è stabilizzato Pensa a questo come impedire agli altri di usare una cucina mentre un gruppo sta cucinando lì.

La pianificazione è parte del blocco del codice in termini di comunicazione quando la release è pronta per eseguire test di QA di base, quando ha il test di accettazione degli utenti e quando è il rilascio. Ogni fase è importante ma, a seconda del tuo processo, non tutti si applicano.

    
risposta data 07.12.2015 - 21:55
fonte