Using unicorns USR2 signal to restart does NOT re-read your unicorn config so be very careful with Capistrano deployments. See SO Q&A for details below:
Additionally you should specify several things in the config file, specifically the gemfile, or it won’t reload that either.
APP_ROOT = DIR
ENV['BUNDLE_GEMFILE'] = DIR/Gemfile
*”1 git repo, 2 Heroku apps, 2 procfiles? Heroku currently is limited to 1 procfile per repo, so we’ve created a rake task that branches, modifies the procfile and pushes. Do you have a better solution?”
Is it possible to use env variables to parameterize your Procfile?
“Capybara: How can I click on a flash dialog for webcam settings?”
This was solved by right clicking and going into flash settings and enabling this permission always for this domain. Setting this up on headless CI may be more difficult.
“I have CSS transitions that behave differently when ‘user initiated’ vs initiated from a setTimeout or other event.”
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.
Strategies are an object oriented programming pattern for creating pluggable execution control. Now, there is a new class of objects that inherit from HerokuSan::Deploy::Base. These objects control how deploys are executed for you. The Rails strategy, HerokuSan::Deploy::Rails does exactly what HerokuSan has always done:
On the other hand, the Sinatra strategy, HerokuSan::Deploy::Sinatra does nothing more than the base strategy:
You can create your own strategies and then configure HerokuSan to use it instead of its default:
Amend your Rakefile:
require 'heroku_san'
class MyStrategy < HerokuSan::Deploy::Base
def deploy
super
# call my own code to do something unique
end
end
HerokuSan.project = HerokuSan::Project.new(Rails.root.join("config","heroku.yml"), :deploy => MyStrategy)
Amend your Rakefile
require 'heroku_san'
class MyStrategy < HerokuSan::Deploy::Base
def deploy
super
# call my own code to do something unique
end
end
config_file = File.join(File.expand_path(File.dirname(__FILE__)), 'config', 'heroku.yml')
HerokuSan.project = HerokuSan::Project.new(config_file, :deploy => MyStrategy)
load "heroku_san/tasks.rb"
git push heroku master and then forgotten to runheroku run rake db:migrate --app yellow-snow-3141 orheroku ps:restartEnter heroku_san, the 85% solution, which allows me to do this:
$ rake staging deployAnd this is what happens: Maintenance mode is turned on; the latest green build is deployed to my staging server; all pending migrations are run, the app restarted, and then maintenance mode disabled. All while I go get a fresh cup of joe.
The value for us is that we don’t repeat ourselves, that our app will deploy, and we are confident that extending the toolkit is easy with a clear API and good test coverage. That’s a big win when you have dozens of apps deploying all day long.
Installation is pretty simple; add gem 'heroku_san' to your Gemfile (you are using Bundler, aren’t you?). This gem is only used locally, so you can add it to your group :development, :test block. Then create and edit a configuration file; config/heroku.yml[1]. The README file has more details and there’s a wiki on github with handy tips on how to extend the basic functionality in common ways.
The gem has been around since 2010 and supported by a loyal core of maintainers. Version 2.1.1 brings changes large and small.
The biggest change since v1.3 is the creation of 2 new classes: Project and Stage, and a test suite to drive out the features. The task library is now almost entirely simple method calls, so there’s a lot of confidence that they will run correctly. Just to make sure, however, I’ve written an integration test, remote.feature which exercises the whole stack by creating an app on Heroku and run it through its paces. It’s worth a read.
There are some other new features worth highlighting:
heroku.yml file, heroku_san will deploy only the most recent revision with that tag to your stage. This is great for creating a multi-stage environment, and when combined with auto_tagger and a continuous integration server (CI), you get a lot of bang for a little bit. See the wiki for more complete instructions.Why write your own deploy scripts, again. Use heroku_san (or another gem like kumade)
[1]: I am working hard to remove the Rails dependencies.
“What’s the best admin gem out there?”
- I’ve used typus and it’s great, https://github.com/fesplugas/typus
- I know Erik Michaels-Ober has a good admin gem, https://github.com/sferik/rails_admin
- Active scaffold isn’t admin specific but that could work
“Amazon Web Services is down”
This is one of the longest outages we’ve seen of Amazon and thus Heroku. So many Ruby applications rely on Heroku that the community is certainly affected. Updates on the damage are on Heroku and Amazon. You can see how far reaching problems on EC2 are on ec2disabled.com
“Obama is in town!”
There have been rumors he is visiting a few notable software companies in the area, hopefully he’ll stop by. Watch out for blocked streets for the motorcade.
Some pivots are having trouble with a flash embed tag’s scale attribute. The desired behavior is that the movie scale to fit the size of the element. According to documentation, this should just work. The flash content will not scale, instead the content is getting cropped.
Anyone have experience using Amazon RDS with Heroku?
Several projects at Pivotal have used this combination with great success.
--deployment switch is being stripped off and Gemfile.lock is rebuilt. If the file differs from what’s in the git repository, the deploy will fail with a somewhat mysterious error message. Work-around: Specify the bundler gem version to v1.0.3 (perhaps even up to v1.0.5) in your Gemfile.
bundle install --without test excludes the test group in your Gemfile from the install. It works well for reducing the size of your Heroku slug. However, there’s a glitch with this option on Heroku — when you specify it, Heroku reinstalls every included gem every time you deploy. It does respect your Gemfile.lock, so you’re trading a smaller slug for a longer deploy.
Pivotal’s open source CIMonitor project now supports OpenID! Thanks Tyler and Josh.
Arel has a bug that makes it difficult to use in rails console. Every time you add a predicate, the number of internal objects in the Arel result increases exponentially. So, by the time you have 5 or 6 predicates, the console finishes generating the expression more or less instantly, and then spends 15+ minutes calling to_s on the resulting Arel object in order to display it to you. tl;dr: when you’re playing with Arel in rails console, end every line with ; nil to avoid having it print out the result. The exponential object explosion will be fixed in Rails 3.1.
I’ve been wanting to use Pivotal Tracker on my iPhone, so I wrote a little proof of concept using the Tracker API. I thought that a native application would be much more difficult than a skinned web application using ActiveResource.
I tried out Dashcode, Apple’s recommended iPhone-compatible front-end web development tool, but was disappointed. I basically found myself developing the entire application in javascript, actually using XMLHttpRequest to talk directly to the API. This would have been pretty neat if I could have pulled it off, but I’d rather develop a data-heavy application in rails than javascript.
I ended up using simple CSS to skin the application called UiUI. It’s the best looking iphone UI I’ve seen, with tons of elements to choose from. It’s missing effects, of course, being only CSS. I also used Heroku, a free and scalable rails deployment environment to host my application. With it, I was up and running with a functional tracker application in under 3 hours. Since then, I’ve added the ability to create and update stories.
Check it out, let me know what you think:
http://itracker.heroku.com
If you’re not on an iPhone, be sure to use Safari. It doesn’t look great in Firefox or IE.