Organizzazione di strumenti ad-hoc in una struttura Muti-Repo

Question

Organizzazione di strumenti ad-hoc in una struttura Muti-Repo

#1 da (1 voti)

4

Immagina di avere il seguente scenario. La tua organizzazione distribuisce alcune app core alla sua missione. Ad esempio, se si è Stack Exchange, questo potrebbe essere il server Web del cliente. Diciamo anche che ti iscrivi a qualcosa come la filosofia dell'app 12-Factor . Ogni app mantiene il proprio repository SCM, che funge da fonte canonica di verità. Potresti anche avere librerie org-wide che sono consumate da zero, una o più app e mantenere i propri repository SCM. Infine, l'app stessa può essere distribuita su molti siti diversi, ognuno con configurazioni potenzialmente diverse o un'infrastruttura sottostante.

Ok, ora la ruggine viene fornita con il modo in cui gestisci gli strumenti progettati per monitorare, analizzare o rilevare le anomalie con le esecuzioni di produzione delle app effettive. Lo scopo potrebbe essere per i motivi sysadmin (controllo dei messaggi di errore critici nei registri delle app), dati scientifici (analisi post-hoc del comportamento degli utenti), profilazione delle prestazioni, o qualche altra ragione.

Quali sono le migliori pratiche per l'organizzazione di questi strumenti nella struttura multi-repository della tua organizzazione. La domanda chiave è mettere questi strumenti con il repository principale dell'applicazione? (Ad esempio, aggiungi una nuova directory di primo livello chiamata tools/ al repository frontend-web-server ). Separate tutti gli strumenti per una data app in un singolo repository separato? (Ad es. Nuovo repository chiamato frontend-web-server-tools ) O creare un repository separato per ogni strumento specifico? (Ad esempio frontend-web-server-user-analysis , frontend-web-server-runtime-monitor , frontend-web-server-profiler )

Vedo alcuni argomenti validi su tutti i lati:

Gli strumenti potrebbero avere dipendenze abbastanza forti sul codice dell'app sottostante. Per esempio. se cambiamo il formato del registro dell'app, probabilmente anche quello che consuma quei log deve essere cambiato. Mantenerlo un unico repository riduce la possibilità di rompere gli strumenti sulle modifiche della base di codice.
Probabilmente lo stesso tooling si conforma a standard di ingegneria del software molto più sciolti, e molti strumenti possono essere creati su base una tantum o ad hoc e poi gettati via. Potremmo non voler inquinare il repository principale con questo.
Alcuni strumenti possono estendersi su più app. Ad esempio, per alcuni script di analisi della scienza dei dati potremmo voler unire attività nell'app front-end con i dati di un microservizio di supporto.
È probabile che lo stesso tooling tragga vantaggio da una base di codice condivisa. Se abbiamo uno strumento per fare X e uno strumento per Y, entrambi potrebbero aver bisogno di una logica per fare Z. Ovviamente DRY, quindi spesso vorremmo che strumenti simili fossero almeno nello stesso repo l'uno con l'altro.
Gli strumenti possono anche utilizzare il codice direttamente dalla base di codice dell'app. Forse abbiamo uno strumento che riproduce l'attività per alcuni ambienti di test. Potrebbe essere molto più semplice fare affidamento su un singolo modulo all'interno dell'app per evitare DRY. La compilazione dello strumento insieme al codebase dell'app è molto più semplice se condividono un repository. Sembra poco pratico forgiare un repository di libreria completamente separato solo per un repository.
Alcuni strumenti potrebbero essere specifici per la distribuzione. Non vorrai inquinare la base di codice dell'app con i dettagli di distribuzione.

Forse un singolo approccio non cattura tutte le idiosincrasie di diversi scenari plausibili. Ma in che modo le grandi organizzazioni in genere gestiscono situazioni come questa? O almeno come si avvicinano a prendere queste decisioni?

repository dry scm project-structure

posta user79126 03.03.2018 - 14:17

fonte

1 risposta

Leggi altre domande sui tag repository dry scm project-structure

Restituisce un 200 con anche informazioni sugli oggetti non validi quando si passa in una raccolta Buoni esempi per l'insegnamento della stima del software (dimensioni, programma, sforzo)? [chiuso]

score 1 · Accepted Answer

La tua intera domanda può essere risolta cambiando il punto di vista e non vedendo quegli "strumenti" come qualcosa di separato dall'applicazione principale, ma come parte o funzionalità dell'applicazione (anche se non sono funzionalità per l'utente finale , ma funzionalità per sviluppatori, amministratori o tester). Quindi le regole per la gestione degli strumenti non sono diverse dalle regole per qualsiasi altra funzione o componente all'interno della tua app.

Consentitemi di dimostrarlo commentando uno ad uno i vostri punti:

The tooling may have fairly strong dependencies on the underlying app code itself. E.g. if we change the app's log format, then anything consuming those logs probably also has to be change. Keeping it a single repo reduces the chance of breaking the tooling on codebase changes.

Gli strumenti che hanno una strong dipendenza dal codice dell'app in genere non possono essere riutilizzati al di fuori del contesto dell'app, quindi dovrebbero far parte del codebase e del repository dell'applicazione. Quindi fai una chiara distinzione tra tali strumenti e altri che puoi riutilizzare altrove.

The tooling itself probably conforms to much looser software engineering standards, and a lot of tools may created on a one-off or ad-hoc basis then thrown away. We may not want to pollute the main repo with this.

Non lo vedrei come un problema quando gli strumenti di recupero entrano nel repository principale per un breve periodo di tempo - se sono davvero strumenti da buttare via, non resteranno a lungo lì, giusto? Tuttavia, se risultano non essere gettati via e devono essere mantenuti per un periodo più lungo, renderli conformi ai tuoi standard ha senso. Ma se i tuoi standard di ingegneria del software non si adattano a tali strumenti o "funzionalità interne all'applicazione", potresti ripensare ai tuoi standard.

Some of the tooling may span multiple apps. For example for some data science analytics script we may want to join activity in the front-end app with data from a backing microservice.

Il tuo link alla app a 12 fattori dice tutto: raccomanda di scomporre il codice condiviso in librerie che può essere incluso tramite il gestore delle dipendenze . E il codice condiviso per gli strumenti non è in alcun modo diverso da qualsiasi altro codice riutilizzabile.

The tooling itself is likely to benefit from a shared codebase. If we have a tool to do X and a tool to Y, they may both need some logic to do Z. Obviously DRY, so we often we probably want similar tools to at least be in the same repo with each other.

Puoi mettere strumenti generici e riutilizzabili in un repository separato quando coprono le stesse tematiche (proprio come non dovresti mettere cose arbitrarie in una libreria). Ma se quegli strumenti X e Y sono strumenti specifici delle app, e Z è uno strumento / componente condiviso, X e Y dovrebbero trovarsi nel repository dell'app e Z nel proprio.

The tooling may also consume code directly from the app's codebase

Se ciò significa che lo strumento deve essere modificato in modo specifico per l'app, allora appartiene alla base di codice dell'app. Se questo porta a una situazione in cui un'intera libreria riutilizzabile deve essere biforcuta / copiata, allora c'è qualcosa di sbagliato nel modo in cui la libreria può essere configurata. Dovrebbe esserci una strong separazione tra la parte generica, riutilizzabile (che viene mantenuta nel repository esterno) e la parte di configurazione creata appositamente per l'app (e questa configurazione dovrebbe trovarsi nel repository dell'app).

Some of the tooling might be specific to the deploy. You wouldn't want to pollute the app codebase with deploy details.

Gli strumenti per la distribuzione di un'app specifica appartengono a quell'app, non lo vedo come un "inquinamento della base di codici", al contrario. Ovviamente, gli strumenti di distribuzione dovrebbero avere le proprie cartelle all'interno della struttura di cartelle del codebase.