Hello and welcome, welcome to the next project in the Devils Project.
Chris, the name of this project is Continuous Delivery with Jenkins and Tool's.
So if you have done continuous integration project, this is just an extension of that project, continuous
delivery folks will understand what is continuous delivery.
What are the problems that it solved and then will set up the coordinate delivery pipeline.
OK, so this is the scenario there are there is a product development happening.
With agile SDLC, so all these developers are making regular code changes and building the product,
and in Energises Realty, developers will make regular code changes.
And all this code changes, which which gets merged with your remote repository, needs to be built,
tested and also needs to be deployed to servers for further software testing or performance testing
or load testing.
So before you when it gets promoted to the production, there are so many tests that happens first on
the code that happens in the gaudiness integration pipeline.
And then after delivering the code to the servers, more tests are conducted.
So once the code is packaged into an artifact, it will be deployed to servers, maybe staging servers,
and then there'll be more tests conducted like software testing, integration testing, low testing,
performance testing.
And if this test reports checks out, fine, then only you get approval to deploy your changes to production.
Now we have to understand we are working in an agile environment, they'll be frequent chord changes
and all this changes needs to be deployed to different different servers, which is called delivery,
and which will be very time consuming if this process is manual.
And whatever the obstacles will not be able to cope with such frequent changes, they will not be able
to deployed so frequently.
The process is manual.
And moreover, here comes a lot of dependencies, the developer will be dependent on building the least
team.
Those teams will be dependent on operations team.
And the interaction in between these teams will be happening through ticketing system all through emails
and some fancy tools also, but my point is there are too much of dependencies, too many tools involved
which actually delays the process of delivery.
So developer as fast as they're developing the code, not at the same speed or not at the same pace,
the code is delivered to the server.
One thing is for sure, in this fast-moving world, whenever there is a code change, this code needs
to be built, tested, deployed and then tested more further before you deploy to production system.
And if this has to be done for every comment, every request, then this process needs to be automated.
And whatever you believe, you test or deploy all for every place.
There should be a notification, every task, completion or failure.
There should be notification.
If something fails, the product owner who is the responsible developer or a tester will get into it
and fix those problems, even operations team.
So if there is any bug in a code that can be isolated very quickly and developers can work on making
the code change, making all the fix and patches, and then this automated process can repeat again.
So completely automated, build, test, deploy, test, deploy, that's OK.
This entire process is called this continuous delivery process.
And when you hear the word delivery really means delivering a preproduction, so your artifact is really
ready now to deploy to production.
We have not deployed to production.
We're still waiting for the approval.
We have delivered it to all the prepared environment and even tested it.
And we are ready to deploy it on production.
We just need the approval.
That's what is continuous delivery process.
And we'll understand it much better by doing it.
Some common benefits about cantinas deliveries, you can resolve any issue quickly.
Syrian wait and accumulate the bugs and errors in the code, if there is any problem of code, fix will
be done, automated process will deploy to everywhere and will make their test quickly.
So meantime, to repair will be very short.
It will be very agile and no human intervention or very, very less human intervention, no human intervention
is better, actually.
So you try to achieve with your continuous delivery pipeline, no human intervention.
In such cases, when you're running your pipeline and if you happen to have any Balgownie error in your
pipeline or in the court, it can be isolated very quickly and you can fix it.
OK, now let's see the tools that we are going to use.
For this project, Jenkins is going to be our continuous integration server.
We are going to use it for the version control system.
Maven will be able to build tool because we have Java Code, Czech style.
We are going to use for code analysis.
Slack for notification will be using.
Nexxus Cyanotype repository will tell me when is going to download dependencies from Nexxus Repository
and also going to upload our artifact, the artifact that we generate from the continuous integration
pipeline will be uploaded to Nexxus Repository.
It's going to be a software repository.
Soknacki observer for analysis, much more good analysis, actually, in detail about you don't get
where we are going to use, where we're going to deploy our artifacts are going to deliver or artifact
to about you don't get server.
And we'll also have some background services like Michael Memcache and ask you if had done the profile
project deployment, you know, what are the services I'm talking about?
We're going to provision all this on the easy to instances.
Selenium going to used for software testing.
We're going to conduct the software testing on a Windows server, so we'll create a Windows server and
we'll add it as a slave to Jenkins and we're going to perform software testing by using selenium on
that Windows server.
And this will happen all automatically.
Every time there is a deployment to the server, selenium test will get automatically executed.
And and the result?
All this will be setting up on a tablas cloud will be using a tablas easy to instances and only see
Dunstone says we we're going to set up Jenkins' Nexxus, Sonor Kube Tomcat, my sequel, Windows Server.
Yeah, I know there are many, but when you need to have a continuous delivery pipeline, you need to
create all those things.
OK, the objectives, so we want full isolation quickly, we want short mkdir.
We want fast turnaround time, so if there is any new request, any new code change, it can be built
quickly by the developer and can be also delivered very quickly.
So that's what fast turnaround time means here.
And less disruptive, once everything is automated, you and that continuous delivery pipeline.
Then there will be less chance of making human error nor human error actually in the pipeline is going
on.
So it's going to be less disruptive.
All right, so let's achieve our goals.
OK, now we'll see architecture of continuous delivery pipeline and also the flow of execution, how
are we going to execute this entire project?
OK, so this is the design.
So first thing that makes a chord change, once you have a continuous delivery pipeline set up, then
this entire process will execute automatically.
So the law makes a code change into a remote repository.
We are using we are going to use GitHub, so as soon as there is a new comit in GitHub, Jinky server
automation server is going to fetch the latest changes, automatically build it, run some test unit,
test our code analysis, all the kinds of test and give the information to.
The developer on slack out water, they're using Vigen to use Slack for notification.
Then the next job in the pipeline will get executed, which is actually going to package the artifact
work unit and store it on some remote repositories.
Remote software repository like Nexus, so we're going to use Nexus stenotype repository, once that
is done, the notification is sent, the next job then gets triggered automatically, which is going
to deploy the artifact to staging environment.
Once it is deployed to a staging environment, there'll be a few more test conducted integration test
load test, any software testing.
So there will be a software testers, test scripts.
We're going to execute that from a Windows server, which is going to check our staging environment
for any bugs, any errors, if everything is good.
Then again, the notification will be sent, the artifact can then be stored to somewhere else for production
deployment or like S3, or you can keep it in Nexis repository also.
And this will be a very, very tested artifact.
The same artifact can deployed on production.
Now in continuous delivery.
We don't automatically deployed to production and continuous delivery via Dunton here and we wait for
the approval.
We have the artifact stored now which is well tested, deployed and again tested.
We are waiting for the approval.
Once we have the approval, we are going to trigger a job which is going to do deployment to production
environment and a few more tests will be conducted.
So it will be a manual trigger.
OK, let's see the flow of execution.
So first, we're going to log into account, we're going to do all on a WCT two instances, folks will
create a log in Key will create a security group for Jenkins Nexus and so on.
That cube server will could exit instances with user data will create for Jenkins Sonor Cube Nexus and
will do Jenkins post installation steps.
We'll set up an repository with three repositories inside MAVEN repositories.
Then we're going to do Soknacki post installation steps.
Then we'll do Jenkins set up, we're going to force a big job, will set up slack notification.
We'll set up a.
Good job.
This job is going to do core analysis with checks.
Then we going to set up Sonoko integration.
We're going to set to integrate Soknacki server with Jenkins will set up a job.
Which will do cold analysis by using sonar scanner and uploaded to sonar observer.
The next job we're going to set up to upload our tested artifact to Nexis repository.
Finally begin to connect all the jobs together with Build Pipeline and will also set automatic trigger.
So whenever there is a code change, this pipeline gets triggered.
Here, it's continuous integration pipeline.
So then we'll make some change with it, you're going to push a new code and which will actually trigger
this pipeline.
OK.
So you will see continuous integration pipeline.
And now we're going to extend this further continuous delivery extension of continuous integration.
Of course, when you have canteen's integration pipeline, then will set up continuous delivery pipeline.
So then we need some said, what are you going to create security group for a Windows Server and tomcatting
back in server?
We'll set up Tom back and settled on Ecija instance with usually does automatically legal provision
these instances.
Will Christina Jenkins job to deploy our artifact to staging server staging, Tom Katsuura will deploy
the artifact from Jenkins.
Then will out of windows, not as a slave to Jenkins, we are doing this so we can execute our software
test cases from here.
So will create a job, that job will execute on Windows Server, it will execute our selenium to suit.
Then once this is done, will deploy the artifact to production server.
By now, we'll have many more jobs and then we're going to finally connect all the jobs in the pipeline
together and we'll test it by making a change now when we make a code change.
It will fetch the code with the code tested, deployed to staging environment again, run more tests
and then finally deploy to production environment production environment will be with approval.
So we are going to do production deployment manually.
The trigger will be manual job will be executed automatically.
What the trigger will be manual.
OK, so there are a lot of things to do.
Let's get started now.
OK, so first, we're going to set up a continuous integration pipeline in the first half of the project,
we have continuous integration pipeline and in the second half, we're going to extend that to continuous
delivery pipeline.
If you have already done continuous integration job on Jenkins', the complete continuous integration
project, if you already have ready on Jenkins, you can skip to the second half and continue from continuous
delivery.
So first half is continuous integration.
As you see on the screen.
We're going to set up this forced.
Once this is done, we will extend it to this continuous delivery pipeline that will be in the second
half.
So let's get started.