Heroku utiliza la base de datos PostgreSQL y una URL en una variable
de entorno ENV['DATABASE_URL']
.
configure :development, :test do DataMapper.setup(:default, "sqlite3://#{Dir.pwd}/development.db") end configure :production do DataMapper.setup(:default, ENV['DATABASE_URL']) end
Estas líneas especifican que se usa SQLite en desarrollo y testing y
PostgreSQL en producción.
Obsérvese que el Gemfile
debe estar coherente:
[~/sinatra/sinatra-datamapper-jump-start(master)]$ cat Gemfile source 'https://rubygems.org' gem "sinatra" gem "slim" gem "sass" gem "dm-core" gem "dm-migrations" gem "thin" gem "pg", :group => :production gem "dm-postgres-adapter", :group => :production gem "dm-sqlite-adapter", :group => [:development, :test]o mejor:
group :production do gem "pg" gem "dm-postgres-adapter" end group :development, :test do gem "dm-sqlite-adapter" end
By default, bundle install will install all gems in all groups in your
Gemfile, except those declared for a different
platform
46.1.
However, you can explicitly tell bundler to skip installing certain
groups with the --without option
.
This option takes a space-separated list of groups.
While the --without
option will skip installing the gems in the specified groups,
it will still download those gems and use them to resolve the dependencies of every gem in your Gemfile.
This is so that installing a different set of groups on another machine (such as a production server) will not change the gems and versions that you have already developed and tested against.
Bundler guarantees that the third-party code you are running in development and testing is also the third-party code you are running in production. You can choose to exclude some of that code in different environments, but you will never be caught flat-footed by different versions of third-party code being used in different environments.
For a simple illustration, consider the following Gemfile
:
source "https://rubygems.org" gem "sinatra" group :production do gem "rack-perftools-profiler" end
In this case, sinatra
depends on any version of Rack (>= 1.0)
,
while rack-perftools-profiler
depends on 1.x (~> 1.0)
.
When you run bundle install --without production
in development
, we
look at the dependencies of
rack-perftools-profiler
as well.
That way,
you do not spend all your time developing against Rack 2.0
,
using new
APIs unavailable in Rack 1.x
,
only to have bundler switch to Rack 1.2
when the production
group is used.
This should not cause any problems in practice, because bundle does not attempt to install the gems in the excluded groups, and only evaluates them as part of the dependency resolution process.
This also means that you cannot include different versions of the same gem in different groups, because doing so would result in different sets of dependencies used in development and production.
Because of the
vagaries of the dependency resolution process, this usually affects
more than just the gems you list in your Gemfile
,
and can (surprisingly) radically change the gems you are using.
heroku create ...
git push heroku master
heroku open
heroku logs --source app
Ahora ejecutamos la consola de heroku:
heroku run consolelo que nos abre una sesión
irb
.
Ahora creamos la base de datos en Heroku:
[~/sinatra/sinatra-datamapper-jump-start(master)]$ heroku run console Running `console` attached to terminal... up, run.8011 irb(main):001:0> require './main' => true irb(main):002:0> DataMapper.auto_migrate! => #<DataMapper::DescendantSet:0x007fb89c878230 @descendants=#<DataMapper::SubjectSet:0x007fb89c8781b8 @entries=#<DataMapper::OrderedSet:0x007fb89c878190 @cache=#<DataMapper::SubjectSet::NameCache:0x007fb89c878168 @cache={"Song"=>0}>, @entries=[Song]>>> irb(main):003:0>Véase también la práctica TicTacToe 33.28 y el capítulo Despliegue en Heroku 52.