Hello and welcome to the cities of Dwarf's Project, the name of this project is Continuous Integration
with Jenkins' and Tool's.
So this is the scenario, let's say you have a product development and agile SDLC is in motion, so
a bunch of smart developers in an agile team will regularly make changes.
So there'll be multiple code changes every day.
And all this code needs to be tested because this is what actually is building your product.
So this code needs to be regularly built and tested.
So usually in an enterprise, there will be a separate building release team will be doing this job
of building, testing and releasing the code, or if it's a small industry, then they'll be it will
be developer's responsibility to merge and integrate this code.
So, yes, there are regular quote changes also called comments or pull requests, developers will be
dependent on building the team, usually to test the code and move it to the next level in the release
cycle.
But not so frequently.
The code will be tested if there are any bugs or whether it will be known late due to these bugs and
errors in the code.
Keep accumulating and let's say these got accumulated.
A problem goes much deeper now, developers need to rework to fix these bugs and errors, which is time
consuming process and seems would be already approaching the deadline.
So Troadec owners really need to test the code as fast as it's billing, but that's not possible because
the billing release team is doing a manual process and also there are approvals and ticketing system
in place which delays the process more further.
So solution to this problem is a regular build and test for every comet, so as soon as there is a code
change, the code needs to be built and tested at the same time.
But if the process is manual, this will not be possible.
So you need to have an automated building release process.
And whenever there is a big and test of the court, the developers should get notified automatically.
So if there is a big failure, if the court is not passing your quality gates or if there is any bug,
any kind of error, the developers will be stopped doing whatever they're doing and they'll fix the
code.
So if you have such kind of automation framework in place, which will regularly build and test the
code for every comic, then you're also removing dependency of developers from building steam.
This process itself is called continuous integration process.
So input to this process is any good comic and output will be well tested artifact and all this will
happen automatically.
Now, this very distant artifact then can be deployed to servers for further software testing or performance
testing, load testing.
And then if everything is good, it can be promoted to production.
So may sound simple, but will be actually so many tools connected together to complete this automated
process.
But this is a well worth investment because to this time is very demanding.
There are regular feedbacks and demands for that.
Developer really need to work regularly and make regular code changes to improve the product.
So in today's time, you should definitely have a continuous integration process.
Let's talk about benefits of continuous integration pipeline, first benefit that you obviously get
is shorter, mean time to repair.
Because here you are not accumulating the boxer as soon as they are found, they are fixed.
So it very well works with the agile team and there will be no human intervention, so we are not dependent
on the developers, are not dependent on building release or operations team to do this, which is a
lot of time.
And obviously, not to mention if there is any fault, any bug, any error, it can be found out very
quickly and can be isolated very quickly.
So in this project, obviously, we're going to set up a continuous integration pipeline.
So now let's talk about the tools that we are going to use in this project.
Starting with Jenkins, Jenkins will be our continuous integration server and main hero in this project
and as hero needs sidekick, our jenkins' hero will also need some assist in tool.
Obviously, we are going to use a version control system, we going to use Git and GitHub as the remote
repository, and we have a Java code in that.
And to build that Java code, we will need build tool even.
We are also going to do some cool analysis, so we are going to use forced check style, which is a
very simple core analysis tool.
But there are more sidekicks, there are more tools, they'll use slack for notification.
We can also have an email integration, so we get email notifications.
We'll use Nexxus, a sonar type to store our artifact and also to download dependancy form.
Even so, orses sonar nexxus will be our software repository.
We're going to get more deeper into your analysis, so we'll be using Soknacki Observer.
So going to scan over Kollwitz on a scanner and check style, and then we're going to publish our results
in Tucson, that cube server dashboard.
And to set up these servers, jinking server, Nexus server, sonor cube server, we are going to use
eatables platform will use eatables easy to instances on C, two instances will set up jinking server,
Nixa Server and Soknacki Observer.
OK, so let's reiterate, our objective will be quick fallout, isolation, shorter media.
Faster turnaround time, so any new request to the new feature needs to be done, it can be done quickly
without disrupting too many things.
So these are our objective to set up a continuous integration pipeline.
All right, let's achieve our goals now.
Before we get started, we'll see continuous integration pipeline architecture.
So you'll have a very clear understanding what we are trying to achieve.
OK, let's see the workflow first, so developer makes a code change, commit to one control system
or source code manager and automation tool will automatically fetch that code, build it, run a unit
test and return the outcome on election.
And so we'll be using slack anyways.
The next.
Phase will be it will grandcourt analysis and analysis, there will be gaits quality gates if the threshold
if it is not passing the threshold gap, then it's good.
If it's passing the threshold, then a notification will be sent on like channel.
If this is good, it goes to the next level.
Then the software will be built, it will be packaged and the artifact will be uploaded and its outcome
notification will be also sent.
The artifact or the software will be stored in the artifact repository, if all these stages are successful,
then the software can be promoted to the next level.
If there is any failure, the notification will be any anyways sent.
Once the notification is received by the developer for any failure they will make, the code will make
the fix and the process repeats again.
So there will be regular code commits, continuous code commits, and this process will run continuously.
So that's why the need continuous continuous integration.
So this process will be automated, so this can be done multiple times in a day if you want.
OK, now let's see architectural design by using all the tools.
So a developer will make code change by using his or her ID like visual studio, our intelligence,
and that tool, that idea will be connected to a good repository.
So developer makes a code change and commits.
This comet will be synched with a remote repository, will be using GitHub, so as soon as GitHub receives
a comet.
Our continuous integration server, Jenkins, will detect that and fetch the changes, fetch the latest
code so it will have an integration with GitHub.
Then Jenkins, you know, Jenkins will be running some court test.
Unit test, basically, which is part of your build process, if there is any failure, the notification
will be sent if it passes.
Good analysis will be done on the court by using try and assume that scanner, so in this project will
have multiple core analysis tool.
So it will generate some report and this report we are going to publish Ensenat Observer, Sonakshi
Observer will display the result and will also have quality gates, a quality criteria if you're passing
the quality criteria.
We can move to the next level or a failure notification will be sent and the process really stops.
So you see, we're putting brakes at every level, if there is any failure, it automatically breaks.
If not, the process continues automatically anyways.
So once the analysis is done.
Then we build the artifact and we have Java code, so we are going to use Maven tool.
If there is any failures, any errors, notification will be sent.
While the source code is getting built, it will lead some dependency over, may even lead some even
dependency.
Those dependency we will be storing in Nexxus repository.
So Mavin will automatically download all the dependency from Mavin repository, which is in Nexxus,
or is this Monotype nexus?
Once the artifact is packaged, once the software is really created, then the software, we are going
to upload it back to Nexxus sonar type repository.
So really using Nexxus on a repository for two cases.
One is to download dependencies from and the second is uploading our artifact or storing our artifact.
So Vigano version and stored the artifact.
So every time this continuous integration process runs, we have a new version of software.
And based on requirements and choices, any woman then can be selected from the repository and can be
deployed to service.
OK, so now you can really pause the video and watch the architectural design once again.
Let's see, step by step process of our execution was to log into your account, we're going to create
login for our servers.
We could secure the group for three server Jenkins, Nexxus and Sunako.
And you're going to create these two instances where we are going to set up these servers with user
data so automatically there'll be provision.
After that, will conduct some Jenkins post installation and install some plug ins.
Once Jenkins is ready, will set up Nix's a repository, looking to set up three repositories in Nexxus
for MAVEN will do some Sunako post installation steps.
In Jenkins, we're going to create multiple jobs for begin to create a big job.
Then we're going to set up Slark notification.
Once we integrate, Jenkins with Channel will test this.
And then we'll get another job check psychoanalysis job.
Then we'll integrate our Jenkins with Sauniere Cube server.
As soon as you can, their job will be created, if all this is successful, we will upload our artifact
to Nexxus Repository.
Finally, we integrate all these jobs together with built pipeline.
And will set automatic trigger.
So if there is any code change, Jenkins will detect that automatically in this entire process will
run and will does this with our ID, with intelligence.
We are going to make a code change, commit and then see the entire execution and finally will do cleanup.
All right.
Let's get into action now.