Deploy Strategies
If you look at the network graphs of heroku_san on github, you'll see a number of branches where the only change is the deletion of the following line from the deploy task:
- stage.migrate
If more than a few people are willing to take the effort to fork a gem just so they can delete 1 line, something smells. The reason is that these forkers were using something other than Rails+ActiveRecord+SQL in their project. Some were using Sinatra, others were using Rails, but with CouchDB.
The raison d'être for the heroku_san gem is to make Heroku deploys dirt simple. So, if people are making whole forks to customize the deploy task, we should make it less painful.
One of the many pleasures of working at Pivotal Labs is that we are encouraged to release some of our work as open source. Often during the course of our engagements, we write code that might have wide-spread use. Due to the nature of our contracts, we can not unilaterally release such code. Those rights belong to the client. And rightly so. So, it is an even greater pleasure when one of our clients believes in "giving back" to the community, as well.
One such example is this modest gem, attribute_access_controllable which allows you to set read-only access at the attribute level, on a per-instance basis. For example, let's say that you have a model Person with an attribute birthday, which, for security purposes, cannot be changed once this attribute is set (except, perhaps, by an administrator with extraordinary privileges). Any future attempts to change this attribute will result in a validation error.
e.g.
> alice = Person.new(:birthday => '12/12/12')
=> #<Person id: nil, attr1: nil, created_at: nil, updated_at: nil, read_only_attributes: nil, birthday: "0012-12-12">
> alice.attr_read_only(:birthday)
=> #<Set: {"birthday"}>
> alice.save!
=> true
> alice.birthday = "2012-12-12"
=> "2012-12-12"
> alice.save!
ActiveRecord::RecordInvalid: Validation failed: Birthday is invalid, Birthday is read_only
> alice.save!(:skip_read_only => true)
=> true
Setting this up is trivial, thanks to a Rails generator which does most of the heavy lifting for you.
rails generate attribute_access Person
After that, you need only know about one new method added to your class:
#attr_read_only(*attributes) # Marks attributes as read-only
There are a few others, but this one, plus the new functionality added to #save and #save! will get you quite far.
And if that's all that you were looking for when you stumbled across this article, then there's no need to read any further. Go install the gem and have fun (and may your tests be green when you expect them to be).
Quiz time!
- How many times (each day) have you typed this at your console?
git push heroku masterand then forgotten to runheroku run rake db:migrate --app yellow-snow-3141orheroku ps:restart - Does your script support a multi-stage environments?
- Do you remember how to get to the application's console process?
- Is your application's configuration consistent across all stages?
- Are you deploy scripts tested?
If you're working in an environment with a noisy background, Skype's über-friendly automatic gain control can drive you crazy (open up sound preferences and watch your input levels change like magic)
Here's a fix (that still works in Skype 5):
http://jon.smajda.com/2011/04/19/disable-automatic-gain-control-in-skype
One of the thornier problems in our workflow is knowing when assets are delivered from the designer and keeping them in sync with our application as they change. We used to use e-mail, Skype or sticky notes. The trouble is that the designer's file naming and directory structure were never quite the same as the application's /public/images directory, so direct comparisons were impossible and we ended with a lot bookkeeping to make sure that we didn't lose any changes. Our solution is to clone the project's git repository into a folder inside a shared Dropbox folder.
Dropbox is cheap, if not free, available on all platforms, and synchronizes easily across most network connections. git is, well, awesome version control. We already had a Dropbox account set up for the project, and all team members had accepted invitations to join the share. We then made a git clone of our application source code in the Dropbox folder;
cd ~/Dropbox/MyProject
git clone https://github.com/myproject/myapp git-repository
We took a minute or 2 to show the designer how to find the images directory, and our basic rationale behind naming and directory structure. That became her "new" assets folder. We did not show the designer how to use git, nor do we need to. As far as she is concerned, it is just another folder. /public/images is even a familiar place for designers.
Here's where the fun starts: We add the Dropbox/git-repository as a remote to our main project repository.
cd ~/myapp
git remote add dropbox file:///Users/me/Dropbox/MyProject/git-repository
Now, as far as our main project is concerned, the Dropbox folder is another remote, just like github.
During our daily workflow, whenever we need a new asset, or to look for a changed one, we cd over to the Dropbox folder with the git repository, change into the /public/images directory and look for what we need. We then use git add to stage and commit only those assets that we need. Back in our main project, we then
git pull dropbox master
from the Dropbox remote and voila! New images! Later, if the designer makes changes, we can simply run git status to see what's changed, re-run git add, commit and pull. The only really gotcha is training our fingers not to type git commit -am '...'
We have found this to be a very fast, lightweight, way of integrating new assets into the project and keeping track of old ones. The designer is no longer worried about getting out of sync with our project, nor are we worried about missing design changes. As a bonus, there's a history in the git logs, so we can review changes and even revert if necessary. All this without the designer ever learning a single git command, nor us worrying about our project directory getting accidentally clobbered.