Lighter weight deployment with git-deploy

Up until now I’ve been using a fairly standard capistrano deploy.rb. The problem is that as we speak I’m trying to deploy a patch from my Windows work machine and it’s not working. The ethics of fixing one of my project from home aside, this is a problem. When I try and deploy the following error  comes up

can’t convert Net::SSH::Authentication::Pageant::Socket into IO (TypeError)

The change I was trying to deploy stops in its tracks. After quite a bit of searching I found a thread about the error that dates back to Capistrano 2.5.3… from 2008. What a shining example of open source.

To be fair the error isn’t necessarily in Capistrano, it may in fact be in Net::SSH. The sad thing is that we’re over a year later, and nothing has been done to fix the problem. Is the number of people that use Ruby from Windows machines so low that no-one has managed to fix it in a year?

I’m not expecting Jamis to fix it. I get that he has too much to do, and doesn’t have time to give out a bunch of freebie support, but I’m now faced with the choice of either trying to fix the problem, a task I don’t currently have time for, or ditching capistrano.

I’ve considered switching to heroku in the past and just never made the leap. For a start the app in question has to many moving parts for heroku. One thing I did like though was the notion that to deploy all I had to do was ‘git push target master’  and the app would be updated and deployed.

After toying around with rolling my own solution, I stumbled upon mislav’s gem. It lacks some of the features that I’m looking for, but its a good deal closer to the level that I need. It lacks the bloat of capistrano, which is important, because the biggest barrier to me getting in and fixing capistrano would be the size of the library and knowing where to start.

I very quickly migrated my existing application to use git-deploy. It’s not perfect for every problem, particularly if you’re doing multi stage deployments, etc, but at least I’ll be able to do a deployment everywhere I can get access to git now.

Documentum, old world document management (or why to avoid Documentum 6.0SP1)

I’m sick of raising support cases for things that should just work. I’m frustrated that a product as buggy and unstable as Documentum 6.0 SP1 can be proposed as a solution (by EMC). There are a lot of good things about Documentum, but there is a lot of bloat as well. This will be a growing list of stupid problems that I’ve found, I’ll start with one item and go from there.

  • Clicking on ‘Save As’ on a permission set with a name over a certain length causes it to bomb out. Why? because it tries to give the permission set a temporary name that is longer than the allowed 32 characters. No chance to override this name, no graceful handling, just a fat error message and the chance to reload DA and try again.
  • When using LDAPSync (which you probably need to get hotfixed anyway what with it having so many bugs fixed) ‘Groups and their member users’ does not update the content of mapped attributes even if they change (for instance during a rename).
  • My favorite of the last 2 weeks: BOCS and DTS are not supported in the same solution. This problem is related to DTS going looking for content that is still parked on the BOCS server. It’s been fixed in 6.5…the problem is that it was EMC that built the solution that we’re now using. There is some instability in the DTS services, which is something I have to follow up, but EMC/Documentum had better be hoping that the two are not related.

I think part of the problem is that Documentum like a lot of old world enterprise applications has a very tenous hold on some of the techniques that allow for more error free development. I mean was the code even unit tested…