Come gestisci frequenti rilasci di software su più client? [chiuso]

Ecco cosa facciamo:

• Abbiamo riparato iterazione in cui vengono create tutte le funzioni pianificate.
• Ogni volta che una funzione viene completata, viene attivato lo script di build automatico e lo rendiamo immediatamente disponibile in un'area speciale chiamata "BETA". È completamente automatico e include l'aggiornamento e l'aggiornamento delle pagine web caricare. Si chiama BETA perché è un termine ben compreso dai nostri utenti. Ma sono puramente sviluppi di sviluppo. Pronto per essere consumato da loro. Il fatto che sia una pagina BETA, l'utente accetta le imperfezioni e il fatto che diventano implicitamente tester di quella build.
• Alla fine di un'iterazione, decida di fare una versione ufficiale (newsletter, cambio del sito web, ecc.) o di ritardare la successiva iterazione.
• Durante il processo, riceviamo feedback dai nostri clienti continuamente . A volte, ci occupiamo di una funzione immediatamente . L'abbiamo reso disponibile molto rapidamente grazie a queste versioni di sviluppo.
• Se affrontiamo un bug fastidioso, lo aggiustiamo sul trunk e lo uniamo al ramo che abbiamo fatto quando abbiamo rilasciato la versione precedente. E aggiorna il file nell'area download ufficiale in modo silenzioso e informa gli utenti che sono stati interessati dal problema.

Facendo questo ci dai i seguenti vantaggi:

• Abbiamo controllo il nostro processo di rilascio. Il nostro cliente lo sente e quindi si fida di noi di più.
• Alcuni clienti sono più desiderosi di fornire un prezioso feedback quando vedono che è importante per noi. Molte innovazioni provengono da quel canale.
• I nostri clienti sanno che stiamo aumentando continuamente quello che hanno pagato, e quindi abbiamo (reale) la sensazione che valga i soldi in cui hanno investito.

Questa è solo una panoramica del processo, ma sono sicuro che avrai capito il punto.

C'è un ottimo libro chiamato Consegna continua che potrebbe aiutarti. Inoltre, potresti voler esaminare un processo chiamato Linee di prodotti software che affronta approcci per mantenere un gruppo di strettamente correlati rami del software. Abbiamo usato questa tecnica quando ero a Convergys (che gestisce la fatturazione per la maggior parte dei provider di servizi wireless e Internet in America utilizzando un singolo prodotto personalizzato per ciascuno dei provider).

Per la maggior parte, uso le filiali. In molte rare occasioni, ho clonato una copia completamente specifica del client del repository. Il punto principale è che vuoi che tutto rimanga "correlato" in modo che la fusione e forse anche il cherry picking non debbano proverbialmente succhiare.

Seguo la stessa regola che seguo quando faccio un fork di qualsiasi altro progetto open source. Se ho bisogno che il progetto vada in una direzione che la maggior parte delle persone coinvolte considererebbe eccessivamente localizzata e specifica per le mie esigenze, la forzo. Se le esigenze del cliente sono sufficienti a divagare dallo sforzo principale, rimuovi un altro repository.

Altrimenti, non è affatto raro mantenere filiali per varie architetture, quindi i rami per particolari client che non richiedono di allontanarsi troppo dall'ambito di sviluppo principale servirebbero fondamentalmente la stessa cosa.

Inoltre, non c'è niente di sbagliato nella clonazione di un nuovo repository per client. Il punto è, tenerli tutti correlati in modo che il tuo sistema di controllo delle versioni ti aiuti a gestire le unioni, le bisecature, i tag e tutte le altre cose belle che contiamo su di loro.