Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Gestione configurazioni e build

21 views
Skip to first unread message

Giulio Petrucci

unread,
Aug 26, 2013, 4:24:45 AM8/26/13
to
Ciao a tutti,

mi trovo a dover gestire le seguenti situazioni e avrei bisogno di
qualche dritta "di mestiere".
1. Applicazione X, piccola applicazione desktop in WPF con un database
SQLite3. Avrei bisogno che in fase di debug la compilazione si portasse
dietro un po' di roba, tipo un piccolo scriptino che riempie il database
di dati fittizi.
2. Applicazione Y, grossa applicazione web in produzione presso diversi
clienti (circa 5), ogni versione ha le sue customizzazioni e le sue
configurazioni.

Stavo pensando di iniziare a gestire i vari task di build e le varie
configurazioni da *dentro* visual studio. C'è qualche best practice?
Oppure (vedi caso Y) voi come fate per gestire diversi file di
configurazione?

Grazie,
Giulio

--

Mauro Servienti [MVP]

unread,
Aug 26, 2013, 8:20:31 AM8/26/13
to
Ciao Giulio,

You wrote on 26/08/2013 :
> Stavo pensando di iniziare a gestire i vari task di build e le varie
> configurazioni da *dentro* visual studio. C'ᅵ qualche best practice? Oppure
> (vedi caso Y) voi come fate per gestire diversi file di configurazione?

secondo me ᅵ sempre un macello e dipende molto dal contesto, dal
sistema di source control, da cosa devi fare con le build, se il tutto
deve funzionare solo sul build server o anche in locale sulla macchina
del dev, se deve essere facilmente manutenibile e se ᅵ sostenibile
pensare che sia un delirio :-)

.m

--
blog @ //milestone.topics.it


Giulio Petrucci

unread,
Aug 26, 2013, 9:19:26 AM8/26/13
to
Ciao Mauro,

On 26/08/2013 14.20, Mauro Servienti [MVP] wrote:
> secondo me è sempre un macello e dipende molto dal contesto, dal sistema
> di source control,

git.

> da cosa devi fare con le build,

Ottima domanda.
Partiamo dal caso dell'applicazione desktop. In quel frangente ho due
necessità:
1. quando lancio il debugger di VS, deve attivarsi la versione con il db
già riempito
2. quando faccio la build per il test, idem come sopra
3. quando faccio la build per la release, allora no.

> se il tutto deve
> funzionare solo sul build server o anche in locale sulla macchina del
> dev,

Diciamo che principalmente si tratta della macchina locale (che è anche
il build server :-)).

> se deve essere facilmente manutenibile

Ovvio. :-P

> e se è sostenibile pensare
> che sia un delirio :-)

Be'... su questo non commento.
:-D

Ciao,
Giulio

--


Julio Di Egidio

unread,
Aug 27, 2013, 4:07:16 PM8/27/13
to
"Giulio Petrucci" <sis...@nonono.boh> wrote in message
news:521b10d1$0$1369$4faf...@reader1.news.tin.it...

> 2. Applicazione Y, grossa applicazione web in produzione presso diversi
> clienti (circa 5), ogni versione ha le sue customizzazioni e le sue
> configurazioni.
>
> Stavo pensando di iniziare a gestire i vari task di build e le varie
> configurazioni da *dentro* visual studio. C'è qualche best practice?
> Oppure (vedi caso Y) voi come fate per gestire diversi file di
> configurazione?

Per le applicazioni web, da VS piu' o meno la panoramica e': varie
configurazioni di build, generazione automatica dei web config associati a
una configurazione, script di pre- e post-build in cui hai anche una
variabile di ambiente per sapere in quale configurazione sei; se non basta,
ci sono i progetti di deployment, a loro volta nella build configuration e a
loro volta con script di pre- e post-build.

Non credo ci sia una best-practice: come forse gia' intendeva Mauro, e' piu'
una questione di gestibilita', ovvero penso che sia un sistema sostenibile
(l'ho usato estensivamente e senza problemi e mal di testa) fino a che di
configurazioni diverse ne hai 2 o massimo 3, gia' 5 puo' comincia a
diventare fastidioso.

Julio


Mauro Servienti [MVP]

unread,
Aug 28, 2013, 6:09:06 AM8/28/13
to
> Per le applicazioni web, da VS piu' o meno la panoramica e': varie
> configurazioni di build, generazione automatica dei web config associati a
> una configurazione, script di pre- e post-build in cui hai anche una
> variabile di ambiente per sapere in quale configurazione sei; se non basta,
> ci sono i progetti di deployment, a loro volta nella build configuration e a
> loro volta con script di pre- e post-build.
>
> Non credo ci sia una best-practice: come forse gia' intendeva Mauro, e' piu'
> una questione di gestibilita', ovvero penso che sia un sistema sostenibile
> (l'ho usato estensivamente e senza problemi e mal di testa) fino a che di
> configurazioni diverse ne hai 2 o massimo 3, gia' 5 puo' comincia a diventare
> fastidioso.

condivido su tutta la linea.
0 new messages