Since we’re heavy vim users, a development environment in the cloud makes
plenty of sense as a way to get rapid (and, importantly, asynchronous) feedback
from teammates on the product before the code.
While the primary benefit of a Development Platform as a Service is faster
product cycles, it has a few side benefits, too:
- Better parity between development, test, staging, and production.
- Ease the burden of setting up a laptop for development.
- Eliminate some differences in development environments (OS X vs. Linux, RVM
vs. rbenv, etc.), which are the source of bugs and lost debugging time.
- Facilitate easy pair programming.
- Piggyback on GitHub’s access control to the source code.
- Develop on Chromebooks.
- Pipe production traffic to development using em-proxy to debug performance.
Nitrous.io is the best Development Platform as a Service that we’ve found
so far. While still in alpha, we’ve noticed benefits such as:
- Simple to get started.
- Ubuntu machine seemed crazy fast.
- Our one roadblock was answered within 30 minutes by the founder in a chat room.
A few things needed work:
- They were a patch level behind on Ruby 1.9.3.
- Their tmux version was behind.
- Since their boxes don’t provide admin access, it didn’t seem possible to
upgrade tmux via
- It didn’t look like their “box templates” are open source.
Nitrous features an IDE that we don’t care about ourselves (we would always use
vim via SSH). However, the IDE could be a nice environment for teaching new
programmers like we used to on Heroku Garden.
The primary downside of a service like this is that it requires an internet
connection. 99% of the time, that shouldn’t matter. Read a book on those
Moving the development environment to the cloud presents an opportunity to
examine how external services should be set up differently to offload work done
by the development platform and to better match staging and production.
The most important external service is the SQL database. On Nitrous, we’re
experimenting with using Heroku Postgres. One potential benefit might be fast
production-to-development backups with PG Backups.
It seems like having a default
config/database.yml like the following could be
a nice separation of configuration and code:
database: <%= ENV['DEVELOPMENT_DATABASE_ID'] %>
host: <%= ENV['DEVELOPMENT_DATABASE_HOST'] %>
password: <%= ENV['DEVELOPMENT_DATABASE_PASSWORD'] %>
port: <%= ENV['DEVELOPMENT_DATABASE_PORT'] %>
username: <%= ENV['DEVELOPMENT_DATABASE_USER'] %>
database: <%= ENV['TEST_DATABASE_ID'] %>
host: <%= ENV['TEST_DATABASE_HOST'] %>
password: <%= ENV['TEST_DATABASE_PASSWORD'] %>
port: <%= ENV['TEST_DATABASE_PORT'] %>
username: <%= ENV['TEST_DATABASE_USER'] %>