Continuous integration, delivery, deployment, and testing explained

Chat is continuous integration (CI), continuous delivery (CD), continuous deployment (CDP), and continuous testing (CT)? How do they differ from each other? Which one should we use?

#ci #cd #continuousintegration #continuousdelivery #continuousdeployment #continuoustesting

▬▬▬▬▬▬ Timecodes ⏱ ▬▬▬▬▬▬
00:00 Intro
00:35 Why continuous integration?
01:25 What is continuous integration?
05:49 How to implement continuous integration?
10:25 Why continuous delivery?
11:03 What is continuous delivery?
15:52 What is continuous deployment?
17:21 What is continuous testing?
19:52 Summary and final thoughts

▬▬▬▬▬▬ 🚀 Courses, books, and podcasts 🚀 ▬▬▬▬▬▬

▬▬▬▬▬▬ 👋 Contact me 👋 ▬▬▬▬▬▬

[DevOpsToolkit]

What are you practicing? Is it Continuous or Delayed Integration/Delivery?

[ChandanKumar-oufr]

You are an awesome teacher. The real life co-relations are really funny. Loved your content 😍

[IamDevNull]

I love how you explain complex topics in a comptent and funny way. Keep up the good work!

[PrinceRambade_Official]

I must say, I am really really impressed with the solid and very useful content of the video !!

[ronaldogeldres]

Now I know we're using delayed integration instead of continuous integration 😅 thanks for the explanation! loved the video

[ivansnegon]

That Subscribe message at the end of the video really got me :D It's really the good one. Subscribing immediately. Thank you for the great videos :)

[davidam]

this is the best and easy explanation I've found, thank you!

[ensmarqu]

A very good explanation about this always confused topic, thank so much!

[krzesimir]

Explanations like "yes, this is good practice but it does not apply to my project because we have ..." are my favorite :) 10 years ago I heard it when people were saying that we cannot write unit tests because we are writing UI, now I hear that we cannot do continuous delivery because our domain is too complex

[blighthornsteelmace]

wow, this all is explained in very easy to understand way.

[awstutorials]

This is the best explanation so far !!

[miletacekovic]

Great video, especially like the steps to verify if we really run the real CD :)
As a side note, maybe it is not obvious, but being able to deploy to production any of the last 10 green builds, means that we also need to have automated database rollbacks, as maybe the chosen build is older than the one already in the production!

[mohamedayman]

I'm Really enjoying your videos. Great explanation, a lot of information and a nice accent. KING 👑

[CriticalThinkerShan]

very nice... it's business decision when to deploy, not should be a technical one.

[antonikucherov]

I absolutely like this video! Btw looks like you love word "silly" a lot :D

[duhsfex]

Great video, but actually whether or not something gets pushed to the "main line" everyday highly depends on the team size. I'd not go as far and say this needs to happen every single day in order for it to be called CI.

[altrag]

Under these definitions:
1) Only the insane would do continuous deployment. Unless the only changes you ever make are pure refactoring with no (intended) side-effects visible to users, databases or other external systems then you're in a situation where you're either a) the only one testing your own code before it hits production, b) deploying completely untested code while you wait for someone else to "continuously" add/update tests or c) both. I guess if you also have an automated way to detect errors in the wild and rollback quickly this might be somewhat mitigated, but that's an extremely complex ask.

2) Only the insane would do "continuous" anything. That implies that every task can be broken down into <1 day chunks that are fully separable and individually deployable. That means either massive amounts of overhead to avoid breaking things with partially-developed code or hoping to hell whatever partial code you do push goes red (and prevents deployment) while you're finishing the rest of the code. And hoping that nobody else wants to deploy the same project during that time period. It would be nice if every single development task fit neatly into a discrete series of non-overlapping 8 hour windows, but that's not realistic in most cases.

2b) And if you don't have any updates for a particular project that week you're just magically not "continuous" unless you create dummy builds for no reason other than to retain a label. Of course if you have enough developers and consider "continuous" to be any deployment rather than on a per-project basis then its likely that somebody will be pushing something every day, but now you've described the size of your dev team rather than describing your deployment strategy.

I think a more useful definition of continuous is "code can be deployed as soon as its ready" (not having to wait for a deployment cycle or manual testing or other delays that could potentially be automated) rather than "code must be pushed within an arbitrary time limit regardless of whether its deployable or not". That leaves "ready" open for interpretation to be sure, but I don't see that as a bad thing necessarily - its a point where business decisions can trade off speed vs risk (are partial features and MVPs acceptable or should we only deploy once the entire feature is fully baked? Does a full test suite have to be developed before merging a feature or do we trust our devs to be "good enough" and just eat the occasional rollback when that trust fails? Etc.).

[ddanielsandberg]

I have to say something.
Continuous Delivery does not imply that *every* step is automated. While most of the checks are automated, there should still be room for manual testing within the pipeline, especially if it's a user facing product. CD is about workflow automation (as in SDLC process), not to defer all thinking to computers.

[ns]

Hi, Great videos, i'm going to watch all. Can you please do a video on gitflow + devops/pipelines and (why not how that would work with argo) from dev perspective? Like how would someone test their feature/bug branch, how are changes reaching dev/qa/staging/prod envs if they are on different branches and must go via different pipelines? How/where would a manual QA test a feature (in terms of devops/env process)?
Update: If everything goes to the main line, does this mean that there is one pipeline which deliver first to dev, then qa, then staging then prod? If yes, why do we need dev/release/main branches?

[bckhwk]

Do you have a book/course where you explain all the patterns and strategies, principle in DevOps?