We are presenting a brief overview of Continuous Integration and Continuous Delivery practices and how they can be implemented using Jenkins.
[Video Transcript]
From the point of view of Continuous integration, you can think that it's a software development practice where members of a team integrate their work frequently. Right. And after each integration it's done, this is verified using an automated build or test in order to detect different kinds of integration problems. Right? As quick as possible. That is, this is the core.
Continuous integration or CI, it's an automatic process that allows you to check, or I don't know, in completeness of an application code every time each member makes a change and pushes that change to an SCM, right?
We can see that in a DevOps culture, a continuous integration fits very well, from the spirit of collaboration and communication, because the execution of this continuous integration will affect the entire members in the temp, right? From the point of view of the work methodology. And of course from the point of view of collaboration. Besides that from the point of view of the implementation, we have to create some processes, right? We need to create, for example, to branch our code, to commit our code, to make pull requests, to perform code reviews and so on and so forth. And these processes can be automated, right? With different kinds of tools we can think about Jenkins, Get, Azure, and so on and so forth. Google cloud.
With those tools, we make a continuous integration life. But continuous integration is just a short part. We also have a continuous delivery, but as high-level from a continuous integration flow, you have to think about the following steps. We can have a pool, a code update, after the developer performance, the code update on his report, it will push the code to the SCM. Maybe in the SCM, you have some kind of scripts that are doing some unit tests and perform some code validation.
If everything passes, this means that you don't have any failed tests. Now you can merge your code changes, and after that continue the flow pipeline. And the next step, if everything didn't break inside the code itself is to create the packages, to create the binaries and deploy those binaries somewhere else. Right. But in order to do that, we have to use another concept, which is a continuous delivery, right?
In the continuous delivery, we are taking the continuous integration and moving to the next step. To deploy the application somehow in an automatic fashion, in a staging environment or non production environment or create environment. Right. And this workflow it's called sometimes continuous delivery. It depends because continuous delivery versus continuous deployment in some organizations means the same thing in some organizations are different processes, but here again, it depends.
It depends on the culture of the organization. And what we are doing here. We are doing it again. We start with developing our code, our functionality for our application. We build the application, we test it, we deploy it and we can perform a release on a non production environment. And this continuous loop and continuous feedback mechanism creates the continuous delivery pipeline.
Looking at the continuous delivery workflow here, we have the continuous integration part where the developer pulls the code, performs code updates with his new logic, pushes the code to the remote SCM or third party tools where automatic scripts perform the code validations. If everything is fine and all the tests are passing, we can perform the march of the code changes. And from this point, we can do more testing. We can do end to end testing, negative testing, performance, scalability, and we can do that based on the product that we are testing in different kinds of environments, create environments, dev environments, staging environments, and non-production environments.
Having these continuous delivery pipelines implemented inside our company, it can give us some benefits, right? We can find bugs more quickly in the code. We can do faster application iterations and more frequent releases. We'll look, give us reliability on the code because we deploy faster. We see that the code is stable, this means that the code is reliable so we can trust this, but this can be done using these continuous delivery pipelines.
But the list, but not the last, we have continuous deployment. So continuous deployment extenze, somehow the continuous delivery. And here, the difference is that we try to automate the deployment process so that the code can be automatically deployed to production after the entire automated regression testing, it's validated, and we don't have any critical bugs.
To deploy it to production, we can use different strategies like blue-green deployment, Canary deployments, rolling updates, depending on our environment.
What is blue, green deployment or Canada deployments or rolling updates?
I used the terminology from the Kubernetes its site, but to have one short overview of blue green deployment, it's basically replicating the production environment, and having to production environments, right? You have the current production environment with our application, which is up and running and you have the blue deployment where you will deploy the new application, and you just switch between them. So now you are using the production, which is the green one, and you just switch to the blue one.
If everything, it's not okay in the blue environment, you just switch back to the green environment, to the production environment. The downside of these is the fact that you have to create or to replicate the production environment. And from some organizations, this can be expensive for some organizations, it can be very easy to create, but it depends. It is your choice.
Another deployment on the other hand, gives you the ability to release inside the production environment, your new code, your new build, your new version of the application, but that new version is just used by a small number of people and it's not available to the entire or the entire role, users or to the entire team. And after the dose, that small amount of people are validating and testing and interacting with this new version and are giving the OK You can deploy it to a full production or deployment by promoting that specific build.
And this is done somehow using more automation and without any manual steps involved here. So if you are trying to look at continuous work deployment workflow, we can see that we have all the previous steps from the continuous integration and continuous delivery, and what we add here on top of that on top of pool code update, push code validation, march the changes and perform the validation testing. We haven't deployed to production. This is deploy to production, it's some harm how done automatically.
If we're looking at this diagram, where we can compare the continuous delivery and the continuous deployment. We can see that at the point or in the pipeline, from the acceptance test to deployment to production, we have this manual step, right?
This is in the continuous delivery workflow. The difference it's very straightforward that in the deployment, everything is done in the automatic fashion. How can you do that? Is by using some kind of flags and this can be implemented with some feature flags that you have to enable inside the pipeline, and activating those kinds of feature flags, you automate this continuous deployment pipeline.
I think this will conclude the DevOps history and culture. There are many tools that are part of the DevOps ecosystem, and you can see that we have here a periodic table of DevOps tools, which are divided in specific areas, right?
We can have tools for cloud, for collaboration, for deployment, for analytics, for security and so on and so forth. Are too many, we cannot cover all of them, but. If you want to learn more about specific tools, don't forget to check out our DevOps learning paths on DevOps artisan, and what's it going to see here we have from Python, Jenkins and Ansible, Kubernetes, Elastic advanced training like Prometheus's implementing security in dev ops and so on and so forth.
share this on:
