È ragionevole utilizzare diversi controlli di versione per diverse parti di un'applicazione Web?

Naviga le tue risposte
0

Sto pensando a diverse tecniche per organizzare il codice per un'applicazione web più grande. Per questa situazione, il server esegue alcune soluzioni Microsoft (probabilmente ASP.NET MVC o OpenRasta) e il client (JavaScript, CSS, ecc.) Lo consuma. Tradizionalmente in un'applicazione MVC, i controller ei modelli insieme al codebase del client vivono tutti nello stesso progetto / soluzione. Le nostre soluzioni attuali utilizzano TFS per il controllo del codice sorgente.

Voglio iniziare a usare Sass e Compass per il front-end, che richiederà Ruby, e mi piacerebbe usare git per il controllo della versione del front-end e continuare a usare TFS per i componenti del server. Il problema che ho è che per far eseguire la soluzione a qualcuno, è necessario prelevare da entrambi i repository e non sono sicuro che sia ragionevole.

Vorresti tentare qualcosa del genere? Riesci a pensare a un modo migliore per strutturare i progetti in modo che il front-end sia separato dal back-end? Se non l'avessi spiegato abbastanza bene sarò felice di elaborare.

    
posta Eli 07.12.2011 - 15:29
fonte

2 risposte

7

Scorporò questa pratica e incoraggerò un singolo controllo di versione unificato (e una gestione di configurazione più grande) su base per progetto.

Qualsiasi individuo, in qualsiasi momento, dovrebbe essere facilmente in grado di ricreare il progetto come lo era in un particolare momento di tempo, e suddividere il progetto in più sistemi di controllo delle versioni rende molto più difficile, dato che si sta trattando con commit, branching e tagging in due sistemi anziché uno.

Per quanto riguarda la separazione del back-end dal front-end, una separazione logica va bene e non richiede una separazione nel controllo della versione. Se si riutilizzano gli stessi componenti in più progetti, prendere in considerazione un trunk e creare rami appropriati per modifiche specifiche che potrebbero essere per progetto o per client.

    
risposta data 07.12.2011 - 15:37
fonte
3

L'IMO che utilizza diversi VC allo stesso tempo ti dà solo un mal di testa dal punto di vista della manutenzione. Inoltre renderà la vita degli sviluppatori più difficile.

Se le storie del progetto sono realmente separate l'una dall'altra (team, filiali, ciclo di sviluppo, ecc.) suggerisco di provare ad implementare un meccanismo come svn esternals o sottomoduli git (TFS dovrebbe avere qualcosa di simile). Questo approccio ha funzionato bene per noi. Gli sviluppatori di back-end non sono interessati all'interfaccia utente e utilizzano i propri strumenti. La struttura principale del progetto ha il ramo definito come esterno e gli sviluppatori front-end non devono pensare troppo alle diverse dipendenze quando costruiscono le loro cose.

    
risposta data 07.12.2011 - 16:32
fonte

Leggi altre domande sui tag

Formattazione di una stringa convertendola in un numero e poi di nuovo in una stringa Devo seguire la regola del "principio di inversione di dipendenza" anche se ho bisogno di un solo tipo e non ho bisogno di polimorfismo?