Interesting Things
An EngineYard-hosted project had an issue with monit attempting to restart
mongrel too often. It turned out that the mongrel processes were not
dropping pid files soon enough. The EngineYard-suggested fix:- Upgrade mongrel to 1.1.5.1 (patched to drop the pid file faster)
- Upgrade to monit 5.0 beta 6
- Update to the latest ey-monit-scripts
- FiveRuns dash is a cool, customizable metrics
service. Pat created a plug-in
for sending continuous integration stats there: dash-ci. Using Cucumber to test Capistrano deployment:
cap --dry-runwill run Capistrano without completing the actual task
(e.g., deployment). Cucumber can then be used to write some nice,
story-like deployment expectations that search the Capistrano output to
document your project’s deployment process and ensure the documentation
remains valid. Something like:Feature: Deployment In order to deploy the application As an administrator I should run Capistrano commands Scenario: Deploying Given I am working from the RAILS_ROOT directory And the parent directory is a Git repository When I run a deployment task Then 'scm_user' for the deployment should be derived from the Git config for the remote origin Scenario: Deploying to demo Given I am working from the RAILS_ROOT directory When I run 'cap demo deploy' Then the deploy should succeed And the deployed code matches the latest 'web/stable' tag And the deployed code should be marked with a new 'web/demo' tagMore on this to come.
Using Selenium to ensure unique IDs in your DOM:
# ---------------------------------------------------------------------- # The examples below illustrate the technique with the Prototype and # jQuery libraries, respectively. Both use Pat Nakajima's selenium # helper for executing javascript in the tested browser window. # # For more on that helper, see: # http://pivotallabs.com/users/patn/blog/articles/717-run-javascript-in-selenium-tests-easily- # ---------------------------------------------------------------------- # ---------------------------------------------------------------------- # with prototype # note the exception catching... prototype chokes on invalid IDs # e.g., "invalid_id[][]" # ---------------------------------------------------------------------- def assert_unique_ids audit_json = run_javascript <<-JS audit_ids = function() { var results = {}; $A($$('*[id]')).each(function(element) { if(element.id.replace(' ', '').length > 0) { try { if($$('#' + element.id ).length > 1) { if( ! results.duplicates) { results.duplicates = {}; } var count = results.duplicates[element.id] || 0; count ++; results.duplicates[element.id] = count; } } catch(err) { // uncomment to capture invalid IDs // var invalid = results.invalid || []; // invalid.push(element.id); // results.invalid = invalid; } } }); return ($H(results).toJSON()); } audit_ids(); JS assert_equal({}, JSON.parse(audit_json)), 'Expected no duplicate IDs') end # ---------------------------------------------------------------------- # with jQuery # additionally depends on the jquery-json plugin: # http://code.google.com/p/jquery-json/ # ---------------------------------------------------------------------- def assert_unique_ids audit_json = run_javascript <<-JS audit_ids = function() { var results = {}; $('*[id]').each(function() { if(this.id.replace(' ', '').length > 0) { if($('*[id=' + this.id + ']').length > 1) { if( ! results.duplicates) { results.duplicates = {}; } var count = results.duplicates[this.id] || 0; count ++; results.duplicates[this.id] = count; } } }); return $.toJSON(results); } audit_ids(); JS assert_equal({}, JSON.parse(audit_json)), 'Expected no duplicate IDs') end
Help Wanted
- One project recently moved from Rimu to EngineYard, only to find their Mongrel processes double in memory consumption. Any thoughts on why?
That is because EngineYard uses 64-bit systems.
It’s the same problem as with Slicehost and is also the reason why Linode is so much more better suited for Rails hosting then SH:
http://forum.slicehost.com/comments.php?DiscussionID=2875
March 11, 2009 at 4:27 pm
Testing your deploy is cool
March 12, 2009 at 1:33 am
Yes, testing your deploy is cool.
Pivotal’s default template project and CI environment also does a real deploy to a ‘local’ environment as part of the CI build. It works fine, you just need to make sure you have a no-passphrase ssh key in ~/.ssh/authorized_keys on localhost.
A little slow, but that’s why it only happens in CI. I wonder if you could leverage these tests for the real build. Testing the output of Capistrano’s –dry-run mode is surely faster and catches syntax errors, but I wonder if it could mask some problems that would show up in a real deploy (file permissions, nonexistent directories?)
– Chad
March 12, 2009 at 8:48 am