• Home
  • Archive
  • Tools
  • Contact Us

The Customize Windows

Technology Journal

  • Cloud Computing
  • Computer
  • Digital Photography
  • Windows 7
  • Archive
  • Cloud Computing
  • Virtualization
  • Computer and Internet
  • Digital Photography
  • Android
  • Sysadmin
  • Electronics
  • Big Data
  • Virtualization
  • Downloads
  • Web Development
  • Apple
  • Android
Advertisement
You are here: Home » Analysis of Jenkins for DevOps : Part IV (END)

By Abhishek Ghosh September 13, 2018 3:27 pm Updated on September 19, 2018

Analysis of Jenkins for DevOps : Part IV (END)

Advertisement

In Part III of the Series on Analysis of Jenkins for DevOps, We Have Discussed About Continuous Integration and Continuous Deployment. Automated deployment, and the more advanced form, continuous deployment or continuous delivery, can be seen as the culmination of the modern CI infrastructure. Remaining part of the series is evaluation, outlook and conclusion. Within Evaluation; we have Integration, Quality Assurance, Build Process, Software Distribution. Within this part of the series, we will discuss around the identified efforts during and after the installation and configuration of Jenkins.

 

Analysis of Jenkins for DevOps : Evaluation

 

Integration

When installing Jenkins we saw that two variants are offered. The installation can be done via a package manager, as independent software. The alternative is to distribute the Jenkins as a WAR file to an existing application server. In the first variant, ideally, only four console commands are needed to complete the Jenkins installation. The installation was done as part of the case study work on a simple Debian system. In a medium to large business, it is very likely that these four steps are not enough to completely install the Jenkins, as for example, proxy settings dictated by corporate security standards must be configured. Even with this extra effort, the installation is still very simple and clear. Assuming that an application server is already installed on the Debian system, the installation becomes even simpler. Here, the second variant can be used, reducing the installation effort to two steps: downloading the WAR file and moving/copying the file to the application server. Even larger companies do not need to take additional steps, assuming that an administrator performing the installation has the necessary rights to download and move a file. Overall, it can be said that the Jenkins is very easy to install, no matter which variant is chosen. that an application server is already installed on the Debian system, the installation becomes even simpler. Here, the second variant can be used, reducing the installation effort to two steps: downloading the WAR file and moving/copying the file to the application server. Even the larger companies do not need to take additional steps, assuming that an administrator performing the installation has the necessary rights to download and move a file. Overall, it can be said that the Jenkins is very easy to install, no matter which variant is chosen. If an application server is already installed on the Debian system, the installation becomes even simpler. Here, the second variant can be used, reducing the installation effort to two steps: downloading the WAR file and moving/copying the file to the application server. Even larger companies do not need to take additional steps, assuming that an administrator performing the installation has the necessary rights to download and move a file. Overall, it can be said that the Jenkins is very easy to install, no matter which variant is chosen. This reduces the installation effort to two steps: Downloading the WAR file and moving/copying the file to the application server. Even larger companies do not need to take additional steps, assuming that an administrator performing the installation has the necessary rights to download and move a file. Overall, it can be said that the Jenkins is very easy to install, no matter which variant is chosen. This reduces the installation effort to two steps: Downloading the WAR file and moving/copying the file to the application server. Even larger companies do not need to take additional steps, assuming that an administrator performing the installation has the necessary rights to download and move a file. Overall, it can be said that the Jenkins is very easy to install, no matter which variant is chosen. has the necessary rights to download and move a file. Overall, it can be said that the Jenkins is very easy to install, no matter which variant is chosen. has the necessary rights to download and move a file. Overall, it can be said that the Jenkins is very easy to install, no matter which variant is chosen.

Advertisement

---

The incorporation of new jobs into the Jenkins is a task that has to be performed every time a new software project is started. During the development of the Jenkins it was evidently taken care to make this process as uncomplicated as possible. If a similar project already exists, the job configuration can be adopted in a new project. After adjusting the differences, the job is ready for immediate use. Even if there is no existing project to take over the configuration, a new job can be created within six steps using the “Free Style” software project. This is possible because the required configuration is kept to a minimum and centralized in the user interface. If required, advanced settings can be made.

In order to highlight how the project flow for a project team changes after the use of Jenkins, it is necessary to know the process before the mission. A generalized example of this looks like this:

  1. Software code is written and imported into the version management.
  2. At irregular intervals, a project manager asks for a demonstration of the current software release.
  3. A test environment will be needed.
  4. A deployment manager must be interrupted in his work and import the new software version into a test environment.
  5. The deployment manager manually copies the new software version to the test environment. This often causes errors, which often requires the process to be repeated.
  6. The software testers must wait for the entire time to load the new version.

For large software projects, it is quite possible that the operations described above need to be performed several times a day. In this process, a lot of unnecessary breaks and distractions are lost through time. The path of the software from the test environment to the productive system is not included in the list above. The same process after the introduction of Jenkins, generalized, looks like this:

  1. Software code is written and imported into the version management.
  2. A few minutes later, the current software version is automatically available in the test environment and ready for use.
  3. The project manager looks at the software version directly in the test environment and can be sure that this is the latest version.
  4. If the quality assurance and the project manager are convinced of the current state, this can be imported with a mouse click into the productive environment.
  5. It can be seen that the introduction of Jenkins, although the operation of development and operation is impaired, but only take steps away as they are automatically taken over by the Jenkins. The result is a significant reduction in workload and process streamlining for the departments involved.

Quality Assurance

For the configuration of automated tests, the Jenkins platform offers various jobs that can be extended by means of plug-ins to phases for testing. This provides developers with a great deal of freedom in choosing their tools to test and does not hamper the team. Each development team can continue to work with their familiar test creation tool, highlighting one of Jenkins’ great advantages.

For example, Junit can be used for testing. JUnit knows several types of tests that are not limited to unit tests. Integration and performance tests can also be integrated into the job. In Jenkins, all that needs to be done is to specify the phase of the Maven build process that defines the execution of the tests. The Jenkins does not care about the actual execution of the tests, these are taken over by the plugin. As a result, the Jenkins is not tied to unit testing, but supports all other types of testing as long as the particular plugin does. Thus, all possible test phases can be mapped across the Jenkins within the QA pipeline. The pipeline, which includes testing as a concept for automating builds, has the advantage that all tests,

By distinguishing between various completion states of the builds within the Jenkins, it is easy to see from which area an error originated. Unstable builds signal that errors have occurred during the test phase. In the overview of the job this can be recognized quickly for the developer. This location should therefore always be the first port of call when searching for an error. By means of this information, the developer is given the opportunity to eliminate the error as quickly as possible. Within the overview of the unstable build the test results can be seen. If you now want to find out the exact cause of the error, this can be done simply by looking into the respective test.

In the field of performance testing, the Jenkins also provides support. The results of the tests also show how long they last and whether or not they have been configured for it. Unit tests are also profiled, giving the developer an insight into the performance of new features without the need for explicit performance testing. The Jenkins feature works off the developer when performance is an important topic within the application.

Finally, to automate testing within the Jenkins, it can be said that the freedom to choose the plug-in that takes care of running the tests is beneficial for a DevOps environment. The teams can choose this themselves and test results and statistics on these results are stored centrally in the Jenkins and can be accessed quickly and clearly. This promotes the interaction of the different departments and simplifies the monitoring of tests. Creating a QA pipeline is done by defining different phases within the Build Management tool rather than directly from the Jenkins itself.

Build Process

The following describes how Fern the Jenkins meets the build process requirements. The requirements of a build process consist of the compilation of the program code, generation of documentation, execution of unit test and the generation of a deliverable format. Since the Continuous Integration Tool should not perform these tasks by itself, it is particularly important how well existing build skips can be integrated into the tool. In the case of Jenkins, the most popular build tools, Ant and Maven, are supported by default. The integration of Maven goes so far that Maven syntax can be used directly in Jenkins. The training effort for users who have previously worked only with Maven, thereby greatly reduced. If a build tool is to be used, which is not easily supported by the Jenkins, numerous plugins are offered, which provide the support later. This is where the extensive expandability and modular design of the Jenkins becomes apparent, which includes a total of over 1000 plugins.

However, continuous integration build jobs are more than simply executing build scripts. Notifications are an indispensable part of the Continuous Integration Strategy. A failed build can not help anyone if nobody is notified about the event. Again, the Jenkins allows a simple configuration to send notifications of errors in the build process. The default configuration is chosen so that there is no need for further customization in most applications. Overall, the configuration of notifications is very intuitive and simple, saving a significant amount of time. In addition, it should be noted that there are a variety of Notification system. Messages about fatal or unstable build jobs can be sent via e-mail or various chat programs. The Jenkins can thus be adapted to a wide variety of corporate environments.

Software distribution

Automated deployment, and the more advanced form, continuous deployment or continuous delivery, can be seen as the culmination of the modern CI infrastructure. Of course, it is generally possible to manually write the deployment script for the application. In some applications, it may even be unavoidable. However, since Jenkins extensions are available for a large number of application servers, they can greatly simplify deployment. On the one hand it can be seen as a disadvantage that the function of the Deployment is not supported by the Jenkins by default. On the other hand, standard support would unnecessarily increase the size of the application, as all application servers would need to be supported. Due to the modular architecture, the appropriate plugin for the respective application server can be selected. The number of extension types supported is very large. Well-known systems such as Tomcat or GlassFish, to less well-known ones such as the IBM WebSphere Application Server, are all configurable by extensions of the Jenkins for deployment. In the investigation of the Jenkins the general Continuous Deployment techniques, focused on Java projects, were shown. However, the basic principles apply to other technologies as well. This is again due to the extensive extensibility. When setting up the automated deployment with Jenkins, there are a few important things to keep in mind. Deployment is the endpoint of any CI architecture and can not work without pre-build jobs, unit tests, and quality checks. Jenkins offers security and clarity in the sometimes very complex architectures that can result from this. If something fails before deployment, detailed notifications can quickly tell you where the problem lies. Rolling back plays an essential role in the requirements of a tool that should implement continuous deployment. Here, the Jenkins has the advantage that the project itself can serve as a version control for built artifacts. Jenkins keeps all successfully built artifacts by default, which makes it possible to roll back to a bug-free version. However, this native versioning is not required. Due to additional settings, it is always possible to integrate the company’s own version management.

Another requirement is the reusability of the built application files or binaries using the Jenkins. This feature is not included without extensions in the Jenkins project. Only after installing the Artifact Plugin is it possible to reuse an artifact from an already completed build job. The integration of the plugin takes little time, but it would be desirable here that this feature would already be included in the Jenkins by default, as it is an essential feature in terms of continuous deployment and continuous delivery.

 

Conclusion

 

Analysis of Jenkins for DevOp

Jenkins, as a continuous integration tool, allows project teams to focus on their work by automating the build process, artifact management and deployment process. This is so well implemented that the Jenkins are no longer indispensable to DevOps today. This is the result of several features of the Jenkins:

  1. A simple installation: The simplest installation of the Jenkin takes just two steps. Downloading the WAR file and distributing this file to an application server.
  2. Clear and easy to use: Configurations can be taken over and adapted from already existing projects. The necessary settings when creating a new build job are kept manageable.
  3. Support for a wide range of technologies: The Jenkins not only supports projects based on the Java programming language but also C, C #, Python, Perl, SQL and many more. The support is not limited to the programming languages ​​but also includes the well-known build tools like Maven and Ant.
  4. Extensibility: In addition to the basic functionality, there are now over 1200 extensions that, as needed, provide the Jenkins with enhanced functionality.

The core functionality and flexibility allow the Jenkins to be integrated into a variety of enterprise environments. The Jenkins adapts to the company and not the other way around. Nevertheless, an agile project organization is a prerequisite, so that the Jenkins can be used as a DevOps tool. The Jenkins project is a tool that greatly simplifies working in a DevOps environment through automation, but it can not compensate for organizational issues within an operation.

With the release of newer Jenkins, several improvements have been introduced, which are also of importance for use in the DevOps environment. The biggest changes include a user-friendly pipeline and improved usability.

Domain Specific Language (DSL) makes it possible to create your own individual pipeline with completely individual phases. Creating complex pipelines takes longer with this method than using a preconfigured job, but it gives you more freedom, but it can make simple test-build-deploy pipelines faster and easier. This also enables application-based pipelines. In addition, almost everything can be automated. This configuration of the pipeline is stored in a file. This file can be versioned and placed next to the code so that the pipeline can be saved to a particular software version.

After setting up the Jenkins, the user is now asked for the start whether he wants to install as a standard plugins or even install plugins. This was an important step in the direction of usability, as new users are overwhelmed by the number of available plugins and usually do not need very special plugins. This facilitates the placement of the jenkin and reduces the initial hurdle to using the jenkin.

There are also several improvements to the user interface. This includes, among other things, the Jenkins installer and Jobs configuration interfaces. All in all, the new Jenkins is an improvement over the previous iteration. It simplifies getting started with the Jenkins, helping to integrate the DevOps approach into businesses.

This Article Has Been Shared 243 Times!

Facebook Twitter Pinterest

Abhishek Ghosh

About Abhishek Ghosh

Abhishek Ghosh is a Businessman, Surgeon, Author and Blogger. You can keep touch with him on Twitter - @AbhishekCTRL.

Here’s what we’ve got for you which might like :

Articles Related to Analysis of Jenkins for DevOps : Part IV (END)

  • Cloud Storage : Architecture and Technology

    Cloud Storage is a storage model based on networks, designed in the 1960s. Cloud storage services can be accessed by API or via web interface easy to all users.

  • Hybrid Cloud and the Era of Startup

    Hybrid Cloud Computing has brought the computational power in the pockets of all. Anyone with a credit card in pocket can be access the largest facilities now.

  • Ways To Backup MySQL Database And Save To Cloud Storage

    Here Are Ways To Backup MySQL Database And Save To Cloud Storage Including OpenStack Swift From SSH Side. Needed Scripts Has Been Included.

  • sysctl.conf Tweaking In OpenVZ Virtual Server Instance

    OpenVZ Kernel Offers A Conservative and Stable Kernel. Here Is Some Information On sysctl.conf Tweaking In OpenVZ Virtual Server Instance.

  • Setup SFTP Without Shell Access For WordPress, Cloud Server

    Often We Need To Host Account On VPS OR Cloud Server Where It Is Desired To Have A Setup SFTP Without Shell Access For WordPress Like cPanel.

Additionally, performing a search on this website can help you. Also, we have YouTube Videos.

Take The Conversation Further ...

We'd love to know your thoughts on this article.
Meet the Author over on Twitter to join the conversation right now!

If you want to Advertise on our Article or want a Sponsored Article, you are invited to Contact us.

Contact Us

Subscribe To Our Free Newsletter

Get new posts by email:

Please Confirm the Subscription When Approval Email Will Arrive in Your Email Inbox as Second Step.

Search this website…

 

Popular Articles

Our Homepage is best place to find popular articles!

Here Are Some Good to Read Articles :

  • Cloud Computing Service Models
  • What is Cloud Computing?
  • Cloud Computing and Social Networks in Mobile Space
  • ARM Processor Architecture
  • What Camera Mode to Choose
  • Indispensable MySQL queries for custom fields in WordPress
  • Windows 7 Speech Recognition Scripting Related Tutorials

Social Networks

  • Pinterest (24.3K Followers)
  • Twitter (5.8k Followers)
  • Facebook (5.7k Followers)
  • LinkedIn (3.7k Followers)
  • YouTube (1.3k Followers)
  • GitHub (Repository)
  • GitHub (Gists)
Looking to publish sponsored article on our website?

Contact us

Recent Posts

  • What is Configuration Management February 5, 2023
  • What is ChatGPT? February 3, 2023
  • Zebronics Pixaplay 16 : Entry Level Movie Projector Review February 2, 2023
  • What is Voice User Interface (VUI) January 31, 2023
  • Proxy Server: Design Pattern in Programming January 30, 2023

About This Article

Cite this article as: Abhishek Ghosh, "Analysis of Jenkins for DevOps : Part IV (END)," in The Customize Windows, September 13, 2018, February 6, 2023, https://thecustomizewindows.com/2018/09/analysis-of-jenkins-for-devops-part-iv-end/.

Source:The Customize Windows, JiMA.in

PC users can consult Corrine Chorney for Security.

Want to know more about us? Read Notability and Mentions & Our Setup.

Copyright © 2023 - The Customize Windows | dESIGNed by The Customize Windows

Copyright  · Privacy Policy  · Advertising Policy  · Terms of Service  · Refund Policy

We use cookies on our website to give you the most relevant experience by remembering your preferences and repeat visits. By clicking “Accept”, you consent to the use of ALL the cookies.
Do not sell my personal information.
Cookie SettingsAccept
Manage consent

Privacy Overview

This website uses cookies to improve your experience while you navigate through the website. Out of these, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may affect your browsing experience.
Necessary
Always Enabled
Necessary cookies are absolutely essential for the website to function properly. These cookies ensure basic functionalities and security features of the website, anonymously.
CookieDurationDescription
cookielawinfo-checkbox-analytics11 monthsThis cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Analytics".
cookielawinfo-checkbox-functional11 monthsThe cookie is set by GDPR cookie consent to record the user consent for the cookies in the category "Functional".
cookielawinfo-checkbox-necessary11 monthsThis cookie is set by GDPR Cookie Consent plugin. The cookies is used to store the user consent for the cookies in the category "Necessary".
cookielawinfo-checkbox-others11 monthsThis cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Other.
cookielawinfo-checkbox-performance11 monthsThis cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Performance".
viewed_cookie_policy11 monthsThe cookie is set by the GDPR Cookie Consent plugin and is used to store whether or not user has consented to the use of cookies. It does not store any personal data.
Functional
Functional cookies help to perform certain functionalities like sharing the content of the website on social media platforms, collect feedbacks, and other third-party features.
Performance
Performance cookies are used to understand and analyze the key performance indexes of the website which helps in delivering a better user experience for the visitors.
Analytics
Analytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics the number of visitors, bounce rate, traffic source, etc.
Advertisement
Advertisement cookies are used to provide visitors with relevant ads and marketing campaigns. These cookies track visitors across websites and collect information to provide customized ads.
Others
Other uncategorized cookies are those that are being analyzed and have not been classified into a category as yet.
SAVE & ACCEPT