Dove memorizzi le tue build?

Question

Dove memorizzi le tue build?

#1 da (5 voti)
#2 da (2 voti)
#3 da (1 voti)
#4 da (1 voti)

6

Al momento utilizziamo Team Foundation Server per fare le nostre build. So che possiamo dire a TFS di mantenere le nostre build per un certo periodo di tempo o di tenerle indefinitamente. E se volessimo mantenere indefinitamente alcune o tutte le nostre build nel caso in cui dovessimo tornare da loro per qualche motivo? Qualcuno di voi usa il controllo del codice sorgente per archiviare le proprie build o utilizzare qualche tipo di file server per conservare le proprie build su un file server per il recupero futuro? Memorizzare le build all'interno della directory Team Build causerebbe un rapido disordine nella directory.

Naturalmente possiamo sempre ramificare un vecchio changeset e creare una definizione di build per quel ramo, ma è più dispendioso in termini di tempo rispetto al recupero di una build dal controllo del codice sorgente o da un file server.

Forse quello che stiamo cercando di fare è solo una cattiva idea.

builds

posta Bob 06.05.2011 - 21:01

fonte

4 risposte

Leggi altre domande sui tag builds

Il framework MVC sembra suggerire la creazione di centinaia di pagine .aspx o .cshtml. Come posso evitare questo? Come dovrei scegliere la documentazione giusta per il mio team?

score 5 · Answer 1

Sicuramente d'accordo sul fatto che le build dovrebbero essere ripetibili. Ma a volte è necessario mostrare i risultati esatti per qualsiasi motivo.

Qui usiamo TeamCity, e abbiamo una funzione chiamata "pinning" - in pratica possiamo bloccare qualsiasi build data, il che significa che verrà mantenuta per sempre. Lo facciamo per tutte le versioni, ma le circa 1000 build che ci sono state lì non sono bloccate.

Non ho idea se TFS abbia una funzionalità simile.

score 2 · Answer 2

Direi che quello che stai facendo è una cattiva idea, come sospetti.

Dovresti idealmente essere in grado di costruire automaticamente il tuo pacchetto completo. A quel punto non è necessario mantenere le build in giro. Se hai bisogno di ciò che hai rilasciato il mese scorso, crealo automaticamente dal tag nel controllo del codice sorgente.

Se ciò non è abbastanza buono, allora il tuo processo di compilazione non è automatizzato correttamente, e questo è il problema che ha davvero bisogno di essere risolto.

score 1 · Answer 3

L'ultimo posto in cui mi trovavo, abbiamo masterizzato ogni build su un CD. Il CD ha gli eseguibili, l'installer e tutto il codice sorgente che ha prodotto quella build. Questo era per le build interne, ovviamente, avevamo una procedura completamente diversa per i CD in cui spedivamo il prodotto (ad esempio ovviamente senza il codice sorgente). Ha scritto il numero di build sul CD nel marker e ha mantenuto un mandrino di vecchie build accanto alla macchina di compilazione. Bassa tecnologia e vecchia scuola, ma bassa ed efficiente.

score 1 · Answer 4

Suppongo che tu abbia a che fare con un'applicazione desktop o client-ospitata - è insolito che un'app web ospitata da casa si preoccupi delle versioni precedenti.

Quando stavamo lavorando a prodotti in cui più release sarebbero potenzialmente in circolazione in qualsiasi momento, abbiamo trovato molto utile avere rami separati nel nostro controllo di versione (git) per ogni versione, con i risultati di una compilazione completa controllata in ogni ramo.

I vantaggi erano molteplici:

Le vecchie build esistenti erano incredibilmente utili per il personale addetto all'assistenza e alla manutenzione, quando tentavano di risolvere problemi al cliente o di riprodurle in casa.
Generalmente una compilazione completa richiede diverse ore e richiede macchine dedicate. Una volta rilasciata una versione, è sicuro che vorremmo nuovamente, e il compromesso tra spazio e tempo è un gioco da ragazzi.
Convincere un cliente a installare una patch è solitamente più facile che convincerli a fare un aggiornamento della versione principale. Man mano che le versioni sempre più vecchie del software si evolvono, è vantaggioso avere filiali in cui è possibile controllare correzioni specifiche, per mantenere le vecchie versioni funzionanti abbastanza a lungo (in modo che i clienti possano avere il tempo di aggiornare in sicurezza alle nuove versioni principali)