Dunque, vi illustro la mia situazione:
ho appena terminato di scrivere la prima versione della mia wep app
utilizzo rails 3.2 in locale, in development, con sqlite3 (quello
standard
insomma)
Vorrei fare il mio primo deploy su Heroku, ma da quanto ho capito dovr
necessariamente cambiare db (postgre?)
La soluzione ottimale secondo me, sarebbe mantenere l’ambiente di
development che ho in locale cos com’, ma quando faccio il deploy,
passare in production e cambiare il db per heroku!
Non so se possibile e come devo fare, al momento mi sto leggendo la
documentazione sul sito di Heroku, su come implementarlo e come fare…
ma!
Se avete qualche preziosa guida/dritta da condividere che magari faccia
esattamente quello che chiedo, non sarebbe male!
We strongly recommend against doing this. Your production and
development
environment should be as close to identical as possible. This prevents
difficult to diagnose bugs introduced by subtle differences between your
environments. Every application on Heroku comes with a PostgreSQL database
as the default SQL database. Therefore you should use PostgreSQL for your
local development database as well.
Qual’ il vostro parere? Io non so, mi sembra intelligente usare il db di
default di RoR durante il dev, ma forse mi faccio troppi problemi…
Il giorno 25 gennaio 2012 09:55, Giovanni C. [email protected]ha scritto:
Ti consiglio questa lettura: http://www.12factor.net/
Al punto dieci recita: Keep development, staging, and production as
similar
as possible.
Questa un’ottima regola, che per bisogna contestualizzare: ActiveRecord
offre un buon livello di astrazione dei database, quindi, in teoria, non
dovrebbe riservare brutte sorprese in fase di deploy (passaggio da
SQLite a
PG). Il punto conoscere la propria applicazione: se si usa SQL non
standard, indicizzazione tramite Sphinx o Solr etc… bisognerebbe usare
lo
stesso database in tutti gli ambienti.
Qual’ il vostro parere? Io non so, mi sembra intelligente usare il db di
default di RoR durante il dev, ma forse mi faccio troppi problemi…
in generale, usare SQLite in development, pu essere comodo e molti
adottano
questo approccio. tuttavia, come sottolineato anche da Heroku, il db
dovrebbe
essere il pi vicino possibile all’ambiente di produzione, per evitare di
trovare brutte sorprese senza capire per quale motivo non si verificato
prima.
per esperienza personale, tutte le volte che ho usato SQLite in
development,
prima o poi spuntava qualche problema nel momento in cui si passava al
db di
produzione, principalmente perch SQLite non rigoroso con i dati quanto
un vero db.
userei SQLite solo per stendere un prototipo al volo, una demo, o
cazzeggiare
con il codice. ma se sto sviluppando qualcosa di vagamente serio, non lo
prendo
in considerazione nemmeno per la fase di sviluppo.
guarda che non sei obbligato ad usate il PgreSQL, se dai un’occhiata
negli addons trovi il ClearDB (mysql) con un piano free. Puoi farti
anche un account con Xeround (proprio oggi hanno lanciato il piano free
anche loro) ma personalmente ho avuto problemi con ques’ultimo.
il fatto che io postgre non lo conosco, ma cmq dovrei utilizzare SQL
standard, e per ora l’applicazione che sto sviluppando pi per un
prototipo o come dice Andrea P.: un cazzeggiare con il codice
Quindi direi che per questo progetto mi tengo sqlite in dev, poi vedremo
Il giorno 25 gennaio 2012 10:14, Luca G. [email protected] ha
scritto:
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
