Eseguire una versione personalizzata di un'applicazione Rails

Question

Ecco i nostri requisiti di base:

• Abbiamo un'applicazione di base Rails, che è mantenuto attivamente.
• Vogliamo offrire una versione personalizzata di questa app, dato che:
  • i server devono risiedere nella premessa dei nostri clienti ed essere eseguiti su un dominio diverso.
  • c'è una specifica strumentazione di registrazione per il proprio monitoraggio nel datacenter.

Per fare questo, posso vedere diverse opzioni per raggiungere tale obiettivo:

• Git ramo
• Rails::Engine
• Rails::Application

La risposta più ovvia sarebbe essere filiale Git, per la massima flessibilità.

Tuttavia, non sono sicuro che sia una buona idea, perché la base di codice è ampiamente condivisa e la linea principale ha molte più attività: recuperare rebase/merge potrebbe essere un problema in più.

Vogliamo dividere il più possibile l'originale e le versioni personalizzate. In altre parole, vogliamo avere il minor numero possibile di conflitti tra l'originale e il personalizzato.

Rails::Engine o Rails::Application sembrava una stretta idea (io non sono a conoscenza Rails motori), ma non capisco come avere OurApp::Application e OurCustomizedApp::Application in un posto e passare da uno all'altro a livello globale e in modo dinamico.

Probabilmente sarebbe bello avere:

• personalizzati inizializzatori, controller e punti di vista in una directory separata per ignorare (o patch) l'originale
• possibilità di specificare quale app (l'originale o la misura) per l'avvio da una variabile di ambiente come RAILS_APP
• file di configurazione separati, in questo modo: config/database.yml essere config/customer1/database.yml
• possibilità di utilizzare lo stesso deploy.rb per capistrano (p robably con config/servers.yml e config/customer1/servers.yml per definire ruoli e IP?)

C'è pratiche/convenzioni per le nostre esigenze? Qualche consiglio?

Le nostre app funzionano su Ruby 1.9.2 + Rails 3.0.3.

UPDATE

Abbiamo iniziato come un ramo Git. Abbiamo creato un'attività rake per generare un file allo config/branch che include testo come "master" o "personalizzato" e application.rb lo legge su bootstrap.Le configurazioni come database.yml o servers.yml ora vivono in config/mainline/ o config/customized/ e application.rb le gestisce di conseguenza.

config.paths.config.database = "config/#{branch}/database.yml" 

Non perfetto, ma abbastanza buono per ora. Aggiornerò quando troveremo un modo migliore per farlo.

Answer 1

So che non è la risposta precisa che cerchi, ma credo che Git sarà il meno lavoro, e il più facile da gestire, a lungo termine, dalla personalizzazione dell'app e dall'aggiunta di logica per gestire il ulteriori file di configurazione, modifica dei file di distribuzione e anche gestione dei (potenzialmente) nuovi file css/js/modello.

Utilizzando l'unione & l'unione sarà molto meno soggetta a errori, e fintanto che manterrai i tuoi rami sincronizzati su base regolare, non dovresti avere problemi seri a mantenerli entrambi aggiornati. Dopotutto, questo è ciò a cui Git è bravo! ;)

Answer 2

Usiamo Git per farlo abbastanza spesso.

Answer 3

Penso che l'approccio migliore sia farlo alla vecchia maniera.

Per prima cosa, aggiungere una classe singleton al progetto (in /lib) chiamata qualcosa come Affiliate. Questa classe dovrebbe fornire implementazioni predefinite (qualunque cosa tu voglia usare la tua applicazione di base) per qualsiasi parte dell'applicazione che possa essere personalizzata. A questo punto, l'applicazione funziona allo stesso modo, ma ha i ganci per consentire la personalizzazione.

presso la sede del cliente, distribuire lo stesso codice sorgente (spediti come una gemma, forse?), Ma anche distribuire un plugin Rails che prevale Affiliate così il suo metodo Singleton instance restituisce una sottoclasse personalizzata che fornisce informazioni o comportamenti specifici del cliente .

Modificato per aggiungere: Il rischio con questo approccio è che gli sviluppatori inavvertitamente si rompono perché testano solo le loro modifiche contro l'affiliazione predefinita. Dovresti utilizzare test automatici e integrazione continua per capirlo.

Answer 4

Sembra che tu abbia due requisiti interessanti qui. Chiedi come avere due applicazioni separate e passare da una all'altra in modo dinamico. Suppongo che tu voglia cohosting di diverse 'versioni' della stessa applicazione e che l'app passi a diverse personalizzazioni basate sul dominio. Tuttavia questo è molto diverso da dire usando i rami Git per distribuire due diverse applicazioni.

Potete chiarire le vostre esigenze qui?

Non consiglierei le filiali Git come soluzione qui. Consiglierei di usare i motori. Soprattutto raggruppando il tuo motore in un gioiello.

Includere la gemma nel progetto personalizzato e quindi utilizzare i metodi tradizionali di sovrascrittura delle funzionalità in un motore. Puoi anche utilizzare i metodi tradizionali di estendere il codice Ruby esistente per sovrascrivere le funzionalità nel tuo gioiello.

In questo modo si mantengono tutte le differenze presentate in un progetto separato. Questo progetto separato avrà anche il proprio set di test, ecc.