Fare in modo che le applicazioni costruiscano il sistema

2

I sistemi di compilazione per le applicazioni Web sono eccezionali: offrono gestione delle dipendenze, minificazione del codice e la possibilità di utilizzare tecnologie come SASS o CoffeeScript che richiedono la pre-elaborazione.

Tuttavia, trovo che usare i sistemi di compilazione sia brutto e noioso ... devi assicurarti che gli sviluppatori abbiano gli strumenti di compilazione installati, che le versioni che hanno installato siano compatibili con le tue configurazioni e che tutte le dipendenze della build strumenti (compilatore SASS, jsmin, ecc.) sono soddisfatti. Ottenere un nuovo sviluppatore integrato richiede ora una suite di strumenti da installare sul proprio sistema locale.

Possiamo combatterlo usando la virtualizzazione: un sistema come Vagrant può consentire la codifica dei sistemi di sviluppo. È disponibile una serie di passaggi per creare un ambiente di sviluppo con tutte le dipendenze o un'immagine macchina già configurata e che può essere semplicemente installata ed eseguita.

Il mio obiettivo è rendere il sistema di generazione non intrusivo. Vorrei che gli sviluppatori non dovessero nemmeno essere a conoscenza del sistema di costruzione per hackerare un progetto. Potrebbe non essere realistico.

Con Vagrant, puoi ottenere questo risultato facendo in modo che un servizio di "sorveglianza" del tuo sistema di build esegua automaticamente e ricostruisca i file ogni volta che cambiano. Va bene, ma che dire di uno sviluppatore del sistema locale che non vuole eseguire Vagrant? Devono ricordarsi di eseguire un processo separato ogni volta che si siedono per sviluppare.

Un approccio che non ho visto è quello di rendere consapevole il sistema di compilazione dell'applicazione. Sembra violare una separazione di preoccupazioni, tuttavia con lo sviluppo del web moderno sembra che siamo già strettamente collegati ai nostri sistemi di build: senza eseguire lo script di build, sarai in grado di eseguire la tua app Web e vedere qualcosa di significativo? Le risorse statiche saranno a posto?

C'è una ragione convincente non per fare in modo che l'applicazione guardi al suo stato di build e si ricompili quando necessario, quando è in modalità sviluppo? Quando si esegue il server di sviluppo, l'applicazione potrebbe essere consapevole del sistema build e creare le sue risorse, se necessario.

Questo non sfugge ai requisiti di dipendenza del sistema di sviluppo. Non ho ancora un'idea concreta di ciò che sto cercando, ma mi sento come se i sistemi di compilazione per le app web non fossero ancora "elaborati". Spero di poter avere un buon brainstorming qui.

    
posta ashgromnies 24.04.2014 - 17:37
fonte

1 risposta

2

Questo è esattamente ciò che accade per i piccoli progetti. LESS o Sass sono convertiti al CSS direttamente dall'applicazione web stessa e JavaScript viene anche minimizzato dall'app Web.

Questo approccio, ad esempio, è diventato quello predefinito con ASP.NET MVC: CSS (o qualsiasi altro preprocessore, se si dispone della libreria necessaria per esso) e il codice JavaScript è combinato in un singolo CSS e un singolo file JavaScript e quindi servito; se si modifica uno dei file CSS, non è necessario ricompilare: basta aggiornare la pagina e il pacchetto viene rigenerato automaticamente.

È fantastico per i piccoli progetti. Cambia il file LESS. Passa al browser. Premere F5. Ottieni il risultato. Immediatamente.

Non è eccezionale per i progetti di grandi dimensioni.

  • In primo luogo, non si ottiene l'immediatezza che si può avere con un piccolo progetto, semplicemente perché ci sono troppi file da trasformare e ci vuole solo tempo. Non è che devi aspettare qualche minuto, ma anche cinque secondi diventano fastidiosi se devi apportare centinaia di piccoli cambiamenti nei fogli di stile.

    Se l'attività consiste nell'apportare molte piccole modifiche ai CSS ottenendo un feedback visivo quasi immediato, ci sono modi migliori per farlo rispetto al flusso di lavoro change-build-refresh. Uno di base è modificare i CSS direttamente nel browser; qualsiasi browser decente consente di farlo.

  • Quindi, sei meno preoccupato di come il tuo nuovo stile apparirà in un browser e di più riguardo al superamento dei test. Con migliaia di test da superare, semplicemente non puoi farlo localmente. Devi dedicare questo duro lavoro a un server di build, e per server, intendo più una fattoria di potenti macchine in grado di funzionare in meno di cinque minuti, cosa che perderebbe giorni se fosse eseguita localmente.

    Immagina di dover cambiare la modalità di visualizzazione di un'informazione su un'app Web. Qual è la tua preoccupazione principale?

    1. Cambia il codice.

      È vero. Se hai bisogno di feedback visivi, fallo nel browser e poi rispecchia la modifica del codice sorgente.

    2. Verifica che il nuovo codice corrisponda alle convenzioni di codifica.

      Questo è ciò che fa un hook pre-commit, quindi devi effettivamente eseguire il commit del tuo codice e attendere che il server di controllo versione risponda, oppure eseguire il controllo localmente, il che significa installare i controllori.

    3. Assicurati di non aver introdotto regressioni.

      Questa è la parte più importante. Hai cambiato gli stili e funziona sulla particolare pagina che stavi guardando al momento del cambiamento. Ma che dire di migliaia di altre pagine? Che cosa succede se la tua modifica ha rotto un'altra pagina di cui non eri a conoscenza?

      Ecco il server di build. Farà il pdiff e mostrerà la grafica delle modifiche. Ehi, guarda quello! Sembra che il tuo cambiamento abbia influenzato una pagina che ora è completamente infranta. Non puoi saperlo quando lavori localmente.

    Per JavaScript, va oltre: bisogna testare unitamente, eseguire test funzionali, per generare la nuova versione della documentazione. Tutti questi passaggi rendono cruciale un server di build.

  • Inoltre, i progetti di grandi dimensioni semplicemente non possono permettersi di fare trasformazioni LESS e CoffeeScript durante il tempo di esecuzione, per due motivi.

    Il primo è la performance. Non puoi consentire a un utente finale di attendere cinque secondi durante la ricostruzione dei file JavaScript.

    Il secondo è che aggiunge complessità e il tipo di complessità che può facilmente essere mitigata spostandolo nella build. Più complessità significa più possibilità di avere bug e più test da eseguire.

  • Infine, avere due sistemi (la build che esegue i test e la prima generazione post-build che costruisce CSS e JavaScript) sembra davvero imbarazzante. Mantenere tutto nello stesso posto e fare tutto il duro lavoro su un server di build dopo ogni commit rende le cose molto più semplici.

Conclusione

La tua idea è ottima per i progetti su piccola scala. È già popolare nella comunità Microsoft e mi aspetto che anche altre comunità utilizzino lo stesso approccio. Consente allo sviluppatore di ottenere la risposta quasi immediata senza dover ricompilare l'app o installare componenti aggiuntivi sulla macchina.

Per i progetti su larga scala, invece, il flusso di lavoro è centrato su una build , che è sia il battito cardiaco del progetto che il mezzo per verificare che i cambiamenti siano corretti e se sono, spostali in produzione. Guardare l'effetto delle modifiche localmente non ha senso, perché il test di regressione delle parti più importante richiede giorni su una normale macchina desktop e perché anche la trasformazione di CSS e JavaScript richiede troppo tempo rispetto alla risposta quasi immediata che ci si aspetterebbe. / p>     

risposta data 24.04.2014 - 19:48
fonte