Analysis of Jenkins for DevOps : Part IV (END)

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.

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

 

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.