<p>Configuration management tools are used to get a system into a known state. Deployment tools deploy new program files and program data to a system. At the end of the day, both types of tools do some combination of:</p>

<ul>
<li>Determine the current state of the system. </li>
<li>Transfer files to the system.</li>
<li>Add or change persistent data (e.g. configuration files, database data, registry settings)</li>
<li>Start or restart programs. </li>
</ul>

<p>Configuration management tools have declarative languages which specify the state of the system. Deployment tools have imperative languages which tell the system to do things. A DevOps person needs to do both. </p>

<p>Using the deployment tool Capistrano, it is clumsy to use its language to tell the system to ensure that the web server is active. You have to issue a command to restart the web server, and another to check to see if the web server is up. It is a kludge to get the web server into a known state. </p>

<p>Using the configuration management tool Ansible, it is clumsy to restart a web server. The language lets you tell the web server to be "up", but if you specifically want it to be restarted, you have to set its state to "restarted". But there is no easy way to check if the web server has been restarted. This is a kludge in Ansible to enable one-off operations. </p>

<p>Some folks prefer doing both types of jobs with one tool, and working around the rough edges. Other folks prefer having two tools to do almost the same thing, but without rough edges. To answer the question, "appropriateness" is a matter of taste. This answer explains why. </p>

CC BY-SA 3.0
2017-03-27T04:44:40.150Z
I agree on Capistrano being slightly awkward for this case. It is usually used as namespace for remotely executed ruby scripts/snippets/lambda over ssh. Your section on Ansible is not correct. You might want to research it a bit and fix it. Good first post, but please work on it a bit more.
Jiri Klouda
CC BY-SA 3.0
2017-04-15T17:31:39.570Z
@JiriKlouda whats wrong with the Ansible section? Do you mean the section `no easy way to check if the web server has been restarted` in that it could be checked by registering a variable?
David Vasandani
CC BY-SA 3.0
2017-04-15T23:21:06.653Z
There are multiple ways to do it, author of the answer just doesn't know them. Feel free to turn it into separate question as comments are not good place for technical answers.
Jiri Klouda
CC BY-SA 3.0
2017-03-27T03:12:59.670Z
2017-03-27T03:12:59.670Z
Jay Godse
<p><strong>TL;DR</strong>: Just use Ansbile, it is <strong>both</strong> configuration and deployment tool :)</p>

<p>There are several types of deployment: </p>

<ul>
<li><p><strong>Application</strong> based (files, archives packages) </p></li>
<li><p><strong>Container</strong> based (includes VMs, Habitat, LXC, Docker)</p></li>
<li><p><strong>Function</strong> based (Micro services / Lambdas / Functions)</p></li>
</ul>

<p>I assume in this case we speak only about application updates on server(s).</p>

<hr>

<p>For deployment you need to have two things happen:</p>

<ol>
<li>Correct files or packages need to move to the server. </li>
<li>Configuration and service states need to change.</li>
</ol>

<hr>

<p>Now for (1) you can use multiple strategies:</p>

<ul>
<li>Artifact Repositories / Syncing</li>
<li>Package Repositories / Package Managers</li>
<li>Version Control System / Updating + Compiling (optionally)</li>
<li>File transfer protocols (scp, rsync, ftp)</li>
<li>Deployment Tools</li>
</ul>

<p>For the (2) you can use:</p>

<ul>
<li>Configuration management tools</li>
<li>Deployment Tools</li>
</ul>

<p>So while the Deployment Tools are a way to do deployment all in one, they are not always the best strategy. Sometimes you want to use combination of these ways for deployment. You most likely already use package managers at least on your servers already. You most likely run configuration tools anyway. The problem with some of the configuration tools was a proper orchestration among multiple servers, but now even Chef and Puppet can do that quite well. Ansible has been always good at this.</p>

<p>From <em>personal experience</em>, I've used all combinations, but currently we use Capistrano for deployment and Ansible sync for configuration management, and VCS and package repositories for file transfers, but there are issues with Capistrano and we are planing to move away from it to unify on Ansible for both deployment, maintenance and configuration management. </p>

CC BY-SA 3.0
2017-03-29T14:12:08.357Z
My experience with Ansible and Capistrano would lead me to the same conclusion. I'd just go with Ansible. And the nice thing about Ansible is that its "desired state" declarations map very nicely to underlying imperative commands.
Jay Godse
CC BY-SA 3.0
2018-04-20T00:06:54.507Z
People sometimes ignore the community contributions around Configuration Management tools. Ansible's community components are, with some noteable exceptions (like DebOps), are not yet as polished and feature-complete as Chef's and Puppet's. As a measurement of this, while I found Puppet and Chef are able to both "apply" and *unapply* configuration directives (do or undo a set of changes), Ansible is great at the "apply" part, but not so great at the "unapply" part.
Jesse Adelman
CC BY-SA 3.0
2017-03-28T02:15:32.617Z
2017-03-28T02:15:32.617Z
Jiri Klouda
<p>For software and deploying code to an existing server or inside a Docker container, the answer is relatively simple - No, you don't <em>need</em> both, but you might want both if another tool or utility adds value and is the <a href="https://devops.stackexchange.com/a/657/2845">right tool for the job</a>, however things get more complicated when you are deploying servers and operating systems.</p>

<p>One value-add of a DevOps mentality is treating infrastructure as code and frequently deploying or destroying virtual machines or even bare metal in a highly elasticized environment. Your configuration management system cannot easily netboot and kickstart your server for you and cannot manage repositories, packages and updates/patching for you during and after deployments or in some cases, licensing and entitlements. </p>

<p>For Amazon Web Services, this is rather conveniently manageable by APIs for the most part, but for those of us who have to manage our own data centers, this is not an option. For this reason <a href="https://www.theforeman.org/" rel="nofollow noreferrer">The Foreman</a> project (and <a href="https://access.redhat.com/products/red-hat-satellite" rel="nofollow noreferrer">Red Hat which re-brands this</a>) have found it necessary to bundle <a href="http://www.katello.org/" rel="nofollow noreferrer">Katello</a>, <a href="http://www.candlepinproject.org/" rel="nofollow noreferrer">Candlepin</a> and a configuration manager such as Ansible, Foreman or Puppet together when deploying the <a href="https://theforeman.org/plugins/katello/3.3/installation/index.html" rel="nofollow noreferrer">Katello Scenario</a>. </p>

<p>So while you might be able to get away with using configuration management tools for software code deployments on the Dev side of the house, over on the Ops side, there are several cases where the answer is a resounding "no, configuration management tools are <em>not</em> appropriate to use as deployment tools" Doing so would require a serious re-invention of the wheel and is impractical. You must instead use your configuration management tools to initiate deployments in another tool.</p>

CC BY-SA 3.0
2017-05-22T21:07:36.057Z
Or not,  chef handle gracefully Capistrano like deploys,  chocolatey packages deploys under windows and all well know packages installs (deb, rpm,  msi,  nullsoft,  etc.). It does bring some burden on the packaging side,  which habitat aim to solve,  but that's a configuration management system fairly able to handle deploys,  I can tell it by seeing it doing roughly 40 deploys per week on multiples environments including production, that's not without a high burden beforehand to code it,  but that's not that much above the same thing with any other tool ateotd.
Tensibai
CC BY-SA 3.0
2017-05-23T02:25:11.397Z
Actually The Foreman is neither a provisioning, deployment or configuration management system. It is just a skin which provides a web based UI and framework that glues together a configuration management system (puppet), license management system (candlepin), repository and patch management system (Katello), and a provisioning/deployment system (kickstart). It front-ends all of these different projects and glues them together. While pretty much any configuration management system can install a package, what they can't do is provide patch management in a manner similar to a WSUS server
James Shewey
CC BY-SA 3.0
2017-05-23T02:33:26.197Z
or pin to or deploy specific versions of packages, include packages that are not in upstream repos or mashup repos. My point is that if Red Hat/The Foreman/Katello felt it couldn't be done with *just* a configuration management system - most notably because it lacked the provisioning/deployment piece that that is worth noting.
James Shewey
CC BY-SA 3.0
2017-05-23T05:05:36.517Z
I misread the sentence about katello,  my bad. First comment was for the sake of completeness :)
Tensibai
CC BY-SA 3.0
2017-05-22T19:47:00.907Z
2017-05-22T19:47:00.907Z
James Shewey
<p>Application deployment is a hard thing to pin down because it has a lot of sub-problems. Config management systems are excellent at modeling tasks which are convergent and work with "what is the desired state of the system". In the context of app deployment, this is great for things like deploying bits to a machine, managing configuration files, and setting up system services. What it is extremely bad for is things that are inherently procedural, notably database migrations and service restarts. I usually try to put the convergent logic in Chef and let an external procedural tool (usually Fabric in my case) handle the few remaining bits as well as sequencing the actual converges.</p>

<p>So, basically, you should use both for the pieces they are best at.</p>

CC BY-SA 3.0
2017-03-27T22:57:04.040Z
2017-03-27T22:57:04.040Z
coderanger
<p>In such context the typical advice should be immediately applicable: use the right tool for the job.</p>

<p>But then you also cannot ignore nowadays the almost virulent tendency of software <em>tools</em> to extend functionality into more or less related fields and actually become <em>toolsets</em> for various reasons: cool feature(s) to have, expand customer base, amass more revenue, etc. </p>

<p>For example many file management tools include image viewing features and many image processing tools include file management features. You can move files around and you can view images with either of the tools, often equally well.</p>

<p>Because of this it's quite possible to have entire portions of the software development process covered/overlapped by multiple tool(sets) even if their main feature/capability differs.</p>

<p>So it really boils down to the exact functionality <em>you</em> want to achieve in <em>your particular process</em> and how well one tool or the other does the job <em>in your context</em>. Subjectivity/preferences/convenience included. </p>

<p>Making this question primarily opinion-based ;)</p>

CC BY-SA 3.0
2017-04-04T16:22:17.210Z
I completely agree! More and more organization are developing "DevOps toolchain" specifically with this right tools for the job idea. For more info this wiki pages does a decent job talking about the different tools/jobs: https://en.wikipedia.org/wiki/DevOps_toolchain
Karl Harnagy
CC BY-SA 4.0
2019-02-12T18:32:28.577Z
I'd just add that the more you extend a tool's use beyond its primary purpose, the more effort it will take to do so.  You might be able to use certain tool for both deployment and configuration, but there's a good chance it will be more work (or require side-stepping best practices) than just using two tools.
jschmitter
CC BY-SA 3.0
2017-03-25T13:28:59.370Z
2017-03-25T13:28:59.370Z
Dan Cornilescu
<p>Off the back of my <a href="https://devops.stackexchange.com/a/649/397">answer</a> to the question: <a href="https://devops.stackexchange.com/q/646/397">How can DevOps help to improve Software Escrow procedures?</a> Tensibai had the question:</p>

<blockquote>
  <p>What would necessitate Capistrano on top of puppet or chef?</p>
</blockquote>

<p>My response was to post a link to <a href="http://codefol.io/posts/why-do-we-need-both-capistrano-and-chef" rel="noreferrer">Noah Gibbs' article "Do We Need Both Capistrano and Chef?"</a>.  Personally, I still subscribe to Noah's view that it is most appropriate to:</p>

<ul>
<li>use a specialist deployment tool such as Capistrano for deployments.</li>
<li>use a specialist configuration management tool such as Chef for configuration management.</li>
</ul>

<p>The fundamental approach that each type of tool uses to complete its task is very different:</p>

<ul>
<li><p><strong>Configuration Management Tools</strong> - are about creating and maintaining the desired state of a system, they are inherently idempotent in nature. Examples of configuration management tools are <a href="https://www.chef.io/chef/" rel="noreferrer">Chef</a>, <a href="https://puppet.com/" rel="noreferrer">Puppet</a>, <a href="https://www.ansible.com/" rel="noreferrer">Ansible</a>, <a href="https://msdn.microsoft.com/en-us/powershell/dsc/overview" rel="noreferrer">PowerShell DSC</a>, <a href="https://saltstack.com/" rel="noreferrer">Salt Stack</a>.</p></li>
<li><p><strong>Deployment Tools</strong> - are about delivering <em>versions</em> of software into a hosting environment, they provide functionality to maintain multiple versions of the software on multiple machines and manage which version is "current", they are inherently imperative in nature.  Examples of deployment tools are <a href="http://capistranorb.com/" rel="noreferrer">Capistrano</a>, <a href="https://octopus.com" rel="noreferrer">Octopus Deploy</a>, <a href="https://deployer.org/" rel="noreferrer">Deployer</a> and <a href="https://commando.io/" rel="noreferrer">Command.io</a>.</p></li>
</ul>

<p>I do believe that Configuration Management Tools can do the job of deployment tools and in the case of <a href="https://www.oreilly.com/ideas/an-introduction-to-immutable-infrastructure" rel="noreferrer">Immutable Infrastructure</a> they are the most appropriate tool for the job as software versions on the target don't need to be maintained.</p>

<p><strong>Question:</strong> Have configuration management tools such as Chef, Ansible and Puppet matured to the point that they are capable of fulfilling both the idempotent and imperative models?</p>

CC BY-SA 3.0
2017-03-28T02:36:51.863Z
Ansible always could, Puppet since 4.0
Jiri Klouda
<ansible><deployment><chef><configuration-management><capistrano>
Are configuration management tools appropriate to use as deployment tools?
Richard Slater
# Are configuration management tools appropriate to use as deployment tools?

(Asked by: username_0 on 2017-03-25)

Off the back of my [answer](https://devops.stackexchange.com/a/649/397) to the question: [How can DevOps help to improve Software Escrow procedures?](https://devops.stackexchange.com/q/646/397) username_6 had the question:

> What would necessitate Capistrano on top of puppet or chef?

My response was to post a link to [Noah Gibbs' article "Do We Need Both Capistrano and Chef?"](http://codefol.io/posts/why-do-we-need-both-capistrano-and-chef). Personally, I still subscribe to Noah's view that it is most appropriate to:

* use a specialist deployment tool such as Capistrano for deployments.
* use a specialist configuration management tool such as Chef for configuration management.

The fundamental approach that each type of tool uses to complete its task is very different:

* **Configuration Management Tools** - are about creating and maintaining the desired state of a system, they are inherently idempotent in nature. Examples of configuration management tools are [Chef](https://www.chef.io/chef/), [Puppet](https://puppet.com/), [Ansible](https://www.ansible.com/), [PowerShell DSC](https://msdn.microsoft.com/en-us/powershell/dsc/overview), [Salt Stack](https://saltstack.com/).
* **Deployment Tools** - are about delivering *versions* of software into a hosting environment, they provide functionality to maintain multiple versions of the software on multiple machines and manage which version is "current", they are inherently imperative in nature. Examples of deployment tools are [Capistrano](http://capistranorb.com/), [Octopus Deploy](https://octopus.com), [Deployer](https://deployer.org/) and [Command.io](https://commando.io/).

I do believe that Configuration Management Tools can do the job of deployment tools and in the case of [Immutable Infrastructure](https://www.oreilly.com/ideas/an-introduction-to-immutable-infrastructure) they are the most appropriate tool for the job as software versions on the target don't need to be maintained.

**Question:** Have configuration management tools such as Chef, Ansible and Puppet matured to the point that they are capable of fulfilling both the idempotent and imperative models?

**Tags:** ansible, deployment, chef, configuration-management, capistrano

> **Comments:**
> **username_1**: Ansible always could, Puppet since 4.0  

---

## 5 answers

### Answer by username_8 on 2017-03-25. Score: 10 | Accepted answer

In such context the typical advice should be immediately applicable: use the right tool for the job.

But then you also cannot ignore nowadays the almost virulent tendency of software *tools* to extend functionality into more or less related fields and actually become *toolsets* for various reasons: cool feature(s) to have, expand customer base, amass more revenue, etc.

For example many file management tools include image viewing features and many image processing tools include file management features. You can move files around and you can view images with either of the tools, often equally well.

Because of this it's quite possible to have entire portions of the software development process covered/overlapped by multiple tool(sets) even if their main feature/capability differs.

So it really boils down to the exact functionality *you* want to achieve in *your particular process* and how well one tool or the other does the job *in your context*. Subjectivity/preferences/convenience included.

Making this question primarily opinion-based ;)

> **Comments:**
> **username_9**: I completely agree! More and more organization are developing "DevOps toolchain" specifically with this right tools for the job idea. For more info this wiki pages does a decent job talking about the different tools/jobs: https://en.wikipedia.org/wiki/DevOps_toolchain  
> **username_10**: I'd just add that the more you extend a tool's use beyond its primary purpose, the more effort it will take to do so.  You might be able to use certain tool for both deployment and configuration, but there's a good chance it will be more work (or require side-stepping best practices) than just using two tools.  

---

### Answer by username_2 on 2017-03-27. Score: 6

Configuration management tools are used to get a system into a known state. Deployment tools deploy new program files and program data to a system. At the end of the day, both types of tools do some combination of:

* Determine the current state of the system.
* Transfer files to the system.
* Add or change persistent data (e.g. configuration files, database data, registry settings)
* Start or restart programs.

Configuration management tools have declarative languages which specify the state of the system. Deployment tools have imperative languages which tell the system to do things. A DevOps person needs to do both.

Using the deployment tool Capistrano, it is clumsy to use its language to tell the system to ensure that the web server is active. You have to issue a command to restart the web server, and another to check to see if the web server is up. It is a kludge to get the web server into a known state.

Using the configuration management tool Ansible, it is clumsy to restart a web server. The language lets you tell the web server to be "up", but if you specifically want it to be restarted, you have to set its state to "restarted". But there is no easy way to check if the web server has been restarted. This is a kludge in Ansible to enable one-off operations.

Some folks prefer doing both types of jobs with one tool, and working around the rough edges. Other folks prefer having two tools to do almost the same thing, but without rough edges. To answer the question, "appropriateness" is a matter of taste. This answer explains why.

> **Comments:**
> **username_1**: I agree on Capistrano being slightly awkward for this case. It is usually used as namespace for remotely executed ruby scripts/snippets/lambda over ssh. Your section on Ansible is not correct. You might want to research it a bit and fix it. Good first post, but please work on it a bit more.  
> **username_3**: @JiriKlouda whats wrong with the Ansible section? Do you mean the section `no easy way to check if the web server has been restarted` in that it could be checked by registering a variable?  
> **username_1**: There are multiple ways to do it, author of the answer just doesn't know them. Feel free to turn it into separate question as comments are not good place for technical answers.  

---

### Answer by username_1 on 2017-03-28. Score: 4

**TL;DR**: Just use Ansbile, it is **both** configuration and deployment tool :)

There are several types of deployment:

* **Application** based (files, archives packages)
* **Container** based (includes VMs, Habitat, LXC, Docker)
* **Function** based (Micro services / Lambdas / Functions)

I assume in this case we speak only about application updates on server(s).

---

For deployment you need to have two things happen:

1. Correct files or packages need to move to the server.
2. Configuration and service states need to change.

---

Now for (1) you can use multiple strategies:

* Artifact Repositories / Syncing
* Package Repositories / Package Managers
* Version Control System / Updating + Compiling (optionally)
* File transfer protocols (scp, rsync, ftp)
* Deployment Tools

For the (2) you can use:

* Configuration management tools
* Deployment Tools

So while the Deployment Tools are a way to do deployment all in one, they are not always the best strategy. Sometimes you want to use combination of these ways for deployment. You most likely already use package managers at least on your servers already. You most likely run configuration tools anyway. The problem with some of the configuration tools was a proper orchestration among multiple servers, but now even Chef and Puppet can do that quite well. Ansible has been always good at this.

From *personal experience*, I've used all combinations, but currently we use Capistrano for deployment and Ansible sync for configuration management, and VCS and package repositories for file transfers, but there are issues with Capistrano and we are planing to move away from it to unify on Ansible for both deployment, maintenance and configuration management.

> **Comments:**
> **username_2**: My experience with Ansible and Capistrano would lead me to the same conclusion. I'd just go with Ansible. And the nice thing about Ansible is that its "desired state" declarations map very nicely to underlying imperative commands.  
> **username_4**: People sometimes ignore the community contributions around Configuration Management tools. Ansible's community components are, with some noteable exceptions (like DebOps), are not yet as polished and feature-complete as Chef's and Puppet's. As a measurement of this, while I found Puppet and Chef are able to both "apply" and *unapply* configuration directives (do or undo a set of changes), Ansible is great at the "apply" part, but not so great at the "unapply" part.  

---

### Answer by username_5 on 2017-05-22. Score: 3

For software and deploying code to an existing server or inside a Docker container, the answer is relatively simple - No, you don't *need* both, but you might want both if another tool or utility adds value and is the [right tool for the job](https://devops.stackexchange.com/a/657/2845), however things get more complicated when you are deploying servers and operating systems.

One value-add of a DevOps mentality is treating infrastructure as code and frequently deploying or destroying virtual machines or even bare metal in a highly elasticized environment. Your configuration management system cannot easily netboot and kickstart your server for you and cannot manage repositories, packages and updates/patching for you during and after deployments or in some cases, licensing and entitlements.

For Amazon Web Services, this is rather conveniently manageable by APIs for the most part, but for those of us who have to manage our own data centers, this is not an option. For this reason [The Foreman](https://www.theforeman.org/) project (and [Red Hat which re-brands this](https://access.redhat.com/products/red-hat-satellite)) have found it necessary to bundle [Katello](http://www.katello.org/), [Candlepin](http://www.candlepinproject.org/) and a configuration manager such as Ansible, Foreman or Puppet together when deploying the [Katello Scenario](https://theforeman.org/plugins/katello/3.3/installation/index.html).

So while you might be able to get away with using configuration management tools for software code deployments on the Dev side of the house, over on the Ops side, there are several cases where the answer is a resounding "no, configuration management tools are *not* appropriate to use as deployment tools" Doing so would require a serious re-invention of the wheel and is impractical. You must instead use your configuration management tools to initiate deployments in another tool.

> **Comments:**
> **username_6**: Or not,  chef handle gracefully Capistrano like deploys,  chocolatey packages deploys under windows and all well know packages installs (deb, rpm,  msi,  nullsoft,  etc.). It does bring some burden on the packaging side,  which habitat aim to solve,  but that's a configuration management system fairly able to handle deploys,  I can tell it by seeing it doing roughly 40 deploys per week on multiples environments including production, that's not without a high burden beforehand to code it,  but that's not that much above the same thing with any other tool ateotd.  
> **username_5**: Actually The Foreman is neither a provisioning, deployment or configuration management system. It is just a skin which provides a web based UI and framework that glues together a configuration management system (puppet), license management system (candlepin), repository and patch management system (Katello), and a provisioning/deployment system (kickstart). It front-ends all of these different projects and glues them together. While pretty much any configuration management system can install a package, what they can't do is provide patch management in a manner similar to a WSUS server  
> **username_5**: or pin to or deploy specific versions of packages, include packages that are not in upstream repos or mashup repos. My point is that if Red Hat/The Foreman/Katello felt it couldn't be done with *just* a configuration management system - most notably because it lacked the provisioning/deployment piece that that is worth noting.  
> **username_6**: I misread the sentence about katello,  my bad. First comment was for the sake of completeness :)  

---

### Answer by username_7 on 2017-03-27. Score: 3

Application deployment is a hard thing to pin down because it has a lot of sub-problems. Config management systems are excellent at modeling tasks which are convergent and work with "what is the desired state of the system". In the context of app deployment, this is great for things like deploying bits to a machine, managing configuration files, and setting up system services. What it is extremely bad for is things that are inherently procedural, notably database migrations and service restarts. I usually try to put the convergent logic in Chef and let an external procedural tool (usually Fabric in my case) handle the few remaining bits as well as sequencing the actual converges.

So, basically, you should use both for the pieces they are best at.


---

