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

But where does automation end and DevOps begin?

  • Hi @punkpanther if this or any answer has solved your question please consider accepting it 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 Apr 1 '17 at 22:18
  • Maybe the better question would be where does DevOps end and automation begin? Not everything done with DevOps is about automation; a large part of it, yes, but not all... One could say DevOps is everything but automation - it's the sysadmin cultrue, the common architecture standards, the common publishing standards (say GitHub) of a particular technological field... Where does the automation in that particular field starts is a good question by itself, I think... – JohnDoea Dec 10 '18 at 20:43

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

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.

  • 1
    Exactly what I had said on the subject :) – Tensibai Mar 2 '17 at 20:01
  • Why isn't "tickets workflow" in DevOps? – Nakilon Feb 5 '18 at 1:50

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.

  • 1
    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 Mar 2 '17 at 19:09
  • 2
    @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 Mar 2 '17 at 21:16
  • This answer is incredibly verbose and it is hard to distill the differences, or pros/cons that relate to the OP Q. – Evgeny Mar 2 '17 at 21:54
  • @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 Mar 2 '17 at 22:17

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.


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.


I would like to add my 2 cents:
1) Automation:
     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.
     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.
     Also, there are many tools for automation in spaces like robotic automation, SOP automation (for servicing industry), report automation (like Splunk), etc.
2) DevOps:
     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.
     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.
     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.
Hope this helps to add any value to the thought process that you may already have.

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


DevOps movement consists of four major areas abbreviated as CAMS:

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

Here is the original defining post 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.


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.

  • But onething, the cooperation was always there right? Communication between dev and ops, is it something new? what's devops bringing new? – pinkpanther Mar 7 '17 at 6:11
  • 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 Mar 7 '17 at 12:43
  • 3
    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 Mar 8 '17 at 16:49
  • @NoRefundsNoReturns Devs are operaters. In the sense that there is no need for a devop team? – pinkpanther Mar 8 '17 at 18:33
  • 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 Mar 27 '17 at 20:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.