Okay so training was more work than expected, hence I will now slowly make my way through the backlog of topics. We will start with some the different techniques being used in DevOps. I will move the definitions to my definitions page as well, as I will refer to them again and again over time I am sure.
Continuous Integration (the practice)
This is probably the most widely known in this list of practices. It is about compiling/building/packaging your software on a continuous basis. With every check-in a system triggers the compilation process, runs the unit test, runs any static analysis tools you use and any other quality related checks that you can automate. I would also add the automated deployment into one environment so that you know that the system can be deployed. It usually means that you have all code merged into the mainline or trunk before triggering this process off. Working from the mainline can be challenging and often concepts like feature toggles are being used to enable the differentiation between features that are ready for consumption and features that are still in progress. This leads to variants where you run continuous integration on specific code branches only, which is not ideal, but better than not having continuous integration at all.
Continuous Integration (the principle)
I like to talk about Continuous Integration in a broader sense that aims at integrating the whole system/solution as often and as early as possible. To me Continuous Integration means that I want to integrate my whole system, while I could have a Continuous Integration server running on individual modules of the system. This also means I want to run integration tests early on and deploy my system into an environment. It also means “integrating” test data early with system to test as close as possible to the final integration. Really to me it means test as far left as possible and don’t leave integration until Integration Test at the end of the delivery life-cycle.
Continuous Delivery vs. Continuous Deployment
What could be more confusing than having do different practices that are called CD: Continuous Delivery and Continuous Deployment? What is the difference between CD and CD. Have a look at the summary picture:
As you can see the main practices are the same and the difference is mainly in where to apply them. In Continuous Delivery you aim to have the full SDLC automated up until the last environment before production, so that you are ready at any time to deploy automatically to production. In Continuous Deployment you go one step further, you actually automatically deploy to production. The difference is really just whether or not there is an automatic or manual trigger. Of course this kind of practice requires really good tooling across the whole delivery supply chain: everything that was already mentioned under continuous integration, but you will have to have more sophisticated test tooling that allows you to test all the different aspects of the system (performance, operational readiness, etc.). And to be honest I think there will often be cases where you require some human inspection for usability or other non-automatable aspects, but the goal is to minimise this as much as possible.
Continuous Testing
Last but not least Continuous Testing. To me this means that during the delivery of a system you keep running test batteries. You don’t wait until later phases of delivery to execute testing but rather you keep running tests on the latest software build and hence you have real-time status of the quality of your software and if you use Test-Driven-Development you have real-time status of progress. This is not terribly different to the others mentioned before but I like the term because it reflects the diffusion of testing from a distinct phase to an ongoing, continuous activity.
I hope this post was helpful for those of you who were a bit confused with the terms. Reach out with your thoughts.
Not A Factory Anymore 
The way I understand that Continuous Deployment is not necessarily to production, you can continuously deploy to staging environment while Continous Delivery is continuously delivering to customers [in automated manner] which means it goes straight until production.
LikeLike
Hi Thanks for sharing this impressive list. It’s really helpful for link building. It will really help me lot.
LikeLike
Reblogged this on Blog Data Center Indonesia.
LikeLike
Thanks again for the post Mirco. I agree with the definition of Continuous Integration that includes the deployment into a single environment as well. Most other definitions only take it up till ‘verification by an automated build allowing teams to detect problems early’), but I think deploying it is required after all to prove that the build itself was indeed successful. I’m interested to know though whether that then also includes ensuring ‘no problems from a deployment process’ and ‘free of environment issues’ perspective’? Or is that part of continuous delivery?
In the scheme of things probably doesn’t really matter, as all issues should be detected anyways, but just wanting to get my terminology right…
LikeLike
Interesting but I found this very lacking in terms of considering the surrounding environments and especialyl security requirements. The problem with the approach is that nowhere does it imply continuous security testing. If security is bundled as part of the traditional testing, it solution will very likely run into security issues. Now, if security is onyl part of the pre-release audit, the same issue remains.
Thus, one working example would be to have an aligned and automated track for security testing that is not too seprate from the business process testing and cycle but another part that supports the Continuous approach. Claims of developers being able to ctach security bugs, these showing up through traditional testing are widely used and alck any credibility when looking at the costs of security findings. Thus, SecDevOps automation is more and more prominent to any type of development cycle.
LikeLike
Hey Lexy, i agree with you. I didnt want to make it too complicated, there is UX, security, third-party testing which you want to build into your pipeline as well. The post is just about the different terms. Perhaps i should write about good pipeline design one of these days.
LikeLiked by 1 person
I totally get the difference between CD/CDep – the lines between CI and CD are not so clear. Can we say: “Continuous Integration is the practice that allows for the principle of Continuous Delivery of value into users’ hands”?
LikeLike
I think the best way to think about it, is the CI is the practice that validates that what you build works, while CD validates that it works as expected (e.g. from a funcational perspective) and CDep makes sure it can be used by users as quickly as possible
LikeLike