# deploy\_revision or Capistrano?

**URL:** <https://discourse.chef.io/t/deploy-revision-or-capistrano/6549>\
**Category:** Chef Infra (archive)\
**Created:** [April 7, 2015, 8:21pm UTC](https://discourse.chef.io/t/deploy-revision-or-capistrano/6549 "2015-04-07T20:21:05Z")\
**Posts on this page:** 15\
**Page:** 1

<div class="post-metadata">

**Author:** ![okram999](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/okram999/32/1083_2.png) [@okram999](https://discourse.chef.io/u/okram999)\
**Post date:** [April 7, 2015, 8:21pm UTC](https://discourse.chef.io/t/deploy-revision-or-capistrano/6549/1 "2015-04-07T20:21:05Z")

</div>

I am using the chef resource “deploy\_revision” to deploy a python code on  
my nodes. I started this initially for a dev enviroment but now slowly  
there is a need for this to expand and i am not sure - if this is a good  
choice. Below is the simple code.

data\_bag = Chef::EncryptedDataBagItem.load("#{node.chef\_environment}",  
"#{node.chef\_environment}")

deploy\_revision “/opt/mount/#{node[:application\_name]}” do  
repo "#{node[:application\_repo]}"  
user "deployer"  
keep\_releases 10  
action :deploy  
migrate false  
symlink\_before\_migrate.clear  
create\_dirs\_before\_symlink  
purge\_before\_symlink.clear  
symlinks.clear  
symlinks {}  
notifies :restart, "service[abc]"  
end

Its pulls down the new code whenever there is one, during the automatic  
chef-run at happen every 30mins on the nodes. This is cool but not so cool  
in other nodes which are not a part of the developement enviroment. I have  
4 enviroments:  
dev  
test  
stage  
prod

If i create 4 remote branches on the git, Is there a way on how to make  
this deploy from specific branch on specific environments? Something like,  
the dev nodes deploy the dev remote branch, test deploys the test remote  
branch and so on… This way, i can put a gate on the auto deploys that  
happening every 30mins. i referred the chef docs, there is this  
"deploy\_branch" but i not sure it just says its the same as  
"deploy\_revision"  
[https://docs.chef.io/resource\_deploy.html#layout-modifiers](https://docs.chef.io/resource_deploy.html#layout-modifiers)

If you guys, think deployment using chef is not a good idea. Do you think-  
i should look out for Capistrano?

---

<div class="post-metadata">

**Author:** ![okram999](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/okram999/32/1083_2.png) [@okram999](https://discourse.chef.io/u/okram999)\
**Post date:** [April 7, 2015, 8:30pm UTC](https://discourse.chef.io/t/deploy-revision-or-capistrano/6549/2 "2015-04-07T20:30:22Z")

</div>

i just noticed 'branch' as an attribute. So, i added the line for the  
branch like this:

deploy\_revision "/opt/mount/#{node[:application\_name]}" do  
repo "#{node[:application\_repo]}"  
user "deployer"  
_branch "node.chef\_environment"_  
keep\_releases 10  
action :deploy  
migrate false  
symlink\_before\_migrate.clear  
create\_dirs\_before\_symlink  
purge\_before\_symlink.clear  
symlinks.clear  
symlinks {}  
notifies :restart, "service[abc]"  
end

Does this look good and was this attribute designed for this. My test nodes  
are in a freeze state & hence i am unable to test out

On Tue, Apr 7, 2015 at 1:21 PM, niristotle okram [nirish.okram@gmail.com](mailto:nirish.okram@gmail.com)  
wrote:

> I am using the chef resource "deploy\_revision" to deploy a python code on  
> my nodes. I started this initially for a dev enviroment but now slowly  
> there is a need for this to expand and i am not sure - if this is a good  
> choice. Below is the simple code.
> 
> data\_bag = Chef::EncryptedDataBagItem.load("#{node.chef\_environment}",  
> "#{node.chef\_environment}")
> 
> deploy\_revision "/opt/mount/#{node[:application\_name]}" do  
> repo "#{node[:application\_repo]}"  
> user "deployer"  
> keep\_releases 10  
> action :deploy  
> migrate false  
> symlink\_before\_migrate.clear  
> create\_dirs\_before\_symlink  
> purge\_before\_symlink.clear  
> symlinks.clear  
> symlinks {}  
> notifies :restart, "service[abc]"  
> end
> 
> Its pulls down the new code whenever there is one, during the automatic  
> chef-run at happen every 30mins on the nodes. This is cool but not so cool  
> in other nodes which are not a part of the developement enviroment. I have  
> 4 enviroments:  
> dev  
> test  
> stage  
> prod
> 
> If i create 4 remote branches on the git, Is there a way on how to make  
> this deploy from specific branch on specific environments? Something like,  
> the dev nodes deploy the dev remote branch, test deploys the test remote  
> branch and so on.. This way, i can put a gate on the auto deploys that  
> happening every 30mins. i referred the chef docs, there is this  
> "deploy\_branch" but i not sure it just says its the same as  
> "deploy\_revision"  
> [https://docs.chef.io/resource\_deploy.html#layout-modifiers](https://docs.chef.io/resource_deploy.html#layout-modifiers)
> 
> If you guys, think deployment using chef is not a good idea. Do you think-  
> i should look out for Capistrano?

--  
Regards  
nirish okram

---

<div class="post-metadata">

**Author:** ![kallistec](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/kallistec/32/23_2.png) [@kallistec](https://discourse.chef.io/u/kallistec)\
**Post date:** [April 7, 2015, 8:51pm UTC](https://discourse.chef.io/t/deploy-revision-or-capistrano/6549/3 "2015-04-07T20:51:23Z")

</div>

On Tuesday, April 7, 2015 at 1:30 PM, niristotle okram wrote:

> i just noticed 'branch' as an attribute. So, i added the line for the branch like this:
> 
> deploy\_revision "/opt/mount/#{node[:application\_name]}" do  
> repo "#{node[:application\_repo]}"  
> user "deployer"  
> branch "node.chef\_environment"  
> keep\_releases 10  
> action :deploy  
> migrate false  
> symlink\_before\_migrate.clear  
> create\_dirs\_before\_symlink  
> purge\_before\_symlink.clear  
> symlinks.clear  
> symlinks {}  
> notifies :restart, "service[abc]"  
> end
> 
> Does this look good and was this attribute designed for this. My test nodes are in a freeze state & hence i am unable to test out  
> That will work the way you want.

As for whether you should do code deployments with chef, it’s a complicated topic. To some degree, your application code and infra code are coupled, as the point of the infra code is to get you a system that can correctly run your app code. Since your app code will have different requirements over time (need different versions of your VM, supporting libraries, etc.), it makes sense to develop and publish them together. The downside is that deployment of new code is harder to orchestrate, since you normally want chef to run on an interval to ensure your config is up to date. Which means you need to be okay with deployments happening over a longer timespan, or add some orchestration component (at small enough scale this can just be knife ssh) to force chef-client runs to occur. Another downside is that chef-client runs involve idempotency checks for all the components beneath your app, which in turn means that your deploys can fail if your other cookbooks depend on an unrelated external resource (like an apt mirror or something) that happens to be down. Also, chef-client will spend time running ohai and doing idempotency checks on other resources before it deploys your application, so it will be slower than using a different tool. This can be mitigated with override run lists, but there are some rough edges to those.

HTH,

--  
Daniel DeLeo

---

<div class="post-metadata">

**Author:** ![Morgan\_Blackthorne](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/morgan_blackthorne/32/100_2.png) [@Morgan\_Blackthorne](https://discourse.chef.io/u/Morgan_Blackthorne)\
**Post date:** [April 7, 2015, 9:10pm UTC](https://discourse.chef.io/t/deploy-revision-or-capistrano/6549/4 "2015-04-07T21:10:15Z")

</div>

I suggest using chef to pre-deploy new code to a versioned path, and then  
you can use cap or such to handle snapping correct symlinks and service  
restarts in an orchestrated fashion. That's actually how I handle updates  
to most of our Atlassian services, so that I can ensure I take a mysqldump  
and vmware snapshot first.  
On Apr 7, 2015 1:51 PM, "Daniel DeLeo" [dan@kallistec.com](mailto:dan@kallistec.com) wrote:

> On Tuesday, April 7, 2015 at 1:30 PM, niristotle okram wrote:
> 
> > i just noticed 'branch' as an attribute. So, i added the line for the  
> > branch like this:
> > 
> > deploy\_revision "/opt/mount/#{node[:application\_name]}" do  
> > repo "#{node[:application\_repo]}"  
> > user "deployer"  
> > branch "node.chef\_environment"  
> > keep\_releases 10  
> > action :deploy  
> > migrate false  
> > symlink\_before\_migrate.clear  
> > create\_dirs\_before\_symlink  
> > purge\_before\_symlink.clear  
> > symlinks.clear  
> > symlinks {}  
> > notifies :restart, "service[abc]"  
> > end
> > 
> > Does this look good and was this attribute designed for this. My test  
> > nodes are in a freeze state & hence i am unable to test out  
> > That will work the way you want.
> 
> As for whether you should do code deployments with chef, it’s a  
> complicated topic. To some degree, your application code and infra code are  
> coupled, as the point of the infra code is to get you a system that can  
> correctly run your app code. Since your app code will have different  
> requirements over time (need different versions of your VM, supporting  
> libraries, etc.), it makes sense to develop and publish them together. The  
> downside is that deployment of new code is harder to orchestrate, since you  
> normally want chef to run on an interval to ensure your config is up to  
> date. Which means you need to be okay with deployments happening over a  
> longer timespan, or add some orchestration component (at small enough scale  
> this can just be knife ssh) to force chef-client runs to occur. Another  
> downside is that chef-client runs involve idempotency checks for all the  
> components beneath your app, which in turn means that your deploys can fail  
> if your other cookbooks depend on an unrelated external resource (like an  
> apt mirror or something) that happens to be down. Also, chef-client will  
> spend time running ohai and doing idempotency checks on other resources  
> before it deploys your application, so it will be slower than using a  
> different tool. This can be mitigated with override run lists, but there  
> are some rough edges to those.
> 
> HTH,
> 
> --  
> Daniel DeLeo

---

<div class="post-metadata">

**Author:** ![Ranjib](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/ranjib/32/1040_2.png) [@Ranjib](https://discourse.chef.io/u/Ranjib)\
**Post date:** [April 7, 2015, 10:20pm UTC](https://discourse.chef.io/t/deploy-revision-or-capistrano/6549/5 "2015-04-07T22:20:29Z")

</div>

I'll jot down my learning from practicing both chef based as well as cap  
based deployments extensively:  
Cap:  
Pros:

1. Dev centric, you get control the exact order or time of deployments.
2. Very easy to adopt for rails and similar projects, UX feels similar to  
func, but ruby compatible idioms
3. Custom deployment strategies, like blue-gree/canary/dark launching etc  
are lot easier with cap (most of them end up grouping hosts  
Cons:
4. Encourages checking in configuration in the code, like all your  
environment details. This is pain if you environment changes, hosts get  
added etc
5. Since everything is triggered from a central place, the whole process is  
susceptible to failure of the central node (can be a CI agent, can be a  
developers laptop)

Chef:  
pros:

1. Same style of deployment as capistrano (symlinks. hooks etc)
2. decentralized, pull based. Things will be deployed eventually.  
cons:
3. deployment is tied with system changes/rollout
4. you cant control the order of deployments (like what if you decide to do  
the db migration first, on one host, then do canary deployment in a subset  
etc)

You can go hybrid, mix n match things, like:

1. cap can use chef to search and auto populate the hosts
2. deploy via chef can be captured in a separate recipe which can be used  
in conjunction with the full blown chef run, or just via chef-client -o  
'recipe[deploy]'
3. you can use blender to orchestrate the chef runs (with or without  
deployment), this also opens up the possibilty to use serf or other non-ssh  
based deployment triggers, which works lot better when u have lot of  
servers, or network is flaky between the trigger point and deployment  
target host

Over all, i'll recommend consider you requirement and your team's strength  
above everything, at the end they are the one who will maintain it

cheers  
ranjib

On Tue, Apr 7, 2015 at 1:51 PM, Daniel DeLeo [dan@kallistec.com](mailto:dan@kallistec.com) wrote:

> On Tuesday, April 7, 2015 at 1:30 PM, niristotle okram wrote:
> 
> > i just noticed 'branch' as an attribute. So, i added the line for the  
> > branch like this:
> > 
> > deploy\_revision "/opt/mount/#{node[:application\_name]}" do  
> > repo "#{node[:application\_repo]}"  
> > user "deployer"  
> > branch "node.chef\_environment"  
> > keep\_releases 10  
> > action :deploy  
> > migrate false  
> > symlink\_before\_migrate.clear  
> > create\_dirs\_before\_symlink  
> > purge\_before\_symlink.clear  
> > symlinks.clear  
> > symlinks {}  
> > notifies :restart, "service[abc]"  
> > end
> > 
> > Does this look good and was this attribute designed for this. My test  
> > nodes are in a freeze state & hence i am unable to test out  
> > That will work the way you want.
> 
> As for whether you should do code deployments with chef, it’s a  
> complicated topic. To some degree, your application code and infra code are  
> coupled, as the point of the infra code is to get you a system that can  
> correctly run your app code. Since your app code will have different  
> requirements over time (need different versions of your VM, supporting  
> libraries, etc.), it makes sense to develop and publish them together. The  
> downside is that deployment of new code is harder to orchestrate, since you  
> normally want chef to run on an interval to ensure your config is up to  
> date. Which means you need to be okay with deployments happening over a  
> longer timespan, or add some orchestration component (at small enough scale  
> this can just be knife ssh) to force chef-client runs to occur. Another  
> downside is that chef-client runs involve idempotency checks for all the  
> components beneath your app, which in turn means that your deploys can fail  
> if your other cookbooks depend on an unrelated external resource (like an  
> apt mirror or something) that happens to be down. Also, chef-client will  
> spend time running ohai and doing idempotency checks on other resources  
> before it deploys your application, so it will be slower than using a  
> different tool. This can be mitigated with override run lists, but there  
> are some rough edges to those.
> 
> HTH,
> 
> --  
> Daniel DeLeo

---

<div class="post-metadata">

**Author:** ![okram999](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/okram999/32/1083_2.png) [@okram999](https://discourse.chef.io/u/okram999)\
**Post date:** [April 8, 2015, 6:25pm UTC](https://discourse.chef.io/t/deploy-revision-or-capistrano/6549/6 "2015-04-08T18:25:39Z")

</div>

hi,  
I tried out today, but it doesn't seem to pull down the code from the  
parameterized branch names. This is what i have for the deploy\_revision:

deploy\_revision "/opt/mount/#{node[:application\_name]}" do

> repo "#{node[:application\_repo]}"  
> user "deployer"  
> _branch "node.chef\_environment"_  
> keep\_releases 10  
> action :deploy  
> migrate false  
> symlink\_before\_migrate.clear  
> create\_dirs\_before\_symlink  
> purge\_before\_symlink.clear  
> symlinks.clear  
> symlinks {}  
> notifies :restart, "service[abc]"  
> end

I have 4 environments (dev, test, staging & production) and i am trying to  
make "deploy\_revision" to deploy the codes from the specific _remote branch  
to the specific environment_.

And the branches on the repo are:

$ git branch -a

- (detached from origin/test)  
master  
remotes/origin/HEAD -\> origin/master
- remotes/origin/dev\*  
remotes/origin/master
- remotes/origin/production\*
- remotes/origin/staging\*
- remotes/origin/test\*

To test it, i pushed a new code to the master. Then merge that the 'dev'  
branch.

HEAD is now at 63c6388... version change

The below shows that the other 3 remote branches are behind or not in par  
with the dev.

$ git checkout origin/test  
Previous HEAD position was 63c6388... version change  
_HEAD is now at ad262df_...

$ git checkout origin/staging  
_HEAD is now at ad262df._..

$ git checkout origin/production  
_HEAD is now at ad262df_...

But strange that, when i run chef-client : the code version are same on  
dev, stage and prod .. while test have a different version. The deploy job  
says "upto date" in test environment.

On Tue, Apr 7, 2015 at 1:51 PM, Daniel DeLeo [dan@kallistec.com](mailto:dan@kallistec.com) wrote:

> On Tuesday, April 7, 2015 at 1:30 PM, niristotle okram wrote:
> 
> > i just noticed 'branch' as an attribute. So, i added the line for the  
> > branch like this:
> > 
> > deploy\_revision "/opt/mount/#{node[:application\_name]}" do  
> > repo "#{node[:application\_repo]}"  
> > user "deployer"  
> > branch "node.chef\_environment"  
> > keep\_releases 10  
> > action :deploy  
> > migrate false  
> > symlink\_before\_migrate.clear  
> > create\_dirs\_before\_symlink  
> > purge\_before\_symlink.clear  
> > symlinks.clear  
> > symlinks {}  
> > notifies :restart, "service[abc]"  
> > end
> > 
> > Does this look good and was this attribute designed for this. My test  
> > nodes are in a freeze state & hence i am unable to test out  
> > That will work the way you want.
> 
> As for whether you should do code deployments with chef, it’s a  
> complicated topic. To some degree, your application code and infra code are  
> coupled, as the point of the infra code is to get you a system that can  
> correctly run your app code. Since your app code will have different  
> requirements over time (need different versions of your VM, supporting  
> libraries, etc.), it makes sense to develop and publish them together. The  
> downside is that deployment of new code is harder to orchestrate, since you  
> normally want chef to run on an interval to ensure your config is up to  
> date. Which means you need to be okay with deployments happening over a  
> longer timespan, or add some orchestration component (at small enough scale  
> this can just be knife ssh) to force chef-client runs to occur. Another  
> downside is that chef-client runs involve idempotency checks for all the  
> components beneath your app, which in turn means that your deploys can fail  
> if your other cookbooks depend on an unrelated external resource (like an  
> apt mirror or something) that happens to be down. Also, chef-client will  
> spend time running ohai and doing idempotency checks on other resources  
> before it deploys your application, so it will be slower than using a  
> different tool. This can be mitigated with override run lists, but there  
> are some rough edges to those.
> 
> HTH,
> 
> --  
> Daniel DeLeo

--  
Regards  
nirish okram

---

<div class="post-metadata">

**Author:** ![Morgan\_Blackthorne](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/morgan_blackthorne/32/100_2.png) [@Morgan\_Blackthorne](https://discourse.chef.io/u/Morgan_Blackthorne)\
**Post date:** [April 8, 2015, 6:47pm UTC](https://discourse.chef.io/t/deploy-revision-or-capistrano/6549/7 "2015-04-08T18:47:08Z")

</div>

You should either remove the quotes around node.chef\_environment, or  
string-ize it as "#{node.chef\_environment}". Putting quotes around it but  
not string-izing it just leads to it being interpreted literally.

--  
~_~ StormeRider ~_~

"Every world needs its heroes [...] They inspire us to be better than we  
are. And they protect from the darkness that's just around the corner."

(from Smallville Season 6x1: "Zod")

On why I hate the phrase "that's so lame"... [http://bit.ly/Ps3uSS](http://bit.ly/Ps3uSS)

On Wed, Apr 8, 2015 at 11:25 AM, niristotle okram [nirish.okram@gmail.com](mailto:nirish.okram@gmail.com)  
wrote:

> hi,  
> I tried out today, but it doesn't seem to pull down the code from the  
> parameterized branch names. This is what i have for the deploy\_revision:
> 
> deploy\_revision "/opt/mount/#{node[:application\_name]}" do
> 
> > repo "#{node[:application\_repo]}"  
> > user "deployer"  
> > _branch "node.chef\_environment"_  
> > keep\_releases 10  
> > action :deploy  
> > migrate false  
> > symlink\_before\_migrate.clear  
> > create\_dirs\_before\_symlink  
> > purge\_before\_symlink.clear  
> > symlinks.clear  
> > symlinks {}  
> > notifies :restart, "service[abc]"  
> > end
> 
> I have 4 environments (dev, test, staging & production) and i am trying to  
> make "deploy\_revision" to deploy the codes from the specific _remote  
> branch to the specific environment_.
> 
> And the branches on the repo are:
> 
> $ git branch -a
> 
> - (detached from origin/test)  
> master  
> remotes/origin/HEAD -\> origin/master
> - remotes/origin/dev\*  
> remotes/origin/master
> - remotes/origin/production\*
> - remotes/origin/staging\*
> - remotes/origin/test\*
> 
> To test it, i pushed a new code to the master. Then merge that the 'dev'  
> branch.
> 
> HEAD is now at 63c6388... version change
> 
> The below shows that the other 3 remote branches are behind or not in par  
> with the dev.
> 
> $ git checkout origin/test  
> Previous HEAD position was 63c6388... version change  
> _HEAD is now at ad262df_...
> 
> $ git checkout origin/staging  
> _HEAD is now at ad262df._..
> 
> $ git checkout origin/production  
> _HEAD is now at ad262df_...
> 
> But strange that, when i run chef-client : the code version are same on  
> dev, stage and prod .. while test have a different version. The deploy job  
> says "upto date" in test environment.
> 
> On Tue, Apr 7, 2015 at 1:51 PM, Daniel DeLeo [dan@kallistec.com](mailto:dan@kallistec.com) wrote:
> 
> > On Tuesday, April 7, 2015 at 1:30 PM, niristotle okram wrote:
> > 
> > > i just noticed 'branch' as an attribute. So, i added the line for the  
> > > branch like this:
> > > 
> > > deploy\_revision "/opt/mount/#{node[:application\_name]}" do  
> > > repo "#{node[:application\_repo]}"  
> > > user "deployer"  
> > > branch "node.chef\_environment"  
> > > keep\_releases 10  
> > > action :deploy  
> > > migrate false  
> > > symlink\_before\_migrate.clear  
> > > create\_dirs\_before\_symlink  
> > > purge\_before\_symlink.clear  
> > > symlinks.clear  
> > > symlinks {}  
> > > notifies :restart, "service[abc]"  
> > > end
> > > 
> > > Does this look good and was this attribute designed for this. My test  
> > > nodes are in a freeze state & hence i am unable to test out  
> > > That will work the way you want.
> > 
> > As for whether you should do code deployments with chef, it’s a  
> > complicated topic. To some degree, your application code and infra code are  
> > coupled, as the point of the infra code is to get you a system that can  
> > correctly run your app code. Since your app code will have different  
> > requirements over time (need different versions of your VM, supporting  
> > libraries, etc.), it makes sense to develop and publish them together. The  
> > downside is that deployment of new code is harder to orchestrate, since you  
> > normally want chef to run on an interval to ensure your config is up to  
> > date. Which means you need to be okay with deployments happening over a  
> > longer timespan, or add some orchestration component (at small enough scale  
> > this can just be knife ssh) to force chef-client runs to occur. Another  
> > downside is that chef-client runs involve idempotency checks for all the  
> > components beneath your app, which in turn means that your deploys can fail  
> > if your other cookbooks depend on an unrelated external resource (like an  
> > apt mirror or something) that happens to be down. Also, chef-client will  
> > spend time running ohai and doing idempotency checks on other resources  
> > before it deploys your application, so it will be slower than using a  
> > different tool. This can be mitigated with override run lists, but there  
> > are some rough edges to those.
> > 
> > HTH,
> > 
> > --  
> > Daniel DeLeo
> 
> --  
> Regards  
> nirish okram

---

<div class="post-metadata">

**Author:** ![okram999](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/okram999/32/1083_2.png) [@okram999](https://discourse.chef.io/u/okram999)\
**Post date:** [April 8, 2015, 7:03pm UTC](https://discourse.chef.io/t/deploy-revision-or-capistrano/6549/8 "2015-04-08T19:03:50Z")

</div>

oops sorry, i had corrected while i was committing the code. This is what i  
have and which is not working

deploy\_revision "/opt/mount1/#{node[:application\_name]}" do

repo "#{node[:application\_repo]}"

user "python"

branch "#{node.chef\_environment}"

keep\_releases 10

action :deploy

migrate false

symlink\_before\_migrate.clear

create\_dirs\_before\_symlink

purge\_before\_symlink.clear

symlinks.clear

symlinks {}

notifies :restart, "service[oss]"

end

On Wed, Apr 8, 2015 at 11:47 AM, Morgan Blackthorne [stormerider@gmail.com](mailto:stormerider@gmail.com)  
wrote:

> You should either remove the quotes around node.chef\_environment, or  
> string-ize it as "#{node.chef\_environment}". Putting quotes around it but  
> not string-izing it just leads to it being interpreted literally.
> 
> --  
> ~_~ StormeRider ~_~
> 
> "Every world needs its heroes [...] They inspire us to be better than we  
> are. And they protect from the darkness that's just around the corner."
> 
> (from Smallville Season 6x1: "Zod")
> 
> On why I hate the phrase "that's so lame"... [http://bit.ly/Ps3uSS](http://bit.ly/Ps3uSS)
> 
> On Wed, Apr 8, 2015 at 11:25 AM, niristotle okram [nirish.okram@gmail.com](mailto:nirish.okram@gmail.com)  
> wrote:
> 
> > hi,  
> > I tried out today, but it doesn't seem to pull down the code from the  
> > parameterized branch names. This is what i have for the deploy\_revision:
> > 
> > deploy\_revision "/opt/mount/#{node[:application\_name]}" do
> > 
> > > repo "#{node[:application\_repo]}"  
> > > user "deployer"  
> > > _branch "node.chef\_environment"_  
> > > keep\_releases 10  
> > > action :deploy  
> > > migrate false  
> > > symlink\_before\_migrate.clear  
> > > create\_dirs\_before\_symlink  
> > > purge\_before\_symlink.clear  
> > > symlinks.clear  
> > > symlinks {}  
> > > notifies :restart, "service[abc]"  
> > > end
> > 
> > I have 4 environments (dev, test, staging & production) and i am trying  
> > to make "deploy\_revision" to deploy the codes from the specific _remote  
> > branch to the specific environment_.
> > 
> > And the branches on the repo are:
> > 
> > $ git branch -a
> > 
> > - (detached from origin/test)  
> > master  
> > remotes/origin/HEAD -\> origin/master
> > - remotes/origin/dev\*  
> > remotes/origin/master
> > - remotes/origin/production\*
> > - remotes/origin/staging\*
> > - remotes/origin/test\*
> > 
> > To test it, i pushed a new code to the master. Then merge that the 'dev'  
> > branch.
> > 
> > HEAD is now at 63c6388... version change
> > 
> > The below shows that the other 3 remote branches are behind or not in par  
> > with the dev.
> > 
> > $ git checkout origin/test  
> > Previous HEAD position was 63c6388... version change  
> > _HEAD is now at ad262df_...
> > 
> > $ git checkout origin/staging  
> > _HEAD is now at ad262df._..
> > 
> > $ git checkout origin/production  
> > _HEAD is now at ad262df_...
> > 
> > But strange that, when i run chef-client : the code version are same on  
> > dev, stage and prod .. while test have a different version. The deploy job  
> > says "upto date" in test environment.
> > 
> > On Tue, Apr 7, 2015 at 1:51 PM, Daniel DeLeo [dan@kallistec.com](mailto:dan@kallistec.com) wrote:
> > 
> > > On Tuesday, April 7, 2015 at 1:30 PM, niristotle okram wrote:
> > > 
> > > > i just noticed 'branch' as an attribute. So, i added the line for the  
> > > > branch like this:
> > > > 
> > > > deploy\_revision "/opt/mount/#{node[:application\_name]}" do  
> > > > repo "#{node[:application\_repo]}"  
> > > > user "deployer"  
> > > > branch "node.chef\_environment"  
> > > > keep\_releases 10  
> > > > action :deploy  
> > > > migrate false  
> > > > symlink\_before\_migrate.clear  
> > > > create\_dirs\_before\_symlink  
> > > > purge\_before\_symlink.clear  
> > > > symlinks.clear  
> > > > symlinks {}  
> > > > notifies :restart, "service[abc]"  
> > > > end
> > > > 
> > > > Does this look good and was this attribute designed for this. My test  
> > > > nodes are in a freeze state & hence i am unable to test out  
> > > > That will work the way you want.
> > > 
> > > As for whether you should do code deployments with chef, it’s a  
> > > complicated topic. To some degree, your application code and infra code are  
> > > coupled, as the point of the infra code is to get you a system that can  
> > > correctly run your app code. Since your app code will have different  
> > > requirements over time (need different versions of your VM, supporting  
> > > libraries, etc.), it makes sense to develop and publish them together. The  
> > > downside is that deployment of new code is harder to orchestrate, since you  
> > > normally want chef to run on an interval to ensure your config is up to  
> > > date. Which means you need to be okay with deployments happening over a  
> > > longer timespan, or add some orchestration component (at small enough scale  
> > > this can just be knife ssh) to force chef-client runs to occur. Another  
> > > downside is that chef-client runs involve idempotency checks for all the  
> > > components beneath your app, which in turn means that your deploys can fail  
> > > if your other cookbooks depend on an unrelated external resource (like an  
> > > apt mirror or something) that happens to be down. Also, chef-client will  
> > > spend time running ohai and doing idempotency checks on other resources  
> > > before it deploys your application, so it will be slower than using a  
> > > different tool. This can be mitigated with override run lists, but there  
> > > are some rough edges to those.
> > > 
> > > HTH,
> > > 
> > > --  
> > > Daniel DeLeo
> > 
> > --  
> > Regards  
> > nirish okram

--  
Regards  
nirish okram

---

<div class="post-metadata">

**Author:** ![Morgan\_Blackthorne](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/morgan_blackthorne/32/100_2.png) [@Morgan\_Blackthorne](https://discourse.chef.io/u/Morgan_Blackthorne)\
**Post date:** [April 8, 2015, 7:06pm UTC](https://discourse.chef.io/t/deploy-revision-or-capistrano/6549/9 "2015-04-08T19:06:30Z")

</div>

And what does chef-client -l info show around that resource?

--  
~_~ StormeRider ~_~

"Every world needs its heroes [...] They inspire us to be better than we  
are. And they protect from the darkness that's just around the corner."

(from Smallville Season 6x1: "Zod")

On why I hate the phrase "that's so lame"... [http://bit.ly/Ps3uSS](http://bit.ly/Ps3uSS)

On Wed, Apr 8, 2015 at 12:03 PM, niristotle okram [nirish.okram@gmail.com](mailto:nirish.okram@gmail.com)  
wrote:

> oops sorry, i had corrected while i was committing the code. This is what  
> i have and which is not working
> 
> deploy\_revision "/opt/mount1/#{node[:application\_name]}" do
> 
> repo "#{node[:application\_repo]}"
> 
> user "python"
> 
> branch "#{node.chef\_environment}"
> 
> keep\_releases 10
> 
> action :deploy
> 
> migrate false
> 
> symlink\_before\_migrate.clear
> 
> create\_dirs\_before\_symlink
> 
> purge\_before\_symlink.clear
> 
> symlinks.clear
> 
> symlinks {}
> 
> notifies :restart, "service[oss]"
> 
> end
> 
> On Wed, Apr 8, 2015 at 11:47 AM, Morgan Blackthorne \<[stormerider@gmail.com](mailto:stormerider@gmail.com)
> 
> > wrote:
> 
> > You should either remove the quotes around node.chef\_environment, or  
> > string-ize it as "#{node.chef\_environment}". Putting quotes around it but  
> > not string-izing it just leads to it being interpreted literally.
> > 
> > --  
> > ~_~ StormeRider ~_~
> > 
> > "Every world needs its heroes [...] They inspire us to be better than we  
> > are. And they protect from the darkness that's just around the corner."
> > 
> > (from Smallville Season 6x1: "Zod")
> > 
> > On why I hate the phrase "that's so lame"... [http://bit.ly/Ps3uSS](http://bit.ly/Ps3uSS)
> > 
> > On Wed, Apr 8, 2015 at 11:25 AM, niristotle okram \<[nirish.okram@gmail.com](mailto:nirish.okram@gmail.com)
> > 
> > > wrote:
> > 
> > > hi,  
> > > I tried out today, but it doesn't seem to pull down the code from the  
> > > parameterized branch names. This is what i have for the deploy\_revision:
> > > 
> > > deploy\_revision "/opt/mount/#{node[:application\_name]}" do
> > > 
> > > > repo "#{node[:application\_repo]}"  
> > > > user "deployer"  
> > > > _branch "node.chef\_environment"_  
> > > > keep\_releases 10  
> > > > action :deploy  
> > > > migrate false  
> > > > symlink\_before\_migrate.clear  
> > > > create\_dirs\_before\_symlink  
> > > > purge\_before\_symlink.clear  
> > > > symlinks.clear  
> > > > symlinks {}  
> > > > notifies :restart, "service[abc]"  
> > > > end
> > > 
> > > I have 4 environments (dev, test, staging & production) and i am trying  
> > > to make "deploy\_revision" to deploy the codes from the specific _remote  
> > > branch to the specific environment_.
> > > 
> > > And the branches on the repo are:
> > > 
> > > $ git branch -a
> > > 
> > > - (detached from origin/test)  
> > > master  
> > > remotes/origin/HEAD -\> origin/master
> > > - remotes/origin/dev\*  
> > > remotes/origin/master
> > > - remotes/origin/production\*
> > > - remotes/origin/staging\*
> > > - remotes/origin/test\*
> > > 
> > > To test it, i pushed a new code to the master. Then merge that the 'dev'  
> > > branch.
> > > 
> > > HEAD is now at 63c6388... version change
> > > 
> > > The below shows that the other 3 remote branches are behind or not in  
> > > par with the dev.
> > > 
> > > $ git checkout origin/test  
> > > Previous HEAD position was 63c6388... version change  
> > > _HEAD is now at ad262df_...
> > > 
> > > $ git checkout origin/staging  
> > > _HEAD is now at ad262df._..
> > > 
> > > $ git checkout origin/production  
> > > _HEAD is now at ad262df_...
> > > 
> > > But strange that, when i run chef-client : the code version are same on  
> > > dev, stage and prod .. while test have a different version. The deploy job  
> > > says "upto date" in test environment.
> > > 
> > > On Tue, Apr 7, 2015 at 1:51 PM, Daniel DeLeo [dan@kallistec.com](mailto:dan@kallistec.com) wrote:
> > > 
> > > > On Tuesday, April 7, 2015 at 1:30 PM, niristotle okram wrote:
> > > > 
> > > > > i just noticed 'branch' as an attribute. So, i added the line for the  
> > > > > branch like this:
> > > > > 
> > > > > deploy\_revision "/opt/mount/#{node[:application\_name]}" do  
> > > > > repo "#{node[:application\_repo]}"  
> > > > > user "deployer"  
> > > > > branch "node.chef\_environment"  
> > > > > keep\_releases 10  
> > > > > action :deploy  
> > > > > migrate false  
> > > > > symlink\_before\_migrate.clear  
> > > > > create\_dirs\_before\_symlink  
> > > > > purge\_before\_symlink.clear  
> > > > > symlinks.clear  
> > > > > symlinks {}  
> > > > > notifies :restart, "service[abc]"  
> > > > > end
> > > > > 
> > > > > Does this look good and was this attribute designed for this. My test  
> > > > > nodes are in a freeze state & hence i am unable to test out  
> > > > > That will work the way you want.
> > > > 
> > > > As for whether you should do code deployments with chef, it’s a  
> > > > complicated topic. To some degree, your application code and infra code are  
> > > > coupled, as the point of the infra code is to get you a system that can  
> > > > correctly run your app code. Since your app code will have different  
> > > > requirements over time (need different versions of your VM, supporting  
> > > > libraries, etc.), it makes sense to develop and publish them together. The  
> > > > downside is that deployment of new code is harder to orchestrate, since you  
> > > > normally want chef to run on an interval to ensure your config is up to  
> > > > date. Which means you need to be okay with deployments happening over a  
> > > > longer timespan, or add some orchestration component (at small enough scale  
> > > > this can just be knife ssh) to force chef-client runs to occur. Another  
> > > > downside is that chef-client runs involve idempotency checks for all the  
> > > > components beneath your app, which in turn means that your deploys can fail  
> > > > if your other cookbooks depend on an unrelated external resource (like an  
> > > > apt mirror or something) that happens to be down. Also, chef-client will  
> > > > spend time running ohai and doing idempotency checks on other resources  
> > > > before it deploys your application, so it will be slower than using a  
> > > > different tool. This can be mitigated with override run lists, but there  
> > > > are some rough edges to those.
> > > > 
> > > > HTH,
> > > > 
> > > > --  
> > > > Daniel DeLeo
> > > 
> > > --  
> > > Regards  
> > > nirish okram
> 
> --  
> Regards  
> nirish okram

---

<div class="post-metadata">

**Author:** ![okram999](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/okram999/32/1083_2.png) [@okram999](https://discourse.chef.io/u/okram999)\
**Post date:** [April 8, 2015, 7:37pm UTC](https://discourse.chef.io/t/deploy-revision-or-capistrano/6549/10 "2015-04-08T19:37:17Z")

</div>

unfortunately i didn't enable the debug, for a node which deployed the  
code. But i can try that after pushing something new to the remote dev  
branch alone.  
Below is the entry from the debug log that doesn't specify anything  
regarding the branch from which its trying to deploy.

[2015-04-07T23:45:32+00:00] INFO: Processing  
deploy\_revision[/opt/mount/oss] action deploy  
(python\_app::python-app-deploy line 36)  
[2015-04-07T23:45:32+00:00] DEBUG: deploy\_revision[/opt/mount1/oss] finding  
current git revision  
[2015-04-07T23:45:32+00:00] DEBUG: deploy\_revision[/opt/mount1/oss]  
resolving remote reference  
[2015-04-07T23:45:32+00:00] DEBUG: deploy\_revision[/opt/mount1/oss] is the  
latest version

I always see this printed "fetch updates for origin"

Thanks

On Wed, Apr 8, 2015 at 12:06 PM, Morgan Blackthorne [stormerider@gmail.com](mailto:stormerider@gmail.com)  
wrote:

> And what does chef-client -l info show around that resource?
> 
> --  
> ~_~ StormeRider ~_~
> 
> "Every world needs its heroes [...] They inspire us to be better than we  
> are. And they protect from the darkness that's just around the corner."
> 
> (from Smallville Season 6x1: "Zod")
> 
> On why I hate the phrase "that's so lame"... [http://bit.ly/Ps3uSS](http://bit.ly/Ps3uSS)
> 
> On Wed, Apr 8, 2015 at 12:03 PM, niristotle okram [nirish.okram@gmail.com](mailto:nirish.okram@gmail.com)  
> wrote:
> 
> > oops sorry, i had corrected while i was committing the code. This is what  
> > i have and which is not working
> > 
> > deploy\_revision "/opt/mount1/#{node[:application\_name]}" do
> > 
> > repo "#{node[:application\_repo]}"
> > 
> > user "python"
> > 
> > branch "#{node.chef\_environment}"
> > 
> > keep\_releases 10
> > 
> > action :deploy
> > 
> > migrate false
> > 
> > symlink\_before\_migrate.clear
> > 
> > create\_dirs\_before\_symlink
> > 
> > purge\_before\_symlink.clear
> > 
> > symlinks.clear
> > 
> > symlinks {}
> > 
> > notifies :restart, "service[oss]"
> > 
> > end
> > 
> > On Wed, Apr 8, 2015 at 11:47 AM, Morgan Blackthorne \<  
> > [stormerider@gmail.com](mailto:stormerider@gmail.com)\> wrote:
> > 
> > > You should either remove the quotes around node.chef\_environment, or  
> > > string-ize it as "#{node.chef\_environment}". Putting quotes around it but  
> > > not string-izing it just leads to it being interpreted literally.
> > > 
> > > --  
> > > ~_~ StormeRider ~_~
> > > 
> > > "Every world needs its heroes [...] They inspire us to be better than we  
> > > are. And they protect from the darkness that's just around the corner."
> > > 
> > > (from Smallville Season 6x1: "Zod")
> > > 
> > > On why I hate the phrase "that's so lame"... [http://bit.ly/Ps3uSS](http://bit.ly/Ps3uSS)
> > > 
> > > On Wed, Apr 8, 2015 at 11:25 AM, niristotle okram \<  
> > > [nirish.okram@gmail.com](mailto:nirish.okram@gmail.com)\> wrote:
> > > 
> > > > hi,  
> > > > I tried out today, but it doesn't seem to pull down the code from the  
> > > > parameterized branch names. This is what i have for the deploy\_revision:
> > > > 
> > > > deploy\_revision "/opt/mount/#{node[:application\_name]}" do
> > > > 
> > > > > repo "#{node[:application\_repo]}"  
> > > > > user "deployer"  
> > > > > _branch "node.chef\_environment"_  
> > > > > keep\_releases 10  
> > > > > action :deploy  
> > > > > migrate false  
> > > > > symlink\_before\_migrate.clear  
> > > > > create\_dirs\_before\_symlink  
> > > > > purge\_before\_symlink.clear  
> > > > > symlinks.clear  
> > > > > symlinks {}  
> > > > > notifies :restart, "service[abc]"  
> > > > > end
> > > > 
> > > > I have 4 environments (dev, test, staging & production) and i am trying  
> > > > to make "deploy\_revision" to deploy the codes from the specific _remote  
> > > > branch to the specific environment_.
> > > > 
> > > > And the branches on the repo are:
> > > > 
> > > > $ git branch -a
> > > > 
> > > > - (detached from origin/test)  
> > > > master  
> > > > remotes/origin/HEAD -\> origin/master
> > > > - remotes/origin/dev\*  
> > > > remotes/origin/master
> > > > - remotes/origin/production\*
> > > > - remotes/origin/staging\*
> > > > - remotes/origin/test\*
> > > > 
> > > > To test it, i pushed a new code to the master. Then merge that the  
> > > > 'dev' branch.
> > > > 
> > > > HEAD is now at 63c6388... version change
> > > > 
> > > > The below shows that the other 3 remote branches are behind or not in  
> > > > par with the dev.
> > > > 
> > > > $ git checkout origin/test  
> > > > Previous HEAD position was 63c6388... version change  
> > > > _HEAD is now at ad262df_...
> > > > 
> > > > $ git checkout origin/staging  
> > > > _HEAD is now at ad262df._..
> > > > 
> > > > $ git checkout origin/production  
> > > > _HEAD is now at ad262df_...
> > > > 
> > > > But strange that, when i run chef-client : the code version are same on  
> > > > dev, stage and prod .. while test have a different version. The deploy job  
> > > > says "upto date" in test environment.
> > > > 
> > > > On Tue, Apr 7, 2015 at 1:51 PM, Daniel DeLeo [dan@kallistec.com](mailto:dan@kallistec.com) wrote:
> > > > 
> > > > > On Tuesday, April 7, 2015 at 1:30 PM, niristotle okram wrote:
> > > > > 
> > > > > > i just noticed 'branch' as an attribute. So, i added the line for  
> > > > > > the branch like this:
> > > > > > 
> > > > > > deploy\_revision "/opt/mount/#{node[:application\_name]}" do  
> > > > > > repo "#{node[:application\_repo]}"  
> > > > > > user "deployer"  
> > > > > > branch "node.chef\_environment"  
> > > > > > keep\_releases 10  
> > > > > > action :deploy  
> > > > > > migrate false  
> > > > > > symlink\_before\_migrate.clear  
> > > > > > create\_dirs\_before\_symlink  
> > > > > > purge\_before\_symlink.clear  
> > > > > > symlinks.clear  
> > > > > > symlinks {}  
> > > > > > notifies :restart, "service[abc]"  
> > > > > > end
> > > > > > 
> > > > > > Does this look good and was this attribute designed for this. My  
> > > > > > test nodes are in a freeze state & hence i am unable to test out  
> > > > > > That will work the way you want.
> > > > > 
> > > > > As for whether you should do code deployments with chef, it’s a  
> > > > > complicated topic. To some degree, your application code and infra code are  
> > > > > coupled, as the point of the infra code is to get you a system that can  
> > > > > correctly run your app code. Since your app code will have different  
> > > > > requirements over time (need different versions of your VM, supporting  
> > > > > libraries, etc.), it makes sense to develop and publish them together. The  
> > > > > downside is that deployment of new code is harder to orchestrate, since you  
> > > > > normally want chef to run on an interval to ensure your config is up to  
> > > > > date. Which means you need to be okay with deployments happening over a  
> > > > > longer timespan, or add some orchestration component (at small enough scale  
> > > > > this can just be knife ssh) to force chef-client runs to occur. Another  
> > > > > downside is that chef-client runs involve idempotency checks for all the  
> > > > > components beneath your app, which in turn means that your deploys can fail  
> > > > > if your other cookbooks depend on an unrelated external resource (like an  
> > > > > apt mirror or something) that happens to be down. Also, chef-client will  
> > > > > spend time running ohai and doing idempotency checks on other resources  
> > > > > before it deploys your application, so it will be slower than using a  
> > > > > different tool. This can be mitigated with override run lists, but there  
> > > > > are some rough edges to those.
> > > > > 
> > > > > HTH,
> > > > > 
> > > > > --  
> > > > > Daniel DeLeo
> > > > 
> > > > --  
> > > > Regards  
> > > > nirish okram
> > 
> > --  
> > Regards  
> > nirish okram

--  
Regards  
nirish okram

---

<div class="post-metadata">

**Author:** ![okram999](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/okram999/32/1083_2.png) [@okram999](https://discourse.chef.io/u/okram999)\
**Post date:** [April 9, 2015, 12:44am UTC](https://discourse.chef.io/t/deploy-revision-or-capistrano/6549/11 "2015-04-09T00:44:21Z")

</div>

Where does chef gets this value from #{node.chef\_environment}?

On Wed, Apr 8, 2015 at 12:37 PM, niristotle okram [nirish.okram@gmail.com](mailto:nirish.okram@gmail.com)  
wrote:

> unfortunately i didn't enable the debug, for a node which deployed the  
> code. But i can try that after pushing something new to the remote dev  
> branch alone.  
> Below is the entry from the debug log that doesn't specify anything  
> regarding the branch from which its trying to deploy.
> 
> [2015-04-07T23:45:32+00:00] INFO: Processing  
> deploy\_revision[/opt/mount/oss] action deploy  
> (python\_app::python-app-deploy line 36)  
> [2015-04-07T23:45:32+00:00] DEBUG: deploy\_revision[/opt/mount1/oss]  
> finding current git revision  
> [2015-04-07T23:45:32+00:00] DEBUG: deploy\_revision[/opt/mount1/oss]  
> resolving remote reference  
> [2015-04-07T23:45:32+00:00] DEBUG: deploy\_revision[/opt/mount1/oss] is the  
> latest version
> 
> I always see this printed "fetch updates for origin"
> 
> Thanks
> 
> On Wed, Apr 8, 2015 at 12:06 PM, Morgan Blackthorne \<[stormerider@gmail.com](mailto:stormerider@gmail.com)
> 
> > wrote:
> 
> > And what does chef-client -l info show around that resource?
> > 
> > --  
> > ~_~ StormeRider ~_~
> > 
> > "Every world needs its heroes [...] They inspire us to be better than we  
> > are. And they protect from the darkness that's just around the corner."
> > 
> > (from Smallville Season 6x1: "Zod")
> > 
> > On why I hate the phrase "that's so lame"... [http://bit.ly/Ps3uSS](http://bit.ly/Ps3uSS)
> > 
> > On Wed, Apr 8, 2015 at 12:03 PM, niristotle okram \<[nirish.okram@gmail.com](mailto:nirish.okram@gmail.com)
> > 
> > > wrote:
> > 
> > > oops sorry, i had corrected while i was committing the code. This is  
> > > what i have and which is not working
> > > 
> > > deploy\_revision "/opt/mount1/#{node[:application\_name]}" do
> > > 
> > > repo "#{node[:application\_repo]}"
> > > 
> > > user "python"
> > > 
> > > branch "#{node.chef\_environment}"
> > > 
> > > keep\_releases 10
> > > 
> > > action :deploy
> > > 
> > > migrate false
> > > 
> > > symlink\_before\_migrate.clear
> > > 
> > > create\_dirs\_before\_symlink
> > > 
> > > purge\_before\_symlink.clear
> > > 
> > > symlinks.clear
> > > 
> > > symlinks {}
> > > 
> > > notifies :restart, "service[oss]"
> > > 
> > > end
> > > 
> > > On Wed, Apr 8, 2015 at 11:47 AM, Morgan Blackthorne \<  
> > > [stormerider@gmail.com](mailto:stormerider@gmail.com)\> wrote:
> > > 
> > > > You should either remove the quotes around node.chef\_environment, or  
> > > > string-ize it as "#{node.chef\_environment}". Putting quotes around it but  
> > > > not string-izing it just leads to it being interpreted literally.
> > > > 
> > > > --  
> > > > ~_~ StormeRider ~_~
> > > > 
> > > > "Every world needs its heroes [...] They inspire us to be better than  
> > > > we are. And they protect from the darkness that's just around the corner."
> > > > 
> > > > (from Smallville Season 6x1: "Zod")
> > > > 
> > > > On why I hate the phrase "that's so lame"... [http://bit.ly/Ps3uSS](http://bit.ly/Ps3uSS)
> > > > 
> > > > On Wed, Apr 8, 2015 at 11:25 AM, niristotle okram \<  
> > > > [nirish.okram@gmail.com](mailto:nirish.okram@gmail.com)\> wrote:
> > > > 
> > > > > hi,  
> > > > > I tried out today, but it doesn't seem to pull down the code from the  
> > > > > parameterized branch names. This is what i have for the deploy\_revision:
> > > > > 
> > > > > deploy\_revision "/opt/mount/#{node[:application\_name]}" do
> > > > > 
> > > > > > repo "#{node[:application\_repo]}"  
> > > > > > user "deployer"  
> > > > > > _branch "node.chef\_environment"_  
> > > > > > keep\_releases 10  
> > > > > > action :deploy  
> > > > > > migrate false  
> > > > > > symlink\_before\_migrate.clear  
> > > > > > create\_dirs\_before\_symlink  
> > > > > > purge\_before\_symlink.clear  
> > > > > > symlinks.clear  
> > > > > > symlinks {}  
> > > > > > notifies :restart, "service[abc]"  
> > > > > > end
> > > > > 
> > > > > I have 4 environments (dev, test, staging & production) and i am  
> > > > > trying to make "deploy\_revision" to deploy the codes from the specific _remote  
> > > > > branch to the specific environment_.
> > > > > 
> > > > > And the branches on the repo are:
> > > > > 
> > > > > $ git branch -a
> > > > > 
> > > > > - (detached from origin/test)  
> > > > > master  
> > > > > remotes/origin/HEAD -\> origin/master
> > > > > - remotes/origin/dev\*  
> > > > > remotes/origin/master
> > > > > - remotes/origin/production\*
> > > > > - remotes/origin/staging\*
> > > > > - remotes/origin/test\*
> > > > > 
> > > > > To test it, i pushed a new code to the master. Then merge that the  
> > > > > 'dev' branch.
> > > > > 
> > > > > HEAD is now at 63c6388... version change
> > > > > 
> > > > > The below shows that the other 3 remote branches are behind or not in  
> > > > > par with the dev.
> > > > > 
> > > > > $ git checkout origin/test  
> > > > > Previous HEAD position was 63c6388... version change  
> > > > > _HEAD is now at ad262df_...
> > > > > 
> > > > > $ git checkout origin/staging  
> > > > > _HEAD is now at ad262df._..
> > > > > 
> > > > > $ git checkout origin/production  
> > > > > _HEAD is now at ad262df_...
> > > > > 
> > > > > But strange that, when i run chef-client : the code version are same  
> > > > > on dev, stage and prod .. while test have a different version. The deploy  
> > > > > job says "upto date" in test environment.
> > > > > 
> > > > > On Tue, Apr 7, 2015 at 1:51 PM, Daniel DeLeo [dan@kallistec.com](mailto:dan@kallistec.com)  
> > > > > wrote:
> > > > > 
> > > > > > On Tuesday, April 7, 2015 at 1:30 PM, niristotle okram wrote:
> > > > > > 
> > > > > > > i just noticed 'branch' as an attribute. So, i added the line for  
> > > > > > > the branch like this:
> > > > > > > 
> > > > > > > deploy\_revision "/opt/mount/#{node[:application\_name]}" do  
> > > > > > > repo "#{node[:application\_repo]}"  
> > > > > > > user "deployer"  
> > > > > > > branch "node.chef\_environment"  
> > > > > > > keep\_releases 10  
> > > > > > > action :deploy  
> > > > > > > migrate false  
> > > > > > > symlink\_before\_migrate.clear  
> > > > > > > create\_dirs\_before\_symlink  
> > > > > > > purge\_before\_symlink.clear  
> > > > > > > symlinks.clear  
> > > > > > > symlinks {}  
> > > > > > > notifies :restart, "service[abc]"  
> > > > > > > end
> > > > > > > 
> > > > > > > Does this look good and was this attribute designed for this. My  
> > > > > > > test nodes are in a freeze state & hence i am unable to test out  
> > > > > > > That will work the way you want.
> > > > > > 
> > > > > > As for whether you should do code deployments with chef, it’s a  
> > > > > > complicated topic. To some degree, your application code and infra code are  
> > > > > > coupled, as the point of the infra code is to get you a system that can  
> > > > > > correctly run your app code. Since your app code will have different  
> > > > > > requirements over time (need different versions of your VM, supporting  
> > > > > > libraries, etc.), it makes sense to develop and publish them together. The  
> > > > > > downside is that deployment of new code is harder to orchestrate, since you  
> > > > > > normally want chef to run on an interval to ensure your config is up to  
> > > > > > date. Which means you need to be okay with deployments happening over a  
> > > > > > longer timespan, or add some orchestration component (at small enough scale  
> > > > > > this can just be knife ssh) to force chef-client runs to occur. Another  
> > > > > > downside is that chef-client runs involve idempotency checks for all the  
> > > > > > components beneath your app, which in turn means that your deploys can fail  
> > > > > > if your other cookbooks depend on an unrelated external resource (like an  
> > > > > > apt mirror or something) that happens to be down. Also, chef-client will  
> > > > > > spend time running ohai and doing idempotency checks on other resources  
> > > > > > before it deploys your application, so it will be slower than using a  
> > > > > > different tool. This can be mitigated with override run lists, but there  
> > > > > > are some rough edges to those.
> > > > > > 
> > > > > > HTH,
> > > > > > 
> > > > > > --  
> > > > > > Daniel DeLeo
> > > > > 
> > > > > --  
> > > > > Regards  
> > > > > nirish okram
> > > 
> > > --  
> > > Regards  
> > > nirish okram
> 
> --  
> Regards  
> nirish okram

--  
Regards  
nirish okram

---

<div class="post-metadata">

**Author:** ![Bill\_Warner](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/bill_warner/32/973_2.png) [@Bill\_Warner](https://discourse.chef.io/u/Bill_Warner)\
**Post date:** [April 9, 2015, 1:18am UTC](https://discourse.chef.io/t/deploy-revision-or-capistrano/6549/12 "2015-04-09T01:18:33Z")

</div>

I really like having my build system (jenkins) use fpm to create packages  
and upload them to a repository. I maintain different repository for dev  
qa staging and prod and can promote the packages through the cycle.  
Jenkins also controls the deployment to dev and qa automagically after  
successful build/test. As we build confidence we may eventually have it  
deploy to prod as well but still have a lot of testing to do.

-Bill  
On Apr 7, 2015 3:20 PM, "Ranjib Dey" [dey.ranjib@gmail.com](mailto:dey.ranjib@gmail.com) wrote:

> I'll jot down my learning from practicing both chef based as well as cap  
> based deployments extensively:  
> Cap:  
> Pros:
> 
> 1. Dev centric, you get control the exact order or time of deployments.
> 2. Very easy to adopt for rails and similar projects, UX feels similar to  
> func, but ruby compatible idioms
> 3. Custom deployment strategies, like blue-gree/canary/dark launching etc  
> are lot easier with cap (most of them end up grouping hosts  
> Cons:
> 4. Encourages checking in configuration in the code, like all your  
> environment details. This is pain if you environment changes, hosts get  
> added etc
> 5. Since everything is triggered from a central place, the whole process  
> is susceptible to failure of the central node (can be a CI agent, can be a  
> developers laptop)
> 
> Chef:  
> pros:
> 
> 1. Same style of deployment as capistrano (symlinks. hooks etc)
> 2. decentralized, pull based. Things will be deployed eventually.  
> cons:
> 3. deployment is tied with system changes/rollout
> 4. you cant control the order of deployments (like what if you decide to  
> do the db migration first, on one host, then do canary deployment in a  
> subset etc)
> 
> You can go hybrid, mix n match things, like:
> 
> 1. cap can use chef to search and auto populate the hosts
> 2. deploy via chef can be captured in a separate recipe which can be used  
> in conjunction with the full blown chef run, or just via chef-client -o  
> 'recipe[deploy]'
> 3. you can use blender to orchestrate the chef runs (with or without  
> deployment), this also opens up the possibilty to use serf or other non-ssh  
> based deployment triggers, which works lot better when u have lot of  
> servers, or network is flaky between the trigger point and deployment  
> target host
> 
> Over all, i'll recommend consider you requirement and your team's strength  
> above everything, at the end they are the one who will maintain it
> 
> cheers  
> ranjib
> 
> On Tue, Apr 7, 2015 at 1:51 PM, Daniel DeLeo [dan@kallistec.com](mailto:dan@kallistec.com) wrote:
> 
> > On Tuesday, April 7, 2015 at 1:30 PM, niristotle okram wrote:
> > 
> > > i just noticed 'branch' as an attribute. So, i added the line for the  
> > > branch like this:
> > > 
> > > deploy\_revision "/opt/mount/#{node[:application\_name]}" do  
> > > repo "#{node[:application\_repo]}"  
> > > user "deployer"  
> > > branch "node.chef\_environment"  
> > > keep\_releases 10  
> > > action :deploy  
> > > migrate false  
> > > symlink\_before\_migrate.clear  
> > > create\_dirs\_before\_symlink  
> > > purge\_before\_symlink.clear  
> > > symlinks.clear  
> > > symlinks {}  
> > > notifies :restart, "service[abc]"  
> > > end
> > > 
> > > Does this look good and was this attribute designed for this. My test  
> > > nodes are in a freeze state & hence i am unable to test out  
> > > That will work the way you want.
> > 
> > As for whether you should do code deployments with chef, it’s a  
> > complicated topic. To some degree, your application code and infra code are  
> > coupled, as the point of the infra code is to get you a system that can  
> > correctly run your app code. Since your app code will have different  
> > requirements over time (need different versions of your VM, supporting  
> > libraries, etc.), it makes sense to develop and publish them together. The  
> > downside is that deployment of new code is harder to orchestrate, since you  
> > normally want chef to run on an interval to ensure your config is up to  
> > date. Which means you need to be okay with deployments happening over a  
> > longer timespan, or add some orchestration component (at small enough scale  
> > this can just be knife ssh) to force chef-client runs to occur. Another  
> > downside is that chef-client runs involve idempotency checks for all the  
> > components beneath your app, which in turn means that your deploys can fail  
> > if your other cookbooks depend on an unrelated external resource (like an  
> > apt mirror or something) that happens to be down. Also, chef-client will  
> > spend time running ohai and doing idempotency checks on other resources  
> > before it deploys your application, so it will be slower than using a  
> > different tool. This can be mitigated with override run lists, but there  
> > are some rough edges to those.
> > 
> > HTH,
> > 
> > --  
> > Daniel DeLeo

---

<div class="post-metadata">

**Author:** ![okram999](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/okram999/32/1083_2.png) [@okram999](https://discourse.chef.io/u/okram999)\
**Post date:** [April 27, 2015, 11:35pm UTC](https://discourse.chef.io/t/deploy-revision-or-capistrano/6549/13 "2015-04-27T23:35:58Z")

</div>

Just wanted to bring this thread to closure with what i finally end up  
doing.  
My desire to deploy codes using the chef's "deploy\_revision" from specific  
branches of the repo was achieved with the below block

deploy\_revision "/opt/mount1/#{node[:application\_name]}" do

repo "#{node[:application\_repo]}"

user "python"

_revision node.chef\_environment_

keep\_releases 10

action :deploy

migrate false

symlink\_before\_migrate.clear

create\_dirs\_before\_symlink

purge\_before\_symlink.clear

symlinks.clear

symlinks {}

notifies :restart, "service[oss]"

end

But i have decided to use capistrano, because i don't think there is a much  
flexibility with chef when it comes to roll back. I think i would have to  
change the action :deploy to :rollback. then push the change to chef-server  
and then perform chef-client. Just too much work!!!

With the cap, i created a jenkins job and use some clicks to perform  
deploy. So far, i dont have a job for rollback yet. I have just started to  
test the deploy job.. Keeping the fingers crossed

On Wed, Apr 8, 2015 at 6:18 PM, Bill Warner [bill.warner@gmail.com](mailto:bill.warner@gmail.com) wrote:

> I really like having my build system (jenkins) use fpm to create packages  
> and upload them to a repository. I maintain different repository for dev  
> qa staging and prod and can promote the packages through the cycle.  
> Jenkins also controls the deployment to dev and qa automagically after  
> successful build/test. As we build confidence we may eventually have it  
> deploy to prod as well but still have a lot of testing to do.
> 
> -Bill  
> On Apr 7, 2015 3:20 PM, "Ranjib Dey" [dey.ranjib@gmail.com](mailto:dey.ranjib@gmail.com) wrote:
> 
> > I'll jot down my learning from practicing both chef based as well as cap  
> > based deployments extensively:  
> > Cap:  
> > Pros:
> > 
> > 1. Dev centric, you get control the exact order or time of deployments.
> > 2. Very easy to adopt for rails and similar projects, UX feels similar to  
> > func, but ruby compatible idioms
> > 3. Custom deployment strategies, like blue-gree/canary/dark launching etc  
> > are lot easier with cap (most of them end up grouping hosts  
> > Cons:
> > 4. Encourages checking in configuration in the code, like all your  
> > environment details. This is pain if you environment changes, hosts get  
> > added etc
> > 5. Since everything is triggered from a central place, the whole process  
> > is susceptible to failure of the central node (can be a CI agent, can be a  
> > developers laptop)
> > 
> > Chef:  
> > pros:
> > 
> > 1. Same style of deployment as capistrano (symlinks. hooks etc)
> > 2. decentralized, pull based. Things will be deployed eventually.  
> > cons:
> > 3. deployment is tied with system changes/rollout
> > 4. you cant control the order of deployments (like what if you decide to  
> > do the db migration first, on one host, then do canary deployment in a  
> > subset etc)
> > 
> > You can go hybrid, mix n match things, like:
> > 
> > 1. cap can use chef to search and auto populate the hosts
> > 2. deploy via chef can be captured in a separate recipe which can be used  
> > in conjunction with the full blown chef run, or just via chef-client -o  
> > 'recipe[deploy]'
> > 3. you can use blender to orchestrate the chef runs (with or without  
> > deployment), this also opens up the possibilty to use serf or other non-ssh  
> > based deployment triggers, which works lot better when u have lot of  
> > servers, or network is flaky between the trigger point and deployment  
> > target host
> > 
> > Over all, i'll recommend consider you requirement and your team's  
> > strength above everything, at the end they are the one who will maintain it
> > 
> > cheers  
> > ranjib
> > 
> > On Tue, Apr 7, 2015 at 1:51 PM, Daniel DeLeo [dan@kallistec.com](mailto:dan@kallistec.com) wrote:
> > 
> > > On Tuesday, April 7, 2015 at 1:30 PM, niristotle okram wrote:
> > > 
> > > > i just noticed 'branch' as an attribute. So, i added the line for the  
> > > > branch like this:
> > > > 
> > > > deploy\_revision "/opt/mount/#{node[:application\_name]}" do  
> > > > repo "#{node[:application\_repo]}"  
> > > > user "deployer"  
> > > > branch "node.chef\_environment"  
> > > > keep\_releases 10  
> > > > action :deploy  
> > > > migrate false  
> > > > symlink\_before\_migrate.clear  
> > > > create\_dirs\_before\_symlink  
> > > > purge\_before\_symlink.clear  
> > > > symlinks.clear  
> > > > symlinks {}  
> > > > notifies :restart, "service[abc]"  
> > > > end
> > > > 
> > > > Does this look good and was this attribute designed for this. My test  
> > > > nodes are in a freeze state & hence i am unable to test out  
> > > > That will work the way you want.
> > > 
> > > As for whether you should do code deployments with chef, it’s a  
> > > complicated topic. To some degree, your application code and infra code are  
> > > coupled, as the point of the infra code is to get you a system that can  
> > > correctly run your app code. Since your app code will have different  
> > > requirements over time (need different versions of your VM, supporting  
> > > libraries, etc.), it makes sense to develop and publish them together. The  
> > > downside is that deployment of new code is harder to orchestrate, since you  
> > > normally want chef to run on an interval to ensure your config is up to  
> > > date. Which means you need to be okay with deployments happening over a  
> > > longer timespan, or add some orchestration component (at small enough scale  
> > > this can just be knife ssh) to force chef-client runs to occur. Another  
> > > downside is that chef-client runs involve idempotency checks for all the  
> > > components beneath your app, which in turn means that your deploys can fail  
> > > if your other cookbooks depend on an unrelated external resource (like an  
> > > apt mirror or something) that happens to be down. Also, chef-client will  
> > > spend time running ohai and doing idempotency checks on other resources  
> > > before it deploys your application, so it will be slower than using a  
> > > different tool. This can be mitigated with override run lists, but there  
> > > are some rough edges to those.
> > > 
> > > HTH,
> > > 
> > > --  
> > > Daniel DeLeo

--  
Regards  
nirish okram

---

<div class="post-metadata">

**Author:** ![Yoshi\_Spendiff](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/yoshi_spendiff/32/13_2.png) [@Yoshi\_Spendiff](https://discourse.chef.io/u/Yoshi_Spendiff)\
**Post date:** [April 28, 2015, 10:37pm UTC](https://discourse.chef.io/t/deploy-revision-or-capistrano/6549/14 "2015-04-28T22:37:49Z")

</div>

Not really chef related, but if you can get a deploy working there should  
be nothing stopping a rollback working with cap [stage] deploy:rollback

For what it's worth we were in a similar position to you but decided we  
wanted our application deployment separate from our Chef management also,  
Chef just didn't quite seem flexible enough to do what we wanted with  
little fuss. We're heading towards using CodeDeploy (we're on AWS) as it  
lets us pick a build and deploy to any environment, but still on Cap for  
now.

On Mon, Apr 27, 2015 at 4:35 PM, niristotle okram [nirish.okram@gmail.com](mailto:nirish.okram@gmail.com)  
wrote:

> Just wanted to bring this thread to closure with what i finally end up  
> doing.  
> My desire to deploy codes using the chef's "deploy\_revision" from specific  
> branches of the repo was achieved with the below block
> 
> deploy\_revision "/opt/mount1/#{node[:application\_name]}" do
> 
> repo "#{node[:application\_repo]}"
> 
> user "python"
> 
> _revision node.chef\_environment_
> 
> keep\_releases 10
> 
> action :deploy
> 
> migrate false
> 
> symlink\_before\_migrate.clear
> 
> create\_dirs\_before\_symlink
> 
> purge\_before\_symlink.clear
> 
> symlinks.clear
> 
> symlinks {}
> 
> notifies :restart, "service[oss]"
> 
> end
> 
> But i have decided to use capistrano, because i don't think there is a  
> much flexibility with chef when it comes to roll back. I think i would have  
> to change the action :deploy to :rollback. then push the change to  
> chef-server and then perform chef-client. Just too much work!!!
> 
> With the cap, i created a jenkins job and use some clicks to perform  
> deploy. So far, i dont have a job for rollback yet. I have just started to  
> test the deploy job.. Keeping the fingers crossed
> 
> On Wed, Apr 8, 2015 at 6:18 PM, Bill Warner [bill.warner@gmail.com](mailto:bill.warner@gmail.com) wrote:
> 
> > I really like having my build system (jenkins) use fpm to create packages  
> > and upload them to a repository. I maintain different repository for dev  
> > qa staging and prod and can promote the packages through the cycle.  
> > Jenkins also controls the deployment to dev and qa automagically after  
> > successful build/test. As we build confidence we may eventually have it  
> > deploy to prod as well but still have a lot of testing to do.
> > 
> > -Bill  
> > On Apr 7, 2015 3:20 PM, "Ranjib Dey" [dey.ranjib@gmail.com](mailto:dey.ranjib@gmail.com) wrote:
> > 
> > > I'll jot down my learning from practicing both chef based as well as cap  
> > > based deployments extensively:  
> > > Cap:  
> > > Pros:
> > > 
> > > 1. Dev centric, you get control the exact order or time of deployments.
> > > 2. Very easy to adopt for rails and similar projects, UX feels similar  
> > > to func, but ruby compatible idioms
> > > 3. Custom deployment strategies, like blue-gree/canary/dark launching  
> > > etc are lot easier with cap (most of them end up grouping hosts  
> > > Cons:
> > > 4. Encourages checking in configuration in the code, like all your  
> > > environment details. This is pain if you environment changes, hosts get  
> > > added etc
> > > 5. Since everything is triggered from a central place, the whole process  
> > > is susceptible to failure of the central node (can be a CI agent, can be a  
> > > developers laptop)
> > > 
> > > Chef:  
> > > pros:
> > > 
> > > 1. Same style of deployment as capistrano (symlinks. hooks etc)
> > > 2. decentralized, pull based. Things will be deployed eventually.  
> > > cons:
> > > 3. deployment is tied with system changes/rollout
> > > 4. you cant control the order of deployments (like what if you decide to  
> > > do the db migration first, on one host, then do canary deployment in a  
> > > subset etc)
> > > 
> > > You can go hybrid, mix n match things, like:
> > > 
> > > 1. cap can use chef to search and auto populate the hosts
> > > 2. deploy via chef can be captured in a separate recipe which can be  
> > > used in conjunction with the full blown chef run, or just via chef-client  
> > > -o 'recipe[deploy]'
> > > 3. you can use blender to orchestrate the chef runs (with or without  
> > > deployment), this also opens up the possibilty to use serf or other non-ssh  
> > > based deployment triggers, which works lot better when u have lot of  
> > > servers, or network is flaky between the trigger point and deployment  
> > > target host
> > > 
> > > Over all, i'll recommend consider you requirement and your team's  
> > > strength above everything, at the end they are the one who will maintain it
> > > 
> > > cheers  
> > > ranjib
> > > 
> > > On Tue, Apr 7, 2015 at 1:51 PM, Daniel DeLeo [dan@kallistec.com](mailto:dan@kallistec.com) wrote:
> > > 
> > > > On Tuesday, April 7, 2015 at 1:30 PM, niristotle okram wrote:
> > > > 
> > > > > i just noticed 'branch' as an attribute. So, i added the line for the  
> > > > > branch like this:
> > > > > 
> > > > > deploy\_revision "/opt/mount/#{node[:application\_name]}" do  
> > > > > repo "#{node[:application\_repo]}"  
> > > > > user "deployer"  
> > > > > branch "node.chef\_environment"  
> > > > > keep\_releases 10  
> > > > > action :deploy  
> > > > > migrate false  
> > > > > symlink\_before\_migrate.clear  
> > > > > create\_dirs\_before\_symlink  
> > > > > purge\_before\_symlink.clear  
> > > > > symlinks.clear  
> > > > > symlinks {}  
> > > > > notifies :restart, "service[abc]"  
> > > > > end
> > > > > 
> > > > > Does this look good and was this attribute designed for this. My test  
> > > > > nodes are in a freeze state & hence i am unable to test out  
> > > > > That will work the way you want.
> > > > 
> > > > As for whether you should do code deployments with chef, it’s a  
> > > > complicated topic. To some degree, your application code and infra code are  
> > > > coupled, as the point of the infra code is to get you a system that can  
> > > > correctly run your app code. Since your app code will have different  
> > > > requirements over time (need different versions of your VM, supporting  
> > > > libraries, etc.), it makes sense to develop and publish them together. The  
> > > > downside is that deployment of new code is harder to orchestrate, since you  
> > > > normally want chef to run on an interval to ensure your config is up to  
> > > > date. Which means you need to be okay with deployments happening over a  
> > > > longer timespan, or add some orchestration component (at small enough scale  
> > > > this can just be knife ssh) to force chef-client runs to occur. Another  
> > > > downside is that chef-client runs involve idempotency checks for all the  
> > > > components beneath your app, which in turn means that your deploys can fail  
> > > > if your other cookbooks depend on an unrelated external resource (like an  
> > > > apt mirror or something) that happens to be down. Also, chef-client will  
> > > > spend time running ohai and doing idempotency checks on other resources  
> > > > before it deploys your application, so it will be slower than using a  
> > > > different tool. This can be mitigated with override run lists, but there  
> > > > are some rough edges to those.
> > > > 
> > > > HTH,
> > > > 
> > > > --  
> > > > Daniel DeLeo
> 
> --  
> Regards  
> nirish okram

--  
Yoshi Spendiff  
Ops Engineer  
Indochino  
Mobile: +1 778 952 2025  
Email: [yoshi.spendiff@indochino.com](mailto:yoshi.spendiff@indochino.com)

---

<div class="post-metadata">

**Author:** ![kallistec](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/kallistec/32/23_2.png) [@kallistec](https://discourse.chef.io/u/kallistec)\
**Post date:** [April 28, 2015, 10:59pm UTC](https://discourse.chef.io/t/deploy-revision-or-capistrano/6549/15 "2015-04-28T22:59:43Z")

</div>

The deploy resource can detect a rollback if you set the desired revision to a revision that exists in the deploy cache. So you can store the desired revision in a data bag item or something and then control the versioning that way.

--  
Daniel DeLeo

On Tuesday, April 28, 2015 at 3:37 PM, Yoshi Spendiff wrote:

> Not really chef related, but if you can get a deploy working there should be nothing stopping a rollback working with cap [stage] deploy:rollback
> 
> For what it's worth we were in a similar position to you but decided we wanted our application deployment separate from our Chef management also, Chef just didn't quite seem flexible enough to do what we wanted with little fuss. We're heading towards using CodeDeploy (we're on AWS) as it lets us pick a build and deploy to any environment, but still on Cap for now.
> 
> On Mon, Apr 27, 2015 at 4:35 PM, niristotle okram \<[nirish.okram@gmail.com](mailto:nirish.okram@gmail.com) ([mailto:nirish.okram@gmail.com](mailto:nirish.okram@gmail.com))\> wrote:
> 
> > Just wanted to bring this thread to closure with what i finally end up doing.  
> > My desire to deploy codes using the chef's "deploy\_revision" from specific branches of the repo was achieved with the below block
> > 
> > deploy\_revision "/opt/mount1/#{node[:application\_name]}" do  
> > repo "#{node[:application\_repo]}"  
> > user "python"  
> > revision node.chef\_environment  
> > keep\_releases 10  
> > action :deploy  
> > migrate false  
> > symlink\_before\_migrate.clear  
> > create\_dirs\_before\_symlink  
> > purge\_before\_symlink.clear  
> > symlinks.clear  
> > symlinks {}  
> > notifies :restart, "service[oss]"  
> > end
> > 
> > But i have decided to use capistrano, because i don't think there is a much flexibility with chef when it comes to roll back. I think i would have to change the action :deploy to :rollback. then push the change to chef-server and then perform chef-client. Just too much work!!!
> > 
> > With the cap, i created a jenkins job and use some clicks to perform deploy. So far, i dont have a job for rollback yet. I have just started to test the deploy job.. Keeping the fingers crossed
> > 
> > On Wed, Apr 8, 2015 at 6:18 PM, Bill Warner \<[bill.warner@gmail.com](mailto:bill.warner@gmail.com) ([mailto:bill.warner@gmail.com](mailto:bill.warner@gmail.com))\> wrote:
> > 
> > > I really like having my build system (jenkins) use fpm to create packages and upload them to a repository. I maintain different repository for dev qa staging and prod and can promote the packages through the cycle. Jenkins also controls the deployment to dev and qa automagically after successful build/test. As we build confidence we may eventually have it deploy to prod as well but still have a lot of testing to do.  
> > > -Bill  
> > > On Apr 7, 2015 3:20 PM, "Ranjib Dey" \<[dey.ranjib@gmail.com](mailto:dey.ranjib@gmail.com) ([mailto:dey.ranjib@gmail.com](mailto:dey.ranjib@gmail.com))\> wrote:
> > > 
> > > > I'll jot down my learning from practicing both chef based as well as cap based deployments extensively:  
> > > > Cap:  
> > > > Pros:
> > > > 
> > > > 1. Dev centric, you get control the exact order or time of deployments.
> > > > 2. Very easy to adopt for rails and similar projects, UX feels similar to func, but ruby compatible idioms
> > > > 3. Custom deployment strategies, like blue-gree/canary/dark launching etc are lot easier with cap (most of them end up grouping hosts  
> > > > Cons:
> > > > 4. Encourages checking in configuration in the code, like all your environment details. This is pain if you environment changes, hosts get added etc
> > > > 5. Since everything is triggered from a central place, the whole process is susceptible to failure of the central node (can be a CI agent, can be a developers laptop)
> > > > 
> > > > Chef:  
> > > > pros:
> > > > 
> > > > 1. Same style of deployment as capistrano (symlinks. hooks etc)
> > > > 2. decentralized, pull based. Things will be deployed eventually.  
> > > > cons:
> > > > 3. deployment is tied with system changes/rollout
> > > > 4. you cant control the order of deployments (like what if you decide to do the db migration first, on one host, then do canary deployment in a subset etc)
> > > > 
> > > > You can go hybrid, mix n match things, like:
> > > > 
> > > > 1. cap can use chef to search and auto populate the hosts
> > > > 2. deploy via chef can be captured in a separate recipe which can be used in conjunction with the full blown chef run, or just via chef-client -o 'recipe[deploy]'
> > > > 3. you can use blender to orchestrate the chef runs (with or without deployment), this also opens up the possibilty to use serf or other non-ssh based deployment triggers, which works lot better when u have lot of servers, or network is flaky between the trigger point and deployment target host
> > > > 
> > > > Over all, i'll recommend consider you requirement and your team's strength above everything, at the end they are the one who will maintain it
> > > > 
> > > > cheers  
> > > > ranjib
> > > > 
> > > > On Tue, Apr 7, 2015 at 1:51 PM, Daniel DeLeo \<[dan@kallistec.com](mailto:dan@kallistec.com) ([mailto:dan@kallistec.com](mailto:dan@kallistec.com))\> wrote:
> > > > 
> > > > > On Tuesday, April 7, 2015 at 1:30 PM, niristotle okram wrote:
> > > > > 
> > > > > > i just noticed 'branch' as an attribute. So, i added the line for the branch like this:
> > > > > > 
> > > > > > deploy\_revision "/opt/mount/#{node[:application\_name]}" do  
> > > > > > repo "#{node[:application\_repo]}"  
> > > > > > user "deployer"  
> > > > > > branch "node.chef\_environment"  
> > > > > > keep\_releases 10  
> > > > > > action :deploy  
> > > > > > migrate false  
> > > > > > symlink\_before\_migrate.clear  
> > > > > > create\_dirs\_before\_symlink  
> > > > > > purge\_before\_symlink.clear  
> > > > > > symlinks.clear  
> > > > > > symlinks {}  
> > > > > > notifies :restart, "service[abc]"  
> > > > > > end
> > > > > > 
> > > > > > Does this look good and was this attribute designed for this. My test nodes are in a freeze state & hence i am unable to test out  
> > > > > > That will work the way you want.
> > > > > 
> > > > > As for whether you should do code deployments with chef, it’s a complicated topic. To some degree, your application code and infra code are coupled, as the point of the infra code is to get you a system that can correctly run your app code. Since your app code will have different requirements over time (need different versions of your VM, supporting libraries, etc.), it makes sense to develop and publish them together. The downside is that deployment of new code is harder to orchestrate, since you normally want chef to run on an interval to ensure your config is up to date. Which means you need to be okay with deployments happening over a longer timespan, or add some orchestration component (at small enough scale this can just be knife ssh) to force chef-client runs to occur. Another downside is that chef-client runs involve idempotency checks for all the components beneath your app, which in turn means that your deploys can fail if your other cookbooks depend on an unrelated external resource (like an apt mirror or something) that happens to be down. Also, chef-client will spend time running ohai and doing idempotency checks on other resources before it deploys your application, so it will be slower than using a different tool. This can be mitigated with override run lists, but there are some rough edges to those.
> > > > > 
> > > > > HTH,
> > > > > 
> > > > > --  
> > > > > Daniel DeLeo
> > 
> > --  
> > Regards  
> > nirish okram
> 
> --  
> Yoshi Spendiff  
> Ops Engineer  
> Indochino  
> Mobile: +1 778 952 2025  
> Email: [yoshi.spendiff@indochino.com](mailto:yoshi.spendiff@indochino.com) ([mailto:yoshi.spendiff@indochino.com](mailto:yoshi.spendiff@indochino.com))