<p>DevOps includes automation but that's only part of it.  DevOps is a cultural change to break down the silos between the different parts of the organization to provide a complete value stream.  Providing a culture where business, development, quality assurance, infrastructure, security, ops, etc all work together to provide value to who ever is the end user.  DevOps is not a tool, you can't buy it, you have to change your culture.  </p>

<p>Automation is a key part of DevOps in that it allows the speed of delivery with quality.  Automation for the deployment process is one of the areas many people focus on first as it is one of the best ways to gain value quickly and provides a high return on investment through not only reducing the time for the deployment but also standardizing the process and removing errors.  </p>

CC BY-SA 4.0
2018-07-17T18:38:46.683Z
2018-07-17T18:38:46.683Z
Rosalind Radcliffe
<p>DevOps movement consists of four major areas abbreviated as <a href="http://devopsdictionary.com/wiki/CAMS" rel="nofollow noreferrer">CAMS</a>:</p>

<ol>
<li>Culture</li>
<li>Automation</li>
<li>Measurement</li>
<li>Sharing</li>
</ol>

<p>Here is the <a href="https://blog.chef.io/2010/07/16/what-devops-means-to-me/" rel="nofollow noreferrer">original defining post</a> from 2010.</p>

<p>In each area there are some tools, processes and practices that are generally accepted, although the subject is not well defined for Best Practices, there are in most cases some Good Practices to follow.</p>

<p>Automation by itself is a bit wider subject, but in context of DevOps it is just a subset of what is being covered. Take a note that we lead with culture, although many DevOps practitioners new to the field often overlook it at their own peril and skip directly to automation.</p>

CC BY-SA 4.0
2018-09-24T13:22:56.563Z
2018-09-24T13:22:56.563Z
Jiri Klouda
<p>Automation is a key attribute of DevOps, but it's not the full story.  The question is kind-of like "What's the difference between time-boxing and Scrum?".</p>

<p>You'll hear DevOps called a 'culture', a 'movement', a 'methodology', and all kinds of things that won't box it in well enough for you to understand it, even though those descriptions are accurate.  In a nutshell, DevOps is about the confluence of Agile methodologies, automation, and virtualization that enables a new feedback loop in the management/control/steering of a software project.</p>

<p>With aggressive automation, things that use to take a long time and be subject to human error now happen quickly and without incident.  As a result, we tend to do them more often.  A primary example of this is a 'deploy into production'.  We used to save large batches of work and deploy them off-hours just in case 'something went wrong'.  But now we can deploy changes several times a day, in a way that the chances of 'something going wrong' is dramatically reduced, and in a way that the impact of something going wrong is much smaller when it does occur.</p>

<p>Once we have this repeatable process in place, we begin to see it as a 'pipeline'.  Requirements go in, code deployed into production comes out.  We automate everything along this pipeline - tests, documentation, merges, deploys, and more tests, and so on...  Because people focus on the automation, they don't see the 'pipeline mentality' that drove it.  <strong>This</strong> is the management methodology - the attention paid on the pipeline - that makes DevOps more than Automation.</p>

<p>Once we have that automation in place, the feedback loops kick in.  We start to measure things like <strong>cycle time</strong> so we can figure out things we had previous tried to guess with estimates.  Things about the architecture that make automation/continuous delivery hard tend to be replaced with alternative architectural patterns that make automation/continuous delivery easier (several great examples of this are documented in the book 'Evolutionary Databases'.  'Green/Blue Deployments' are another).  </p>

<p>Notice I was able to provide this description without talking about Jenkins, Check, Puppet, Ansible, Vagrant, AWS, or any of the other tooling that supports it.  This is what we mean by the larger level buzzwords like 'methodology'.  In the end, any set of tools can be replaced... What we're left with is the core management principles enabled by automation and the focus on the pipeline.</p>

CC BY-SA 3.0
2017-03-02T19:09:32.693Z
I am sorry, but this sounds like an Agile manifesto more than a devops culture information to my feelings. Agile/iterative/short cycle methodology even if often used are not mandatory for a devops organization. You can have devops teams on a waterfall project and  you can automate silo based delivery, as such I feel this answers address partially the question.
Tensibai
CC BY-SA 3.0
2017-03-02T21:16:02.743Z
@Tensibai I have to disagree somewhat- you don't automate a process that doesn't execute frequently.  DevOps without Agile is like automating the building of a multi-million dollar supercar.
Dave Swersky
CC BY-SA 3.0
2017-03-02T21:54:55.933Z
This answer is incredibly verbose and it is hard to distill the differences, or pros/cons that relate to the OP Q.
Evgeny Zislis
CC BY-SA 3.0
2017-03-02T22:17:28.253Z
@Dave you're missing the point, I must have been unclear, what I mean is that a devops culture is about breaking silo teams, automation or short cycle are unrelated even if usual , I didn't saw this important point in your answer
Tensibai
CC BY-SA 3.0
2017-03-02T18:10:37.237Z
2017-03-02T18:34:28.313Z
2017-03-02T18:34:28.313Z
David Bock
<p>DevOps is really a cultural shift - it's intended to be about breaking down the traditional barriers between operations and development (and really also with QA and the rest of the business!). The idea is that rather than having departmental 'silos' you can work directly with other teams to get things done quicker and more efficiently.</p>

<p>It's all about removing constraints and streamlining processes. Automation comes into this heavily because having repeatable processes helps remove constraints. For example: if someone from ops has to do a manual release process to get code out to an environment, there's a couple of things that can get in the way - one is that there has to be someone in ops free to do the deploy, and two, there is less confidence in the release process because manual work is error-prone. </p>

CC BY-SA 3.0
2017-03-04T03:59:45.923Z
2017-03-04T03:59:45.923Z
tayworm
<p><b>I would like to add my 2 cents:</b><br>
<b>1) <em>Automation</em>:</b> <br/>
&nbsp;&nbsp;&nbsp;&nbsp; Something that we are nowadays having to move towards. It has become more of a necessity wherein the preferred way would be to automate pieces, if not the entire process. This approach gives the users (developers) flexibility to use a fixed step along with being able to customize as needed.<br/>
&nbsp;&nbsp;&nbsp;&nbsp; The advantage in this approach is that we can automate the parts that we want to while the individual process can be tied together by the developer. The more granularized the automation steps, the better control they have.<br/>
&nbsp;&nbsp;&nbsp;&nbsp; Also, there are many tools for automation in spaces like robotic automation, SOP automation (for servicing industry), report automation (like Splunk), etc.<br/>
<b>2) <em>DevOps</em>:</b> <br/>
&nbsp;&nbsp;&nbsp;&nbsp; Given the state of delivery quality and timeliness that is being expected out of the current world, there is a necessity to extend automation of the software delivery process. To enable this and provide value to the customer in the fastest way possible, DevOps does extensively rely on automation tools.<br/>
&nbsp;&nbsp;&nbsp;&nbsp; The advantage in this approach is that, the individual steps can be automated to bring about consistency across enterprise while the overall orchestration can be modified to suit the process needed by that project.<br/>
&nbsp;&nbsp;&nbsp;&nbsp; The individual automation tools (in a way) like Chef for deployment, Docker via Dockerfile, Maven for build, etc. can be tied together probably via Jenkins to provide the required solution while at the same time bringing down the time needed for implementation or usage.<br/>
Hope this helps to add any value to the thought process that you may already have.<br>
<br/>
<strong>Edit:</strong> Forgot to add that I had talked about the Process and Tools - 2 of the 3 aspects in DevOps. As mentioned by the others, the 3rd and equally important aspect is People. One of the major differences I would assume between this and automation would be that people are more prone to absorb automation more frequently than they would resist DevOps. I feel that this is due to the nature of DevOps itself, in that automation is usually associated with making things easier for them, while they feel that DevOps is changing the way that they are comfortable with.</p>

CC BY-SA 4.0
2018-07-18T06:45:27.870Z
2018-07-18T06:53:28.320Z
2018-07-18T06:53:28.320Z
Karthik Venkatesan
<p>Automation and DevOps are unrelated.  DevOps is more like combined engineering where the Developers of a site or service are all the Operators of that site or service.  Why is this novel?  In my experience the first thing the Ops team did when anything more exciting than a network blip happened was to call the Dev team.  Why did they do that?  Because all the Ops team did was monitor and keep a list of dev phone numbers to call.</p>

<p>Notice I've said nothing about automation.</p>

<p>Automation is about repeating success.  If I do steps a,b and c and process X always works, then steps a, b and c are good candidates for automation.  Then I can use the time for what used to be a manual process to do things that make me more money.  Automation is successful when it's simple.  Deploying new releases, running integration tests, torquing a nut on a bolt, backing up data, balancing credits vs. debits, etc. are all great candidates for automation because the steps are repeated whether by a person or a robot.</p>

<p><strong>Note</strong>: What is new is that Developers are also the operators. There is not another group. Cooperation in my case was rare. If there was nothing in the Troubleshooting Guide (aka TSG) then you were guaranteed a phone call. In my experience Ops was the first call in case of backhoe. Problems between services were out of their wheelhouse.</p>

CC BY-SA 3.0
2017-03-07T06:11:45.457Z
But onething, the cooperation was always there right? Communication between dev and ops, is it something new? what's devops bringing new?
pinkpanther
CC BY-SA 3.0
2017-03-07T12:43:07.747Z
What is new is that Developers are also the operators.  There is not another group.  Cooperation in my case was rare.  If there was nothing in the Troubleshooting Guide (aka TSG) then you were guaranteed a phone call.  In my experience Ops was the first call in case of backhoe.  Problems between services were out of their wheelhouse.
No Refunds No Returns
CC BY-SA 3.0
2017-03-08T16:49:19.660Z
Automation and DevOps are "unrelated"?  Respectfully, I couldn't disagree more.  Continuous Integration, Continuous Deployment, Automated Testing, and more are integral to the technology component of DevOps.  Without automation, DevOps is *only* culture.  Culture is important, to be sure, but it's only one leg of the three-leg DevOps stool (Culture, Process, Technology)
Dave Swersky
CC BY-SA 3.0
2017-03-08T18:33:09.927Z
@NoRefundsNoReturns Devs are operaters. In the sense that there is no need for a devop team?
pinkpanther
CC BY-SA 3.0
2017-03-27T20:17:12.203Z
Feel free to disagree.  We had tons of automation when we both a "developer" team and and "operations" teams.  That's why I say they are unrelated.  Automation could care less about your org structure.  If your developers are also the operators it is highly likely automation will occur because most developers are lazy and will tend to automate repetitive tasks.  I'm confused by your response @pinkpanther
No Refunds No Returns
CC BY-SA 3.0
2017-04-19T15:08:06.330Z
another anonymous downvote.  Please feel free to disagree but have the balls to step up and say why if you do.  Haters are just gonna hate.
No Refunds No Returns
CC BY-SA 4.0
2018-12-11T13:36:23.137Z
the upvotes and answers here indicate that folks think that automation is a key part of the picture. you focus on support. I think that merging design-build-support into one team to optimise the value chain is what devops is about. removing silos is part of that but also getting it right first time and cycling faster is important. merging dev and ops teams isn't doing devops its just breaking down one particular silo. devops is about optimising the whole end to end delivery which is automation, culture and tooling.
simbo1905
CC BY-SA 4.0
2018-12-11T21:02:01.713Z
I stand by my position that these subjects are unrelated based on my original answer.  Please feel free to continue the downvotes.  If you really want to get in the game though, offer an `answer` and open `your reputation` up to public scrutiny.

As I said originally, we had automation long before we had Dev / Ops.
No Refunds No Returns
CC BY-SA 3.0
2017-03-07T04:46:08.600Z
2017-03-08T06:47:35.013Z
2017-03-08T06:47:35.013Z
No Refunds No Returns
<p>A big part of DevOps is making it possible to release very often. That comes with automated build, automated testing, etc. You can say that to achieve its goals, DevOps need to use automation to be efficient.</p>

<p>Here's how DevOps and automation are related. DevOps is not just automation, there's more to it. Conversely, automation is not exclusively used by "DevOps people". A lot of automation was taking place in IT before DevOps came around.</p>

<p><a href="https://i.sstatic.net/m0tMY.jpg" rel="noreferrer"><img src="https://i.sstatic.net/m0tMY.jpg" alt="DevOps in relation to automation"></a></p>

<p>Please don't consider to above diagram to represent all that is DevOps, or all this is automation. It is to help the reader picture how the two concepts are related.</p>

CC BY-SA 3.0
2018-02-05T01:50:42.680Z
Why isn't "tickets workflow" in DevOps?
Nakilon
CC BY-SA 3.0
2017-03-02T20:01:47.937Z
Exactly what I had said on the subject :)
Tensibai
CC BY-SA 3.0
2017-03-02T19:08:22.987Z
2017-03-02T19:08:22.987Z
Alexandre
<p>I see that whenever someone does DevOps, it's mostly about automating things like deployment etc.</p>

<p>But where does automation end and DevOps begin?</p>

CC BY-SA 3.0
2017-04-01T22:18:28.427Z
Hi @punkpanther if this or any answer has solved your question please consider [accepting it](https://meta.stackexchange.com/q/5234/179419) by clicking the check-mark. This indicates to the wider community that you've found a solution and gives some reputation to both the answerer and yourself. There is no obligation to do this.  If you don't feel that your question has been answered please do feel free to engage with the authors in the comments.
Richard Slater
<continuous-integration><terminology><automation><culture>
What's the difference between DevOps and Automation?
pinkpanther
# What's the difference between DevOps and Automation?

(Asked by: username_0 on 2017-02-28)

I see that whenever someone does DevOps, it's mostly about automating things like deployment etc.

But where does automation end and DevOps begin?

**Tags:** continuous-integration, terminology, automation, culture

> **Comments:**
> **username_1**: Hi @punkpanther if this or any answer has solved your question please consider [accepting it](https://meta.stackexchange.com/q/5234/179419) by clicking the check-mark. This indicates to the wider community that you've found a solution and gives some reputation to both the answerer and yourself. There is no obligation to do this.  If you don't feel that your question has been answered please do feel free to engage with the authors in the comments.  

---

## 7 answers

### Answer by username_12 on 2017-03-02. Score: 47 | Accepted answer

A big part of DevOps is making it possible to release very often. That comes with automated build, automated testing, etc. You can say that to achieve its goals, DevOps need to use automation to be efficient.

Here's how DevOps and automation are related. DevOps is not just automation, there's more to it. Conversely, automation is not exclusively used by "DevOps people". A lot of automation was taking place in IT before DevOps came around.

[![DevOps in relation to automation](https://i.sstatic.net/m0tMY.jpg)](https://i.sstatic.net/m0tMY.jpg)

Please don't consider to above diagram to represent all that is DevOps, or all this is automation. It is to help the reader picture how the two concepts are related.

> **Comments:**
> **username_5**: Exactly what I had said on the subject :)  
> **username_13**: Why isn't "tickets workflow" in DevOps?  

---

### Answer by username_4 on 2017-03-02. Score: 15

Automation is a key attribute of DevOps, but it's not the full story. The question is kind-of like "What's the difference between time-boxing and Scrum?".

You'll hear DevOps called a 'culture', a 'movement', a 'methodology', and all kinds of things that won't box it in well enough for you to understand it, even though those descriptions are accurate. In a nutshell, DevOps is about the confluence of Agile methodologies, automation, and virtualization that enables a new feedback loop in the management/control/steering of a software project.

With aggressive automation, things that use to take a long time and be subject to human error now happen quickly and without incident. As a result, we tend to do them more often. A primary example of this is a 'deploy into production'. We used to save large batches of work and deploy them off-hours just in case 'something went wrong'. But now we can deploy changes several times a day, in a way that the chances of 'something going wrong' is dramatically reduced, and in a way that the impact of something going wrong is much smaller when it does occur.

Once we have this repeatable process in place, we begin to see it as a 'pipeline'. Requirements go in, code deployed into production comes out. We automate everything along this pipeline - tests, documentation, merges, deploys, and more tests, and so on... Because people focus on the automation, they don't see the 'pipeline mentality' that drove it. **This** is the management methodology - the attention paid on the pipeline - that makes DevOps more than Automation.

Once we have that automation in place, the feedback loops kick in. We start to measure things like **cycle time** so we can figure out things we had previous tried to guess with estimates. Things about the architecture that make automation/continuous delivery hard tend to be replaced with alternative architectural patterns that make automation/continuous delivery easier (several great examples of this are documented in the book 'Evolutionary Databases'. 'Green/Blue Deployments' are another).

Notice I was able to provide this description without talking about Jenkins, Check, Puppet, Ansible, Vagrant, AWS, or any of the other tooling that supports it. This is what we mean by the larger level buzzwords like 'methodology'. In the end, any set of tools can be replaced... What we're left with is the core management principles enabled by automation and the focus on the pipeline.

> **Comments:**
> **username_5**: I am sorry, but this sounds like an Agile manifesto more than a devops culture information to my feelings. Agile/iterative/short cycle methodology even if often used are not mandatory for a devops organization. You can have devops teams on a waterfall project and  you can automate silo based delivery, as such I feel this answers address partially the question.  
> **username_6**: @username_5 I have to disagree somewhat- you don't automate a process that doesn't execute frequently.  DevOps without Agile is like automating the building of a multi-million dollar supercar.  
> **username_7**: This answer is incredibly verbose and it is hard to distill the differences, or pros/cons that relate to the OP Q.  
> **username_5**: @Dave you're missing the point, I must have been unclear, what I mean is that a devops culture is about breaking silo teams, automation or short cycle are unrelated even if usual , I didn't saw this important point in your answer  

---

### Answer by username_8 on 2017-03-04. Score: 14

DevOps is really a cultural shift - it's intended to be about breaking down the traditional barriers between operations and development (and really also with QA and the rest of the business!). The idea is that rather than having departmental 'silos' you can work directly with other teams to get things done quicker and more efficiently.

It's all about removing constraints and streamlining processes. Automation comes into this heavily because having repeatable processes helps remove constraints. For example: if someone from ops has to do a manual release process to get code out to an environment, there's a couple of things that can get in the way - one is that there has to be someone in ops free to do the deploy, and two, there is less confidence in the release process because manual work is error-prone.


---

### Answer by username_2 on 2018-07-17. Score: 5

DevOps includes automation but that's only part of it. DevOps is a cultural change to break down the silos between the different parts of the organization to provide a complete value stream. Providing a culture where business, development, quality assurance, infrastructure, security, ops, etc all work together to provide value to who ever is the end user. DevOps is not a tool, you can't buy it, you have to change your culture.

Automation is a key part of DevOps in that it allows the speed of delivery with quality. Automation for the deployment process is one of the areas many people focus on first as it is one of the best ways to gain value quickly and provides a high return on investment through not only reducing the time for the deployment but also standardizing the process and removing errors.


---

### Answer by username_3 on 2018-09-24. Score: 2

DevOps movement consists of four major areas abbreviated as [CAMS](http://devopsdictionary.com/wiki/CAMS):

1. Culture
2. Automation
3. Measurement
4. Sharing

Here is the [original defining post](https://blog.chef.io/2010/07/16/what-devops-means-to-me/) from 2010.

In each area there are some tools, processes and practices that are generally accepted, although the subject is not well defined for Best Practices, there are in most cases some Good Practices to follow.

Automation by itself is a bit wider subject, but in context of DevOps it is just a subset of what is being covered. Take a note that we lead with culture, although many DevOps practitioners new to the field often overlook it at their own peril and skip directly to automation.


---

### Answer by username_9 on 2018-07-18. Score: 1

**I would like to add my 2 cents:**  
**1) *Automation*:**


---

### Answer by username_10 on 2017-03-07. Score: -2

Automation and DevOps are unrelated. DevOps is more like combined engineering where the Developers of a site or service are all the Operators of that site or service. Why is this novel? In my experience the first thing the Ops team did when anything more exciting than a network blip happened was to call the Dev team. Why did they do that? Because all the Ops team did was monitor and keep a list of dev phone numbers to call.

Notice I've said nothing about automation.

Automation is about repeating success. If I do steps a,b and c and process X always works, then steps a, b and c are good candidates for automation. Then I can use the time for what used to be a manual process to do things that make me more money. Automation is successful when it's simple. Deploying new releases, running integration tests, torquing a nut on a bolt, backing up data, balancing credits vs. debits, etc. are all great candidates for automation because the steps are repeated whether by a person or a robot.

**Note**: What is new is that Developers are also the operators. There is not another group. Cooperation in my case was rare. If there was nothing in the Troubleshooting Guide (aka TSG) then you were guaranteed a phone call. In my experience Ops was the first call in case of backhoe. Problems between services were out of their wheelhouse.

> **Comments:**
> **username_0**: But onething, the cooperation was always there right? Communication between dev and ops, is it something new? what's devops bringing new?  
> **username_10**: What is new is that Developers are also the operators.  There is not another group.  Cooperation in my case was rare.  If there was nothing in the Troubleshooting Guide (aka TSG) then you were guaranteed a phone call.  In my experience Ops was the first call in case of backhoe.  Problems between services were out of their wheelhouse.  
> **username_6**: Automation and DevOps are "unrelated"?  Respectfully, I couldn't disagree more.  Continuous Integration, Continuous Deployment, Automated Testing, and more are integral to the technology component of DevOps.  Without automation, DevOps is *only* culture.  Culture is important, to be sure, but it's only one leg of the three-leg DevOps stool (Culture, Process, Technology)  
> **username_0**: @NoRefundsNoReturns Devs are operaters. In the sense that there is no need for a devop team?  
> **username_10**: Feel free to disagree.  We had tons of automation when we both a "developer" team and and "operations" teams.  That's why I say they are unrelated.  Automation could care less about your org structure.  If your developers are also the operators it is highly likely automation will occur because most developers are lazy and will tend to automate repetitive tasks.  I'm confused by your response @username_0  
> **username_10**: another anonymous downvote.  Please feel free to disagree but have the balls to step up and say why if you do.  Haters are just gonna hate.  
> **username_11**: the upvotes and answers here indicate that folks think that automation is a key part of the picture. you focus on support. I think that merging design-build-support into one team to optimise the value chain is what devops is about. removing silos is part of that but also getting it right first time and cycling faster is important. merging dev and ops teams isn't doing devops its just breaking down one particular silo. devops is about optimising the whole end to end delivery which is automation, culture and tooling.  
> **username_10**: I stand by my position that these subjects are unrelated based on my original answer.  Please feel free to continue the downvotes.  If you really want to get in the game though, offer an `answer` and open `your reputation` up to public scrutiny.  As I said originally, we had automation long before we had Dev / Ops.  

---

