As Continuous Delivery and DevOps are making it more and more into the core of SAP, I thought it’s about time to ensure we’re all on the same page when it comes to terminology. Especially Continuous Delivery and DevOps are often used in the same context (which is OK) so that the uninitiated reader/listener could think they’re the same thing (which is not OK).
So, let’s try to define Continuous Integration (CI), Continuous Delivery (CD), Continuous Deployment and DevOps.
Continuous Integration (CI) is most likely the “oldest” and most common technique among the four methods described here. As the name says its goal is to integrate changes (which were done locally) into a common code base. The result is from all parties accepted as the only truth when it comes to compilation, test and any other errors.
I remember 2001 when I was starting at SAP, that I created a CI service called “Bob the Builder” which basically pulled and build every change from our VCS all day long. The heart of it was a bunch of chaotic shell and batch scripts, which ensured each push to the main development code line was instantly build and tested. If something caused an error the developer got an email with the order to fix the issue asap.
Even tough this was a very (long lasting) temporary solution, it served its purpose an increased overall stability.
Today many CI servers are out there that do the job way better, than my set of shell scripts…
As Paul Stack outlines “Continuous Delivery is not continuous deployment”, CD is about having shippable software after each check-in. When (how often) the actual shipment will be done is not defined in CD.
This causes many people to have troubles to say whether they (already) do CD, because there’s a gut feeling that CD requires you to ship “very frequently” (whatever this means). Is it every day, once a week, once a month? You won’t find and limit here, for good reasons:
Shipping software fast is not a goal on its own. It’s an ability that results from our very first statement on CD: “shippable software after each check-in”.
It simply depends on your application, your environment, your customers, your business, … to decide how “fast” you should deliver.
So the core of CD is getting feedback fast along your complete development and operations process (the so called deployment pipeline). When you get your feedback fast (from CI Servers, Tests, Metrics, Monitors, …) you can ensure to have “shippable software after each check-in”.
So when CD is about “shippable software after each check-in” but not necessary require you to ship after each check-in, Continuous Deployment (yes I’m running out of acronyms here) expands CD by exactly that. Each check-in to the VCS is released (after being qualified) as soon as possible. John Allspaw wrote a lot on this how it’s done at Etsy and Flickr.
With Continuous Integration, Continuous Delivery and Continuous Deployment you can see a clear line and common goal among them. Continuous Deployment extends Continuous Delivery which relies on Continuous Integration.
Now with DevOps it’s a bit different. On all the previous topics you can find gazillions of books, blogs, etc. that exactly describe what and how to do. DevOps doesn’t have that clear definition. Many people try to nail it down a little more (see e.g. Mike Loukides
here or Baron Schwartz on “
The DevOps indentity crisis”) but the origin and initial purpose basically reject such a clear definition.
First the definition seems to be quiet clear. DevOps is development + operations. Easy.
But does it end there? What about QA, Product Management, …. do we need a DevOpsQAProd movement now? No, we don’t. There are two widely accepted definitions on what DevOps is (or better: should do)
One comes from Gene Kim in his book “The Phoenix Project”. According to this DevOps has three pillars:
- Visualize the end-to-end process
- Improve feedback loop
- Continuous improvement
Let’s look into this. Visualize the end-to-end process basically says, write down your complete product definition, development, quality, operations, “what have you” processes. So this already includes not only Development and Operations, but also QA, product management, … so no need to invent a new movement. (BTW: Kanban does good in doing the visualization to our experiences at twogo.com)
Once you understood the complete process, try to improve the feedback loops. So tear down any boundaries between your organizations (which are involved in the process). This is the core. DevOps is a cultural change. Don’t put Devops (only) into your org chart. There is no DevOps person nor department. Also tools can only help you with DevOps, they cannot do the cultural change for you.
Once you archived that (and this is way harder than any technical implementation you’ve done) continuously improve your working methods. There is no defined goal in DevOps, which again makes it hard (but not impossible) to say: “Yeah you’re doing DevOps”.
The second description or definition on DevOps that is often found is: CAMS – Culture, Automation, Monitoring, Sharing. Patrick Debois, godfather of DevOps often refers to this description (which is not in contrast to the first one I gave above…). Culture we already spoke about in the first definition. Automation and Monitoring along your process, will enrich your process with more democracy. When things need to be done manually, you rely on certain persons/roles to execute a specific job. When you automate things, things are not only becoming more reliable, reproducible, cheaper, faster, … but also more democratic as many people can now do (start) certain (new) jobs . The same with monitoring. Even though the term is technical it basically says, be open on your process. Visualize your process and make it available to everybody. Everyone should see what you’re doing (process wise). Don’t hide information. Don't be afraid that others see your mistakes. Mistakes are fine, as long as you learn from them. This is again true when looking at the last point: Sharing. Share your knowledge and give insights of your work to others (people, departments, …).
