Analysis of Jenkins for DevOps : Part III

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. In part II of analysis of Jenkins for DevOps, we discussed about integration into the project cycle. This is the part III of the series. In This Part 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.

Table of Contents 1 Introduction 2 Continuous Integration 2 Continuous Deployment 3 Conclusion

 

Analysis of Jenkins for DevOps : Continuous Integration

 

Automated tests

Jenkins is a Continuous Integration (CI) platform which has evolved over time into a Continuous Delivery Platform. CI was the first step towards agile development methods in software development. Through CI, when importing code changes in the common coderepository via a hook so-called unit tests are automatically executed and returned in the event of an error. This automatically detects errors in the code and avoids manual search by the developer. This has both shortened the software lifecycle integration phase, allowing faster software delivery and increased developers’ productivity, as they do not have to worry about running them once the tests have been written once.

Unit tests are used to verify the functionality of individual components of a software. Automated execution of unit tests can achieve higher software quality, ensuring that the components always function as expected as long as the unit tests are successful. Unit testing is especially helpful when new features are implemented or old features are adapted to new requirements. They provide a check of existing features for their correctness. As a result, unwanted side effects, which can arise due to changes, can be detected early.

The Jenkins comes with tools designed to simplify the integration of unit tests. For example, the Jenkins can set up a new instance of the Jenkins for each test to be performed. As a result, each test runs in an environment unaffected by previous testing. The Jenkins can simulate user interactions with HtmlUnit and integrate them into the tests. In order to automate tests, the existing Jenkins job must be notified of Maven’s configuration for the test phase. For example, the JUnit plug-in can be used via the POM file to have Jeuins defined in a Java project run by Jenkins.

In order to integrate the unit tests into the automatic build process, the project in the job must have the phase of Maven in which the tests are to be executed by the Jenkins. Maven then takes care of running the tests. After running the tests, the Jenkins can report the results. It may happen that a build of the Jenkins is marked as unstable. This indicates that errors have accumulated during the tests. In general, Jenkins makes a distinction between builds in three categories:

Successful builds

For successful builds, all processes involved in the build have completed without error. Such a build is considered to be of high quality and can be publicized in the productive environment as long as QA has not detected any further bugs on the software.

Unstable builds

An unstable build is a low quality build. Unstable builds occur when the defined tests are completely or partially faulty. The expected behavior of the application is not achieved and the errors must first be cleaned up before the software can be delivered.

Failed builds

Failed builds typically indicate serious compile errors within the application. These builds can not be delivered because the application would not start and the software quality is virtually nonexistent in the built application.

Build

Continuous integration is a process that integrates all development work as early as possible and automatically constructs and tests the resulting artifacts. Artifacts are executable files, in the case of Java, .jar or .war files. This process is intended to detect errors as early as possible. Jenkins is the tool that will do continuous integration and the automatic build process. The basic function of Jenkins is to execute a list of predefined steps. The trigger for this, as already described in previous chapters, time or event-based. This list may include the following steps, for example:

1. Do a software build with Maven or Ant
2. Running a shell script
3. Archive artifacts resulting from the build process
4. Starting unittests

The build process does not necessarily have to be triggered by one of the described triggers. It is also possible to start the build process manually. The theoretical example project used (you need to read our previous part) for this article’s example is based on a Maven build script. Therefore, this chapter mainly focuses on the first point. To define the build of a software project using Maven, a special configuration file called Project Object Model is used. Jenkins offers a job type specifically designed for Maven. This special job type has several advantages over a standard Jenkins job. Analysis of the Maven POM to collect project information drastically reduces the required Jenkins configuration. Jenkins responds to the execution of the maven build and unlocks what to do on its own. An example of this is generated documentation of the program code, which is automatically filtered out and recorded. Dependencies between projects are created automatically. A Maven Builds is divided into several specific phases. Each of these phases has its own responsibility within the process. In order to be able to define which phases are to be executed within a construction process, so-called Maven Goals are specified. The user interface of the Jenkins allows you to call up Maven Goals directly.

An important aspect to consider when building a new project using Jenkins is managing the build history. Historically, running jobs can use a large amount of hard disk space. This is especially true if the created artifacts are to be archived. Even without keeping the artifacts, keeping an entry for each run job consumes additional memory. If the history is not desired and the additional memory required is to be saved, the function can be deactivated or restricted within the Jenkins user interface. However, Jenkins will never delete the last successful build, no matter how old it is.

Equally essential is notifying responsible persons when something fails during the build process. Email alerts are the most common way to do this. Within the Jenkins interface, e-mail notifications can be activated by activating a form field. You can specify a list of addresses that should always be notified and/or notified to the person who initiated the failed build. By default, Jenkins sends emails for any failed or unstable build process. If the error is resolved, a mail will also be sent to indicate that the problem has been resolved. Furthermore, it is possible to notify people via RSS (Really Simple Syndication) feed or chat program.

 

Analysis of Jenkins for DevOps : Continuous Deployment

 

Release

Part of a successful release management is the versioning of the software. Software versions used in the production environment should always have their own version number so that other systems that communicate with the software know how the data exchange works. Interactions are published to the other systems via these standards. Within Maven projects, it is therefore advantageous to choose meaningful version numbers, because the Maven plugin then takes over the referencing of different software versions within the project dependencies. Furthermore, it is recommended to use the Maven standard for software versions, which consists of three numbers. These so-called major versions are unique, committed, once released software versions.

Another important medium of Maven for versioning is the so-called “snapshot”. A snapshot defines a software release that is under development and has not yet been committed through a release. These always show the latest version of the built application. While in the CI concept the software version could always be clearly assigned using other mechanisms, such as a fingerprint of the Jenkins as identification, this approach can not be used in Continuous Deployment (CD). Every built and uniquely identifiable software version within CD must be able to be used in the productive environment. That’s why build management tools like Maven need to evolve to meet that need. The Jenkins itself stores the fingerprints created during the build process in the integrated database to allow it to identify individual software versions, but it can not be understood after distributing the software, which job has built the application. This information is important if, in the event of a fault, it has to be reconstructed whether the application was built correctly.

Continuous Deployment (CD) in the DevOps environment requires a few prerequisites for releasing software:

1. Cooperation of different departments (development, quality assurance, operation)
2. Concatenation of processes of the departments so that a common process for CD can be created
3. High automation of the software delivery process
4. These prerequisites together with the automated build process result in a shortened software realease cycle.

Due to the automated construction of the software, there are several software versions within one day. To avoid unnecessarily many versions, the releases are not all marked with their own version number. The concept of snapshots was therefore developed. As a result, there is only one software version for the version in progress, so developers are always up-to-date with the software as they prepare the next release.

Software distribution

In its elementary form, Continuous Deployment can be simply writing a script to distribute its own software to a specific server. Jenkins offers plugins that allow you to distribute applications to a variety of popular application servers. The Deploy Plugin provides the ability to distribute software to Tomcat, JBoss, and GlassFish servers. The WebSphere Deployer Plugin, on the other hand, supports IBM WebSphere application servers. If other application servers are to be used in connection with Jenkins, it is necessary to integrate the deployment process into the build script or to fall back on self-created scripts.

As our example uses a Java project based on Maven for sample purposes, the deployment of a Java application to an application server with Jenkins is now analyzed. This is also called hot deployment because the application is distributed to a running server. However, depending on the application and server, the approach can lead to memory leaks. Especially older Tomcat versions are prone to this problem. When this problem occurs, you are forced to restart the application server after each deployment, or to start a nightly reboot.

The application to be distributed should not be rebuilt each time, as previous tests would no longer be reliable. Jenkins offers Artifact Plugins. Those plugin allow artifacts to be exchanged between independent build processes. This feature, together with the build triggers, can be used to distribute exactly the binary file that was built and tested in a previous phase. For this approach to be workable, all environment-specific configurations must be swapped out of the artifact. If this is not desired or, for the respective case, not feasible, it is possible to rebuild the artifact, but to refer to a special revision from the version management.

To distribute applications to one of the most popular application servers using Jenkins, the Deploy Plugin is ideal. To see how the plugin works, a simple automatic build pipeline is set up . The default build performs the unit and integration test and builds the redistributable application file in the format of a WAR file. The build metrics then checks the quality standards of the program code. Upon successful completion of both builds, the application will automatically be uploaded to the test environment by the deploy-to-test job. Artifact Plugins are used to copy the WAR file from the “default” build job. Then the Deploy Plugin is used to distribute the WAR file to the test server.

In order to create the possibility to go back an already distributed version, it is important to precisely identify the current version. There are several ways to do this, depending on the role the Jenkins should play in the deployment architecture. Jenkins can be used as a central repository for all versions of the artifacts. With this approach, it makes sense to distribute the artifacts directly from the Jenkins instance. Alternatively, an external repository can be used, which then serves as a central reference point for artifact versions.

In order to be able to specify which version of an artifact is to be distributed, Trigger Plugin is required. Within the setting, a variety of behaviors can be configured to select the artifact version, including the last successful build or a specific build version. After completing the plugin configuration, when starting a build it is possible to select the artifact version to distribute.

 

Conclusion

 

This part briefly discussed mainly Continuous Integration and Continuous Integration and completed the brief overview. Remaining part is Analysis of Jenkins for DevOps series is evaluation, outlook and conclusion.

This Article Has Been Shared 4369 Times!

Facebook Twitter Google+ Pinterest