2009-06-18 13 views
9

Ammetto che non seguo molto di tutto "giusto" sulla distribuzione del test rispetto al codice di produzione. Ho utilizzato ASP.NET e di solito lo eseguo localmente in Visual Studio, funziona, lo carico, lo sottopongo nuovamente al test sul server di produzione.Perché è presumibilmente "difficile" distribuire Ruby on Rails alla produzione?

Ho letto molte persone dicono che la distribuzione di applicazioni Rails è più difficile e ci sono programmi speciali/modi sul sito rubino sulla distribuzione di RoR. Ho solo giocato con RoR. Cosa c'è di speciale nella distribuzione? Non basta copiare e incollare il codice ed eseguirlo (dalla macchina di sviluppo alla produzione)? È perché uno è in Apache e l'altro in esecuzione sul server integrato?

Questo sarà su un Mac Server se è importante.

risposta

15

Distribuzione di RoR non è difficile più, soprattutto con Phusion Passenger.

Ciò che è un po 'difficile, è ottenere un ambiente di produzione automatizzato con capistrano, vlad, ecc. Se non ti interessa semplicemente copiare il codice sul server, puoi farlo bene. La maggior parte delle persone sceglie di non farlo in quel modo perché si perdono molti dei benefici che gli strumenti di distribuzione automatizzati offrono.

+2

Ulteriori risorse sono disponibili su http://rubyonrails.org/deploy –

+1

Uso addirittura capistrano per configurare un nuovo account rails per la distribuzione automatica. Quindi dico "cap setup: fresh" e questo si occuperà di tutto come impostare un testurl, impostare un gitrepository locale e sul mio server di origine, effettuare il commit iniziale, impostare un nuovo vhost e così via .. . –

0

Non è particolarmente difficile. Se rispettate le convenzioni poi con un po 'di configurazione si riduce a questo:

cap deploy 

... tuttavia c'è a volte un po' di sforzo necessario in anticipo per ottenere il flusso di lavoro in atto.

La buona notizia è che un sacco di persone hanno confezionato su soluzioni e pile per RoR che si può solo plug and play. Ad esempio, google ec2onrails - questa è un'immagine di Ubuntu e una serie di compiti capistrano per l'esecuzione di app di rails nel cloud EC2 di Amazon, con un sacco di elementi comuni configurati già fuori dalla scatola.

Scegli un buon provider di hosting e dovresti riuscire a trovare qualcosa di simile anche per quello.

0

Un modo semplice per distribuire applicazioni Rails è quello di utilizzare Phusion Passenger. La distribuzione non è molto più semplice di quella per qualsiasi linguaggio o framework di programmazione. Puoi farlo su un server Mac.

7

Credo che la gente considera un'applicazione Rails più difficile da implementare rispetto dire alcune applicazioni PHP o tali in cui basta plop il codice da qualche parte e puntare Apache o qualsiasi altra cosa a questo. Ma, come detto sopra, ora puoi farlo con Phusion Passenger.

Usiamo Nginx + passeggeri, ma non per la semplicità di implementazione. Capistrano è il nostro strumento di distribuzione preferito e, in realtà, a meno che tu non abbia un'app molto semplice, vorresti comunque qualcosa come Capistrano. Ad esempio, con il nostro Deploy, facciamo un gran numero di cose:

  • run eventuali migrazioni di database
  • generano note di rilascio automatico, sulla base di tutti i commit al GIT tra l'ultima implementare e questo
  • notificare varie persone via email (con elenchi diversi a seconda che l'implementazione sia per il nostro ambiente di staging o produzione) - lo facciamo tramite cap_gun che si integra con Capistrano.
  • Notifica nuove Relic RPM del deploy in modo che possa segnare nella nostra analisi RPM
  • Segnalatemi Hoptoad del deploy, in modo che possa avere anche che i dati quando si segnalano le eventuali eccezioni
  • produrre i nostri file di sitemap.xml, e ping Google per dirgli che ce n'è uno nuovo
  • aggiorna i file crontab (memorizzo i nostri file crontab per ogni server nel nostro repository git, e poi sul deploy vede se c'è una nuova versione e gli aggiornamenti di conseguenza, ecc.).
  • a filo/riavvio memcached

Ci sono altri modi oltre a Capistrano, ma è uno strumento collaudato, con un sacco di flessibilità, ma abbastanza semplice da configurare una configurazione di vaniglia.

Quindi, la mia opinione è che una volta entrati in qualsiasi app che è al di là solo delle app più semplici, avrete bisogno/volete fare cose diverse dal semplice aggiornamento del codice. All'inizio però, se hai solo bisogno degli aggiornamenti del codice e forse delle migrazioni di Rails, allora puoi fare cose più semplici come Passenger e code sync, o guardare strumenti come Heroku o Engine Yard dove eseguono una distribuzione facendo un clone Git (e quindi offrire alcune abilità aggiuntive).

0

Un altro modo davvero semplice per installare le guide è con jruby e la gemma del glassfish.

4

Un altro modo super facile da implementare è con http://heroku.com/

+0

Heroku è impressionante, ho iniziato ad usare per un paio di settimane ed è stata una gioia completa per lavorare con – Jimmy

+13

dispiaciuto per il downvote, ma ogni volta che ho letto rotaie sulla distribuzione e qualcuno suggerisce Heroku, non posso fare a meno di pensare "sì , heroku è un modo semplice per implementare ON HEROKU ". heroku è un servizio, non un modo universale di distribuire un'app _everywhere else_, su vps, server propri e così via. – pistacchio

0

Alcune delle questioni da affrontare con la distribuzione di rotaie per la produzione:

  • connessione al database. È necessario accertarsi che il connettore del database sia impostato per l'ambiente di produzione.

  • Migrazioni di database. È necessario eseguire le migrazioni del database sul database di produzione anche se potrebbero essere già state eseguite in produzione/test/staging

  • Versione rubino. La versione o sottovoce o Ruby possono farti inciampare, ad es. An error occurred while installing debugger-linecache (1.1.1), and Bundler cannot continue

  • Dipendenza da gemma. L'ambiente di produzione può avere diversi pacchetti e gemme dallo sviluppo. Bundler lo individuerà per la maggior parte e installerà le dipendenze, ma a volte ci sono ancora problemi che è necessario risolvere manualmente.

  • Dipendenze. Alcune gemme su alcune macchine hanno dipendenze particolari. Ho visto frequenti problemi con l'utilizzo di gem sulla mia casella unix che funziona su OSX e viceversa.

Nota l'ultimo 3 non dovrebbe influire se sulla stessa macchina ma li ho inclusi in base al titolo e per essere completo.

+0

Non l'ho mai usato. Era solo l'hype al momento. Con il passare del tempo ha perso popolarità, imho, quindi non ho potuto trovare una ragione per usarlo diverso da RoR. Non ha necessariamente gradito il RoR e la convenzione sulla configurazione (penso che fosse RoR). Grazie. – johnny