And for those of you who would want to follow today's activities, to see the things I'll be talking about in the flesh, there are three things you should do before you do that. To get started, head over to the Discord chat for this workshop.
First of all, fork the repository of the application that we're going to be using as our sample app in this workshop. The link, as I mentioned, is in the Discord chat. You can see I have forked it to my own GitHub account just a few moments before the workshop so that we are on the same page.
The second thing to do is creating a account in our CICD tool, which is Buddy. Simply go to Buddy.Works, create an account, and you'll be able to create all those great pipelines with me.
The third thing to do, if you're planning to follow along with what I'm going to be showing you today, you're going to need a couple of features that are not available upon registration to all users. So make sure to create your account now and copy the workspace link and send it over in the Discord chat so that our team can sort you out and enable these additional features that you are going to need in the later part of the workshop.
If you're wondering what's the workspace link, that's the link that you get right after you sign into Buddy. As you can see, my workspace is JSNation and I'm going to be creating my projects in this here workplace.
And one more thing, since we all love free stuff and goodies, we've thought about that and we have prepared a goodie bag, swag bag, so to say, for you. So if you want to grab that, there's a form also in the same Discord chat. Leave us your email and we'll sort you out with a shipment of Buddy-themed goodies.
So now I'm going to switch over to my slides and we are going to be doing a bit of theory. I'm also going to take a sip of water because I'm already parched. It's very hot in here. This is the full name of our workshop and the next slide is the introduction to what we are going to be talking about today for what's one of the most important things we are going to be talking about today. And I think that this introduction, it's going to be a nice bit of warm-up for all of us and it might be necessary, as we have learned today, as we have listed this workshop as suitable for everybody, so you don't have to be an expert in these matters. We are going to attempt at giving you the knowledge you require to understand everything you hear and see today.
So without further ado, let's start. We are on a tight schedule. We have three hours slotted. We should be done in about two hours, 15 minutes, I suppose, but we'll see about that.
So first of all, CI-CD, we have two abbreviations, but actually there are three concepts behind these two abbreviations. These three concepts are continuous integration, continuous delivery and continuous deployment. And keep in mind, this is a very basic thing, but I see that people get it wrong quite often that none of these three, continuous integration, delivery and deployment, none of these are a tool, so to say. So if somebody asks you, hey, if you're using continuous integration in your project or what do you think about continuous delivery, don't start talking about any tools. None of these are a tool. These are practices, approaches, that all focus on creating an efficient and automated process for delivering software.
As you can see in this nice graph here, these processes, they each go a step further in this timeline of this life of code and I'm about to tell you in this little peel of knowledge how they do that.
So first of all, what's continuous integration? To keep it short, when you hear continuous integration, you should be thinking about merging your changes back to the main branch as often as possible. Continuously integrating your changes with the main line of code. When people are talking about continuous integration, there's always in the back of our heads when we are talking about this, there's always automated tests. So whenever you integrate your code with the main line, there are automated tests running and making sure that nothing breaks, that everything is going to be fine. When this code that you have just created or refactored, that when it goes to the main line, nothing blows up. And what does continuous integration help with? It helps you avoid what's known as integration hell.
If you haven't heard about it, or if that's a term that's unfamiliar to you, imagine a situation where you work on a feature, let's say for a month and a half. And then you're done and your manager says, Well, okay, so you and your two other developer friends, you guys are going to integrate on Monday because on Thursday we're releasing. So, from Monday to Thursday, there are three days and you have three days to integrate your code, make sure it plays nice with all the features developed by other developers in your team. And this can be very stressful. Things might go wrong. You haven't really tested your changes against what other people in your project have done. So, you have no idea how this is going to go. And continuous integration, so automatic testing and getting your changes integrated into the mainline. Very often, this helps you mitigate that and be much more calm and less stressed.
Now, onto continuous delivery. You can think of continuous delivery as an extension of continuous integration. So, continuous integration is all about taking your code, building your application, testing it, and getting these changes integrated into the mainline. What continuous delivery does is it extends this automation to the release process. So, everything gets built and gets ready for your app to be deployed with just a click of a button. And this click of a button, this human element, is very important and, I'd say, is crucial to what continuous delivery is. The automation is introduced up to a point. So, you still have a control over when your application, your code gets released to production. It's not that you don't have an opportunity to look over the logs or maybe to manually test the app on the staging environment. You still get a high degree of control when you are going to release your code to the hands of the users or customers.
And then, finally, the third of the trio, Thress Ombres, is continuous integration. No, sorry, continuous deployment, I mean. Which is, again, takes this entire idea one step further. And what I mean by that is that the entire journey of code, from developing, writing, anything you do manually, to then automated tests. This has been automated in the previous two instances. But continuous deployment automates the deployment as well. So provided your changes don't break anything, they pass all the automated tests that are defined in your project, your application gets to production very, very quickly.
So that's the three concepts behind the two abbreviations. And you might ask yourself, why would you want to do that? Why would you want to put so much emphasis of this continuous aspect of these three concepts? Right? And I think that there's this old wisdom that if you practice more, you get better. And it's been paraphrased to fit the IT world a little bit better. So if it hurts, do it more often. So things like releasing, integrating, and testing. These things can be, well, maybe not, they won't hurt you physically, but they might be problematic, they might be stressful, they might create some situations that you are not sure how to handle.