Mi ricollego al discorso iniziato da @r.bianco su Progetti di classe Enterprise con Foundation
Abbiamo dei progetti molto complessi, l’albero è tipo così:
Progetto A
Applicazione Web usa tutti i componenti
Comp A offline, esportato
Comp B (usa A) offline, esportato
Comp C (usa A,B) offline, esportato
Comp D (usa A,B,C)
Comp E (usa A,B), esportato
Comp F (usa A,B,E)
Comp G (usa A,B) offline, esportato
Comp H (usa A,B,G)
Progetto B
Applicazione mobile usa A,B,C,G senza sorgenti
Comp M (suo specifico)
Di norma come lavoriamo?
Facciamo una modifica a componente B, esportiamo C,E,G, ma anche A perché ci piace avere tutti i componenti allineati con lo stesso numero di versione.
Andiamo nell’applicazione mobile e importiamo i componenti usati (E è usato in un altro progetto ancora).
E fin qui sembra tutto facile.
La faccenda si complica quando aggiungiamo la variabile “produzione”, ossia il progetto che va pubblicato in produzione non necessariamente conterrà tutte le modifiche del componente B perché magari sono ancora da testare, e con un ciclo di rilascio molto breve (settimanale se non più volte a settimana) non riusciamo a preparare tutto per la pubblicazione ogni volta.
Allora per sicurezza, a meno che non devo fare delle funzionalità nuove da testare, recupero nella copia ufficiale di pubblicazione le modifiche, esporto da lì i componenti e quindi importo i componenti definitivi nell’applicazione mobile. E già questo è un buon carico di lavoro.
Problemi
Essendo il progetto A molto grosso abbiamo numerosi problemi di prestazioni con TW, i checkin ci mettono una decina di minuti.
La compilazione è molto lunga e come già riportato da Riccardo validando più e più volte gli stessi componenti (A viene validato n-volte+1 in base a quante volte utilizzato).
L’esportazione dei componenti fallisce il più delle volte durante la compressione del componente (siamo ancora in 24, probabilmente con la 25 che può gestire componenti non compressi si riesce a far qualcosa) e già li esportiamo senza sorgenti, con i sorgenti è praticamente impossibile.
Per l’app mobile il file full.js contiene n-volte+1 tutti i componenti in base a quante volte sono riutilizzati rendendo il debug un’odissea.
Soluzione praticabile
Una possibile soluzione per le prestazioni è quella di tirar fuori ogni componente in un suo progetto, riducendo drasticamente il peso del progetto A e quindi TW ringrazia, l’IDE ringrazia perché non deve più rivalidare 800 volte i componenti e i tempi morti si riducono drasticamente.
Considerazioni e domanda finale
Intanto non risolverebbe il problema dell’esportazione, il componente resta grosso uguale e fallisce uguale, ma così facendo inoltre incappo nel problema con l’applicazione mobile (progetto B), ossia fare tutto il giretto per lo sviluppo e per la pubblicazione in produzione.
Sono a conoscenza dei branch etc, ma con TW è praticamente tutto lavoro manuale e non riusciamo a gestirli, è più semplice gestirli lato Cloud con il sistema diverso e probabilmente lo sarà lato Studio, ma per il momento…
Tutta questa spiegazione mi serve a un quesito che mi sta infastidendo da tempo, ossia: come snellire questo giretto di esportazione e importazione componenti?