Extra layer a causa della mancanza di controllo

2

Stiamo utilizzando Git e vogliamo aggiungere un hook post-ricezione lato server che invii eventi al nostro sistema di tracciamento dei bug.

Nella nostra azienda, il server Git è gestito dall'IT e il server del sistema di tracciamento dei bug è gestito da noi, sviluppatori. Poiché gli sviluppatori non hanno accesso ai server IT, se apportiamo aggiornamenti al git hook, dobbiamo chiedere all'IT di caricare la nuova revisione. Qualcuno suggerisce che, per evitare di infastidire l'IT, l'hook, invece di eseguire una logica complessa, passa semplicemente i parametri grezzi a un livello intermedio gestito da noi, e il middle layer esegue la pesante transizione e la logica complessa, quindi pubblica gli eventi sull'endpoint dell'API del sistema di tracciamento dei bug, come illustrato dal flusso rosso nella figura.

Sei d'accordo è una buona strategia? Ritengo che lo strato intermedio aggiunga costi di manutenzione, ma ci dovrebbe essere qualche soluzione alla mancanza di controllo del server IT. Come gestirai questa situazione?

Non so quali tag appropriati siano per questa domanda. Sentiti libero di aggiungere.

    
posta Gqqnbig 08.01.2018 - 23:04
fonte

2 risposte

4

Mentre evitare di infastidire l'IT è una scarsissima ragione per aggiungere il livello di astrazione, evitare di mettere la logica complessa in un hook è una buona ragione. Prendi Github come buon esempio. I loro webhooks sono molto semplici, e se hai creato un middle layer per Github, sarebbe abbastanza semplice modificarlo per lavorare con Bitbucket, o GitLab, o qualsiasi altra cosa si possa spostare in futuro. In particolare, Github era solito accettare hook più complessi chiamati servizi , ma ora supportano solo i servizi legacy.

Inoltre, se il tuo bug tracker non è homegrown, l'uso del modello a gancio minimo significa che è probabile che tu possa trovare plugin di terze parti per il tuo bug tracker che già fanno ciò che vuoi. In altre parole, il tuo middle layer sarebbe un plugin per il tuo bug tracker invece di un'entità completamente separata.

    
risposta data 09.01.2018 - 00:28
fonte
3

La soluzione migliore è ancora lavorare con l'IT per trovare la soluzione migliore. Possono darti permessi per gestire i ganci per i tuoi repository. Possono impostare WebHooks per rendere l'approccio più dinamico.

Se sei in un caso sfortunato in cui sei una piccola squadra in una grande azienda in cui l'IT non si preoccupa delle tue esigenze, perché non hai la tua parola quando arriva per il loro budget, quindi, in effetti, il livello di indirezione che hai immaginato potrebbe risolvere il problema.

In questo caso, assicurati di mantenere l'interfaccia tra SGitHub (o qualsiasi altra cosa tu usi) e il livello intermedio il più semplice possibile, e fai molta attenzione a progettarlo bene da zero, poiché rendere l'IT modificare qualcosa più tardi sarebbe probabilmente molto difficile. Questo può sembrare semplice, ma non lo è. Anche decidere dove e come verrà ospitato il tuo middle layer non è una scelta facile, così come l'URI che sarebbe usato da SGitHub per contattare il tuo middle layer.

    
risposta data 09.01.2018 - 00:24
fonte

Leggi altre domande sui tag