Table of Contents
- The traditional flow of code
- Code Terminal
- Quality Assurance
- What is Jenkins?
- How Jenkins work?.
- The basic infrastructure of Jenkins
- Detailed Structure of Jenkins.
- Video Tutorial
1 Traditional Flow of Code
First, we will discuss the traditional flow of code during a life cycle of software development
- Now, in the beginning, the code is written in the terminals, and then it is stored in the storage where it could be a GIT or it could be local and after that, the code is passed on to Quality Assurance.
- In quality assurance, the code is tested and managed by the developers of the team and after that, it is passed on to testing.
- The testing place is where the tests the code for any faults and once the code is approved it is passed on to production.
- Now as you can see here in this layout is the flow of code is done on a manual basis and if let see in case if there is some issue in testing then the testing team will push back the code to the quality assurance and quality assurance is saying that the code is running fine at there and then thereby some dispute between both the teams and it generally happens when we are using a manual deployment process.
2. What is Jenkins?
Now here comes the role of Jenkins.
- Jenkins is a powerful application that allows continuous integration and continuous delivery of projects. So, by that, we mean that it is a tool through which we can do various types of activities which can help in the continuous integration of a project with that it means that we are integrating the components.
- Continuous integration is a software development practice in which the members of a team integrates their work frequently. so continuous integration is a broad term various factors can be included in continuous integration.
- The biggest benefit of Jenkins is that it can be attached to various types of deployment technologies.
- Now talking about continuous integration like what was the architecture of the software life cycle when there was no continuous integration and what was the structure of the software life cycle when the continuous integration was introduced.
- Now before continuous integration, the entire source code was built and tested to the entire source code was needed to be built with all the features then all the features are tested at one time.
- After continuous integration now every commit made by the developer in the source code is built and tested at the same time on the fly. So is come it is tested and built to increase the commit if the commit doesn’t go right then we can pull back the changes at that moment only so we don’t have to be the entire source code again and again.
- Now developers in the before continuous integration developer have to wait for test results because all these things were done manually most of the tools which we are using for testing are introduced two years ago.
- After continuous integration developers now test the result of every commit made in the source code on the run so that developers can easily check the results of the source code testing in a fraction of seconds when the test is completed.
- In continuous integration, there was no feedback by feedback we mean that we have a calculated set of results which helps us in understanding the flaws in our code but after continuous integration, we have also the feedback.
3.How Jenkins Work?
- In the first place, the developers commit the court and push their food on the second step the Jenkins will pick up the change source code and trigger a build and run the test cases.
- Also in this simply means that when a source code is used then the Jenkins tools will pick up that code and trigger a build.
- Now this does triggering of the build could be done using many deployment tools and after that, there are a certain set of cases that can be implemented on the code, and here are also many tools that can be used.
- The build output will be available in the Jenkins dashboard and automatic notification can be sent back to the developer. So the output of the build is itself present in the dashboard so the developer has doesn’t need to check at any other place and also and a notification is sent to the developer which is very helpful.
4. Basic Infrastructure of Jenkins
- As you can see the basic infrastructure of Jenkins and can be as much as complicated with the addition of every too.
- So let us a for the building we are using the Maven tool and power version control system for storing the code we are using the Git tool.
- Now in continuous monitoring we are using Nagios and in continuous deployment for deploying the code we are using Ansible and also to configure the management configuration management of the source code is done by puppet and when it comes to writing the steps for continuous testing we are using Selenium tool all these tools are integrated with the Jenkins and that is what it makes Jenkins powerful application automation of the software snow these are only single tools but we can implement multiple tools using Jenkins.
5. Detailed Structure of Jenkins
- Developers commit changes to the source code.
- Continuous Integration server pulls that code and triggers a build.
- The build application is then deployed on the testing server for testing.
- After testing the application, it is then deployed on the production server
- The concerned teams are constantly notified about the build and test results
- Finally, we say that the Jenkins is a hub of the automation of the deployment which we do in the current scenario of software deployment procedures
- This is a tool that provides both continuous integration and non-continuous integration