if you have to setup a foodsoft test/development machine the next time
you can use a vagrant box to better isolate the development environment
from you computer's environment. This is also very useful if you have no
*nix machine to work with (windows for example).
Vagrant grabs an ubuntu image from vagrantcloud, loads it into your
local vagrant registry and starts a new virtual machine with it. After
booting the first time the litte shell script is running, which installs
ruby, mysql, redis and setups the rails databases. The foodsoft app code
will be mounted within the container, so you can use your normal editor,
favourite shell etc. The app itself will be running inside the
container, with all it's dependencies isolated from your machine.
Save the Vagrantfile to your foodsoft app root dir and bootstrap a new
ubuntu container with 'vagrant up --provider lxc'.
After that you can ssh in the container via 'vagrant ssh', navigate to
the synced foodsoft dir 'cd foodsoft' and start the rails server with
'bundle exec rails s'.
vagrant will foward the ports 8000 to the container's 3000. So you can
access the foodsoft in your browser on http://localhost:8000.
To access mailcatcher you have to start mailcatcher with --http-ip
0.0.0.0, otherwise mailcatcher can't here you from outside. Acces
mailcatcher from your browser on http://localhost:8030
In order to get the integration test working (there is no firefox in the
container available), I replaced webkit-selenium with poltergeist, which
provide a pull request next week.
Please tell me, if you have some problems. I am no expert in vagrant,
but found it very usefull to share development setups between team members.
Besides, as I run the test, my schema.rb was updated. @wvengen, do you
use postgres or sqlite as main development database?
Hi Benni, thanks for sharing this with us. Please feel free to put
this on the wiki, so that developers can easily find it in the
future. Else I'll link to the
thread from a wiki page.
Regarding the schema - I'm having a hard time keeping it up-to-date,
because I'm working on a number of different versions with different
database schemas. Usually I manually add the schema changes. Perhaps
we could add a check in Travis-CI doing migrations from zero (or
from a known-good schema version, e.g. by commit-ish) gives the same
schema (bonus points for opening a pull request automatically). I'm
using MySQL for development.