Le configurazioni e gli ambienti: un rapporto difficile
Il problema è abbastanza tipico ed è molto semplicemente che la configurazione della macchina di sviluppo è sempre diversa dalla configurazione delle macchine di test che è sempre diversa dalla configurazione della macchine di preproduzione che a sua volta è sempre diversa da quella delle macchine di produzione… respiro :-)
La cosa importante è che:
- va bene che sia così;
- non ha assolutamente nessun senso che si cerchi di cambiare le cose;
Siccome ne ho già parlato non vi tedio oltre e vi rimando a quel post per la soluzione. In quel post mancano però un paio di puntaulizzazioni importanti:
- Non fare di più di quello che ci serve, è tempo sprecato:
Queste sono le post-build action di un progetto, vedremo prossimamante cosa fanno e che problema risolvono, sono banalmente dei comandi per la shell, giustamente qualcuno potrebbe dire… tristezza… perchè non l’hai fatto con MSBuild? perchè scrivere quei comandi cuba circa 20 secondi e sono a prova di vero nerd, se ci sono riuscito io :-)…, mentre mettere mano al file *proj di MSBuild, testarlo e assicurarsi che in tutte le condizioni funzioni non è proprio cosa banale e quello che vogliamo fare è decisamente banale: luke…keep it simple:-). - Sii curiso e pigia sui bottoncini che trovi sulla UI… mica mordono :-)
e scopri che Visual Studio ha un interessantissimo set di “macro” che rendono il task di cui sopra ancora più da dummies :-) - Anzi… 3 puntaulizzazioni: nell’ottica dell’essere a prova di scemo e friction-less una soluzione complessa ad un problema banale è sicuramente la cosa peggiore che possiamo fare; se diamo in mano la nostra solution ad un nuovo dev sarà più facile che comprenda una Post Build Action o che sia un guru di MSBuild, NAnt o QuelloCheViPareCompiloIoCheSonoFigo? :-)