Setting your database setting in an environment variable makes sense, but can be a pain sometimes as it breaks Rails' assumptions. Check an easy way to get the best of both worlds.
Over the years I've gone to great lengths to avoid committing production passwords into version control. With Rails this has inevitably meant a number of different ways to ensure the
database.yml was where it needed to be on the production servers, with the right credentials. Custom Capistrano recipes to create a new config when setting up a server, moving it into place after a deploy, it worked well enough but it's always felt a little heavy.
Git comes with built in support for firing of a custom script before and after various commands. With a little forethought, you can leverage these to offer some amazing benefits to your workflow.
Agile development and project management is a bit of a buzz phrase, and has been for quite a few years. Truth is, in my experience very few places are able to make it work. The following is a summary of the things that places that "make it work" consistently do.
I’ve spent almost all of my career with something along the lines of “freelancer”, “consultant”, or “contractor” on my business cards and the forms HR departments make me sign. On the two occasions that hasn’t been the case I’ve been working for as part of a development team that was primarily developing solutions for external customers, or managing a team of contractors working on launching a start-up. So I’ve been really very fortunate to work across a really broad spectrum of clients and environments and with some brilliant people, which over time makes it easier to appreciate what works and what doesn’t.
Trying to work out which testing framework to use in ruby these days is simple, all the kids are using cucumber so you should too lest you want to be an outcast. It's all very great in theory, but how much is it really helping you?
If you've deployed a Rails app the chances are high that you've done it using Capistrano. Capistrano has come a long way, but it was originally designed back when we were all using SVN to manage our code. Times have changed, and we can make some significant improvements to the default process.
There are times when you've SSHed onto a remote server that you need access to another server, but you don't have your private key on the first server. You probably don't want to put your private key on there either, because there is another way.