condivisione del codice ruby ??all'interno di un'organizzazione

Question

Io e il mio team stiamo iniziando a creare alcuni script riutilizzabili. Sono riutilizzabili all'interno della nostra organizzazione solo quando funzionano con app proprietarie e il nostro particolare ambiente server. Quindi non adatto a rubyforge o github, ecc.

La mia domanda è: qual è la migliore pratica per garantire che tutti usiamo gli script più recenti e migliori tra tutti gli utenti? Praticamente eseguiamo questi script su un server, ma potrebbe essere necessario espanderci ad altri.

Dovremmo raggrupparli in gem (s) e avviare un server gem privato?

O qualcosa di più semplice come una directory lib comune e condivisibile. Forse con uno script da scaricare / aggiornare dal nostro SCM?

Altre idee?

Grazie ....

Answer 1

Questo dipende da alcuni fattori, come quante persone vogliono cambiare il codice (solo la tua squadra o qualcun altro) o quanti soldi hai per questo?

Personalmente creerei un server build + gem, dove è possibile caricare gli script usando un sistema di controllo delle versioni (come git o svn, dipende da quante persone stanno lavorando al progetto), e quindi creare un lavoro cron, che genererebbe automaticamente le gemme dalle fonti a intervalli generici e le memorizzerebbe come versioni diverse. In questo modo puoi essere sicuro di avere sempre un server autorevole che memorizza le gemme delle tue applicazioni e puoi sempre ottenere una versione precedente in caso di problemi. Il tuo script potrebbe creare nomi di versione gemma separati, come " appserv-edge " o " appserv-stable "

Potresti anche voler controllare anche le opzioni a fonte chiusa di github, se hai i soldi per permettertelo. Non so comunque se abbiano gemma e strutture di hosting per programmi non open source.

Answer 2

Ho creato un gemserver privato ed è molto semplice. L'unica cosa difficile è decidere come desideri che i tuoi utenti caricino le gemme. Personalmente, uso solo un modulo di caricamento PHP e lo controllo per assicurarsi che non stia mascherando gemme esistenti.

Answer 3

Nel mio ufficio stiamo usando un approccio un po 'ibrido per alcuni dei nostri script e librerie condivisi. Li raggruppiamo tutti in una gemma, ma invece di usare un gem server li manteniamo nel controllo del codice sorgente, quindi costruiamo la gemma (usando newgem) e la installiamo localmente se necessario.

Il rovescio della medaglia di questo approccio è che sono necessari due comandi anziché uno per installare la gemma, ma ciò è ampiamente mitigato in qa e ambienti di produzione, poiché utilizziamo Capistrano per la distribuzione.

I lati positivi sono che è semplicissimo, e nello sviluppo c'è un ciclo di modifica / costruzione / distribuzione molto breve se stai lavorando con qualcosa che richiede modifiche alla gemma. Attualmente sto inserendo molte funzionalità comuni nella gemma condivisa, quindi apprezzo molto questo aspetto.