If don’t want to worry about editing JSON files and uploading those JSON files for chef-solo to use? I would consider exporting temporary environment variables during the execution of a remote SSH command and then referencing those in your deploy recipes. Anything you can do with Ruby you can do with Chef. So something like:

 
deploy "/my/deploy/dir" do
  repo "git@github.com/whoami/project"
  revision "#{ENV['APP_REVISION']}" # Use the temp environment vars..
  user "deploy_ninja"
  enable_submodules true
  migrate true
  migration_command "rake db:migrate"
  environment "RAILS_ENV" => "production"
  shallow_clone true
  action "#{ENV['DEPLOY_OR_ROLLBACK']}"
  restart_command "touch tmp/restart.txt"
  scm_provider Chef::Provider::Git
end

If you desire to make it look and feel exactly like Capistrano then write a shell script or a Ruby script that takes the same “signature” and then pass those arguments along accordingly.

A few parting thoughts. Chef isn’t for everyone, in fact, some might argue that automating your infrastructure is a separate concern from deployment. Deviating too far outside the pragmatic uses of Chef could just mean that it is not a good fit for your team. Don’t try to shoehorn something in because it is trendy or seemingly cool. Maybe Capistrano is exactly what you need…

With Capistrano I do “cap production deploy BRANCH=v20110903″ or whatever and that branch is deployed. With chef I have to set an attribute on a node or edit then upload a data bag, then run the chef-client.

This is even more important for rolling back, since that’s usually a high-pressure situation, where “cap production deploy:rollback” instantly fixes it. I don’t want to be dicking around with JSON and having to upload stuff while my server is on fire.

I guess it would be nice to be able to type a command like “knife deploy omfg its on fire roll back roll back!”

I’m not trying to diss chef here, I use it a lot and I’m going to ditch cap for chef for deployments, but I need to come up with a solution for this (common?) use-case.

Hi,

I just read your article
http://techwhizbang.com/2010/04/cooking-with-chef/ , which was good,
but I had a question and I thought you might be able to answer.

In the article you’re talking about how easy it is to deploy with
Chef. I’ve found this to be somewhat true, but the default deploy
resource basically makes is so your “master” or whatever is deployed
to the system whenever you run chef-client. So, if I’m running
chef-client as a daemon and doing continuous deployment that’s cool,
but I’m still not getting it for periodic deploys of a certain branch
or for rolling back.

I mean, a collegue asked me, “how do I deploy the app”, and I told
him, “well, you don’t really deploy the app, you bring the node into a
state of convergence.”, then he said, “What?”

I’m deploying with the deploy resource and apps data bag, and I’m
thinking of making a knife plugin where I can do `knife deploy
production myapp` that sets an attribute for the action of the deploy
resource or something, so I was wondering how you handle rolling back
(as I understand it, the way the defaults work I have to edit a
cookbook if I want to roll back, which is not cool.)

Also, you said, “Take deployment and rollback even a step further with
a tool like Hudson or TeamCity. Configure a job for them to run and
wire up the Chef deployment script. The “easy button” deployment and
rollback.” Could you explain how you do this?

* He replied: *

Hi Nathan,

For some reason your name sounds familiar. Thanks for the inquiry and the complement. I think Chef is a good choice for deployment if you are already using it for automating your setups. It is probably way too much trouble in terms of setup and understanding for just the deploy resource. Although you could just use chef-solo to sidestep the complicated steps of maintaining and managing the full Chef server stack. I’m assuming you’re intending on using it to its fullest extent. I’ve used the deploy resource a couple different ways. The first way I used it was to create a recipe that does deploying/rollbacks for each target environment. Imagine a cookbook with the following recipes:

— deploy_some_app_cookbook
– development.rb
– qa.rb
– staging.rb
– production.rb

All of these recipes share the same code except for a couple things captured in attributes. The recipes have attributes for the target tag or branch and potentially if you’e deploying or rolling back:
default[:deploy_apps][:vcs_branch_or_tag] = “Tag v0.0.1″
default[:deploy_apps][:rollback] = false

So when you use these recipes you can reference the attributes in the deploy resource. This way you aren’t always deploying master or trunk. Update the recipes and attributes across Chef accordingly as things for your project(s) change.

Another approach is to use data bags. You can access data bags similarly in your recipes. By the way, the deploy resource is extensible to just about any application, not just Rails apps. I’ve molded it to deploy WAR files, background applications, and all types of services.

You were concerned about rollback, but Chef does 2 types of deployments – timestamped or commit revisions. When you execute a rollback, Chef places a file on your server that keeps track of the last 10 or so deploys in the exact order they were performed along with all of the artifacts necessary to perform the rollback. So when you do a rollback you don’t have to worry about specifying a revision number, tag, or anything of that sort. Just “rollback” and Chef will automatically change the symlink it uses to point to the previous deploy.

In terms of using Team City or Jenkins as an “easy button”. Both of the CI servers will take an arbitrary shell script, executable, rake task, maven task, ant task, or whatever else you can dream up. You would normally use the command line to do a deploy with Chef, so my suggestion was to make it one step easier. Create a job that will execute a shell script that wraps the Chef commands used for deployment and rollback.

I think once you get Chef fully up and running and begin using it this will be easier and also become very clear. Hope this helps.

~approximately~
myModel = function(){
this.myField = ko.observable() -> creates a field that binds to the view

this.myArray = ko.observableArray() -> creates an array that binds to the view
}

ko.applyBindings(myModel);

I tried backbone first. Pretty cool for sure, but I didn’t like being tied to the backbone base classes. With knockout, I can pretty easily switch frameworks if I every need to. The integration is pretty flexible.

Just my two cents

It is becoming increasingly popular to mix technologies, frameworks, and languages to power a web site. So what happens when you want to share session data between some permutation of a Ruby, PHP, .NET, Python, Java web framework? Well of course using …