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.

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

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

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.

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

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

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.

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 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:

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.

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

Dev centric, you get control the exact order or time of deployments.

Very easy to adopt for rails and similar projects, UX feels similar to
func, but ruby compatible idioms

Custom deployment strategies, like blue-gree/canary/dark launching etc
are lot easier with cap (most of them end up grouping hosts
Cons:

Encourages checking in configuration in the code, like all your
environment details. This is pain if you environment changes, hosts get
added etc

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:

Same style of deployment as capistrano (symlinks. hooks etc)

decentralized, pull based. Things will be deployed eventually.
cons:

deployment is tied with system changes/rollout

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:

cap can use chef to search and auto populate the hosts

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]’

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

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.

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.

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.”

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.

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.”

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.

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.”

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.

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.

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.”

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.

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.

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.”

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.

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.

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

Dev centric, you get control the exact order or time of deployments.

Very easy to adopt for rails and similar projects, UX feels similar to
func, but ruby compatible idioms

Custom deployment strategies, like blue-gree/canary/dark launching etc
are lot easier with cap (most of them end up grouping hosts
Cons:

Encourages checking in configuration in the code, like all your
environment details. This is pain if you environment changes, hosts get
added etc

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:

Same style of deployment as capistrano (symlinks. hooks etc)

decentralized, pull based. Things will be deployed eventually.
cons:

deployment is tied with system changes/rollout

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:

cap can use chef to search and auto populate the hosts

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]’

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

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.

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

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.

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

Dev centric, you get control the exact order or time of deployments.

Very easy to adopt for rails and similar projects, UX feels similar to
func, but ruby compatible idioms

Custom deployment strategies, like blue-gree/canary/dark launching etc
are lot easier with cap (most of them end up grouping hosts
Cons:

Encourages checking in configuration in the code, like all your
environment details. This is pain if you environment changes, hosts get
added etc

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:

Same style of deployment as capistrano (symlinks. hooks etc)

decentralized, pull based. Things will be deployed eventually.
cons:

deployment is tied with system changes/rollout

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:

cap can use chef to search and auto populate the hosts

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]’

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

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.

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.

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

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.

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

Dev centric, you get control the exact order or time of deployments.

Very easy to adopt for rails and similar projects, UX feels similar
to func, but ruby compatible idioms

Custom deployment strategies, like blue-gree/canary/dark launching
etc are lot easier with cap (most of them end up grouping hosts
Cons:

Encourages checking in configuration in the code, like all your
environment details. This is pain if you environment changes, hosts get
added etc

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:

Same style of deployment as capistrano (symlinks. hooks etc)

decentralized, pull based. Things will be deployed eventually.
cons:

deployment is tied with system changes/rollout

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:

cap can use chef to search and auto populate the hosts

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]’

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

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.

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.

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

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

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:

Dev centric, you get control the exact order or time of deployments.

Very easy to adopt for rails and similar projects, UX feels similar to func, but ruby compatible idioms

Custom deployment strategies, like blue-gree/canary/dark launching etc are lot easier with cap (most of them end up grouping hosts
Cons:

Encourages checking in configuration in the code, like all your environment details. This is pain if you environment changes, hosts get added etc

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:

Same style of deployment as capistrano (symlinks. hooks etc)

decentralized, pull based. Things will be deployed eventually.
cons:

deployment is tied with system changes/rollout

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:

cap can use chef to search and auto populate the hosts

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]’

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

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.