Especially in larger organizations and enterprises there used to be (and sometimes still is) a distinction between development and operations. This distinction is very easy; DEVelopment is responsible for making (new) software. When it is ready (build and tested), it is handed over to OPerationS who are responsible for running and monitoring this software in a production environment. They are separate worlds with little interaction; after the formal handover, the only contact they have is when a failure occurs which development has to fix. This situation works well in large enterprises where business hours, batch windows and release calendars facilitate (or even make it necessary to have) such a division. When software, technology, and the business itself changed, this division became impractical, especially when Agile, with its emphasis on frequent releases, was introduced. Enter DevOps.
Instead of having two separate teams, one for making the software and another for running it, DevOps combines them a single team which is responsible for both making and running it. Which makes a lot of sense; as now this new team has all the knowledge and privileges to take full responsibility for their application(s).
Most of the tasks of operations are also done by development in test environments, so for developers, switching to DevOps is a minor change. And a welcome one as it used to be a hassle for developers to get any information on how their software was behaving in production, the only exception being when operations ran into a failure.
DevOps as a job requirement
DevOps indicates a way of working and is not a skill in itself. If a candidate has DevOps experience, it is an advantage but not having it is not a disqualifier. As we have seen it is a combination of two different areas, and any experienced developer will have no problem at all working in a DevOps environment. Having just an operations (and no developer) background, on the other hand, is not enough as development is by far the biggest part of DevOps and requires very specific skills.
Continuous Integration (CI)
In many cases, multiple developers work on the same software either by adding new code or changing existing code. At some point (after days or weeks), all of this the code needs to be combined and tested. If it contains errors or conflicts, it fails. If it contains many, it fails miserably and it can take a lot of effort to find and solve them (a situation aptly called “integration hell”).
There are various ways of preventing this and CI is one of them. By committing (= combining) and testing code from different developers as soon as possible (daily or even multiple times a day) errors and conflicts are detected at an early stage when they are easy to solve.
Without getting too technical, CI has both advantages and downsides and is not suitable for every situation.
CI as a job requirement
CI is an (automated) process and not a skill in itself (it even requires less skill from developers instead of more). The tools used in CI vary between organizations as does the specific implementation. Any experienced developer without CI experience will have done all the steps manually and will have no difficulty using CI. Keep in mind this is not rocket science but something that any developer should be able to pick up very quickly (a day or so).
Continuous Delivery/Deployment (CD)
The next step in making the process of software development more efficient and manageable is Continuous Delivery/Deployment (CD). There is a slight difference between the two (the abbreviation adds to the confusion); they are the same but the final step in the process is manual for Delivery and automated for Deployment.
Instead of manually implement changes in production software, CD automates the process as much as possible. CD has the intention of both speeding up the delivery and preventing human errors.
In practice, only a (very small) subset of all software is suitable for this kind of delivery and in many cases some human involvement is still necessary (at best Continuous Delivery). You have to be pretty sure your automated tests cover everything to allow a fully automated process (= Continuous Deployment).
CD as a job requirement
CD is also not a skill but a process. Even more than CI, it will have a very specific implementation for each organization (depending on the technology and tools they use).
Any experienced developer should have no problem with using CP; again it is something that makes them do less then they were used to do.
Putting it all together
DevOps, CI, and CD are processes and not skills. For any good developer switching to them is comparable to switching from a car with manual transmission to an automatic; it may take some getting used to (as you are required to do less instead of more) but you can’t do anything wrong.
Take note: for developers who only have experience with CI and CD any environment in which they are missing will be difficult. CI and CD not only relieve you from the manual work but also from awareness of the principles and thinking behind this work (just code and CI and CD will do the rest). If you only learned to drive an automatic, switching to a manual transmission car will be extremely difficult at first.