Libreria UI di frontend end che utilizza più repository per più client

1

Ho appena ereditato una libreria UI interna basata su HTML / CSS, che il posto che lavoro sta pianificando di utilizzare per standardizzare gli stili CSS per tutti i suoi prodotti su tutta la linea, principalmente webapps. La libreria ha un codice che è in uno stile simile al bootstrap, tuttavia ci sono anche file css separati per ciascuno dei nostri client all'interno dello stesso repository git.

Ora sento che farlo in questo modo è sbagliato perché, in primo luogo, ritengo che gli stili specifici del client dovrebbero trovarsi nel proprio repository, lontano dal codice di base della libreria dell'interfaccia utente. Inoltre, quando si tratta di creare CSS minorato e JavaScript per la produzione, esiste un lavoro di compilazione automatizzato, che alza i numeri di versione al completamento. Poiché disponiamo di team che lavorano con diversi client contemporaneamente, i lavori di compilazione / rilasci conterranno il codice "Pronto per il rilascio" per un cliente, mentre il resto avrà il codice "In corso". Influisce anche sul sistema di numerazione delle versioni in cui sono presenti dozzine di versioni, ma il codice base principale non è cambiato molto.

Ritengo che ciò debba essere risolto, tuttavia so che il tempo necessario per investire in questa impresa dovrà essere molto; quindi, ho pensato che se avessi potuto valutare i pro ei contro e le bandiere rosse, sarebbe stato un buon modo per prendere una decisione.

Attualmente ho in mente, è la possibilità di separare qualsiasi HTML / CSS specifico del client dal codice base corrente in un repository separato, per cliente, per prodotto. Questo repository avrebbe quindi importato la libreria dell'interfaccia utente di base per ottenere gli stili relativi a ciascun componente.

Questo sarebbe il tipo di approccio che sto cercando per risolvere il mio problema precedente? Ci sono possibili bandiere rosse per questo approccio?

    
posta koramaiku 11.07.2016 - 07:25
fonte

1 risposta

0

Sì, sei sulla strada giusta. Il vantaggio più importante è che è possibile caricare una versione specifica della libreria per ciascun client. In questo modo puoi controllare gli aggiornamenti e il repository specifico del cliente mostrerà sempre la situazione reale per quel client.

Fondamentalmente puoi vedere la libreria come una libreria esterna.

Quindi, per dare un esempio specifico su chi potrebbe risolvere:

raccolta

  • V1.0 - Rilascio stabile
  • V1.1 - Aggiunto il nuovo componente in verde
  • V1.2 - Modificato il nuovo componente su rosso

Client repo 1

  • V0.1 - Utilizza V1.1 in modo che mostri un componente verde (tra il tempo qui il componente nella libreria è diventato rosso, ma NON avrebbe avuto impatto sul client)
  • V0.2 - Decidi di aggiornare la libreria alla V1.2, quindi ora il componente diventa rosso.

Questo è il vantaggio principale, tu, come sviluppatore del repository client, hai il controllo.

Anche questo funziona meglio con i test. Perché un aggiornamento nella libreria principale potrebbe interrompere il progetto client ma non ne verrai a conoscenza.

In uso quotidiano pratico

Tieni presente che stai modificando il flusso di lavoro della tua organizzazione. Va bene, fallo con cura e, soprattutto, comunicazione.

Questo cambiamento cambierà molto la routine quotidiana. Inoltre richiede alcune conoscenze su come utilizzare le versioni e caricarne una specifica.

Un altro potenziale svantaggio potrebbe essere che una nuova versione della libreria non viene automaticamente inviata a tutti i client. Potresti anche prendere in considerazione un semplice comando da riga di comando upgrade-lib, quindi è facile per gli sviluppatori eseguire rapidamente l'upgrade all'ultima versione sul loro computer locale.

    
risposta data 11.07.2016 - 10:02
fonte

Leggi altre domande sui tag