Jenkins is a Java-based Continuous Integration (CI) server that supports the discovery of defects early in the software cycle. Thanks to a rapidly growing number of plugins (currently over 1,000), Jenkins communicates with many types of systems, building and triggering a wide variety of tests.
CI involves making small changes to software and then building and applying quality assurance processes. Defects do not only occur in the code, but also appear in naming conventions, documentation, how the software is designed, build scripts, the process of deploying the software to servers, and so on. CI forces the defects to emerge early, rather than waiting for software to be fully produced. If defects are caught in the later stages of the software development life cycle, the process will be more expensive. The cost of repair radically increases as soon as the bugs escape to production. Estimates suggest it is 100 to 1,000 times cheaper to capture defects early. Effective use of a CI server, such as Jenkins, could be the difference between enjoying a holiday and working unplanned hours to heroically save the day. And as you can imagine, in my day job as a senior developer with aspirations for quality assurance, I like long boring days, at least for mission-critical production environments.
Jenkins can automate the building of software regularly and trigger tests pulling in the results and failing based on defined criteria. Failing early via build failure lowers the costs, increases confidence in the software produced, and has the potential to morph subjective processes into an aggressive metrics-based process that the development team feels is unbiased.
Jenkins is not just a CI server, it is also a vibrant and highly active community. Enlightened self-interest dictates participation. There are a number of ways to do this:
Participate in the mailing lists and Twitter (https://wiki.jenkins-ci.org/display/JENKINS/Mailing+Lists). First, read the postings and as you get to understand what is needed, then participate in the discussions. Consistently reading the lists will generate many opportunities to collaborate.
Improve code and write plugins (https://wiki.jenkins-ci.org/display/JENKINS/Help+Wanted).
Test Jenkins and especially the plugins and write bug reports, donating your test plans.
Improve documentation by writing tutorials and case studies.
Chapter 1, Maintaining Jenkins, describes common maintenance tasks such as backing up and monitoring. The recipes in this chapter outline methods for proper maintenance that in turn lowers the risk of failures.
Chapter 2, Enhancing Security, details how to secure Jenkins and the value of enabling single sign-on (SSO). This chapter covers many details, ranging from setting up basic security for Jenkins, deploying enterprise infrastructure such as a directory service, and a SSO solution to automatically test for the OWASP top 10 security.
Chapter 3, Building Software, reviews the relationship between Jenkins and Maven builds and a small amount of scripting with Groovy and Ant. The recipes include checking for license violations, controlling the creation of reports, running Groovy scripts, and plotting alternative metrics.
Chapter 4, Communicating Through Jenkins, reviews effective communication strategies for different target audiences from developers and project managers to the wider public. Jenkins is a talented communicator, with its hordes of plugins notifying you by e-mail, dashboards, and Google services. It shouts at you through mobile devices, radiates information as you walk pass big screens, and fires at you with USB sponge missile launchers.
Chapter 5, Using Metrics to Improve Quality, explores the use of source code metrics. To save money and improve quality, you need to remove defects in the software life cycle as early as possible. Jenkins test automation creates a safety net of measurements. The recipes in this chapter will help you build this safety net.
Chapter 6, Testing Remotely, details approaches to set up and run remote stress and functional tests. By the end of this chapter, you will have run performance and functional tests against a web application and web services. Two typical setup recipes are included. The first is the deployment of a WAR file through Jenkins to an application server. The second is the creation of multiple slave nodes, ready to move the hard work of testing away from the master node.
Chapter 7, Exploring Plugins, has two purposes. The first is to show a number of interesting plugins. The second is to review how plugins work.
Appendix, Processes that Improve Quality, discusses how the recipes in this book support quality processes and points to other relevant resources. This will help you form a coherent picture of how the recipes can support your quality processes.
This book assumes you have a running an instance of Jenkins.
In order to run the recipes provided in the book, you need to have the following software:
Recommended:
Maven 3 (http://maven.apache.org)
Jenkins (http://jenkins-ci.org/)
Java Version 1.8 (http://java.com/en/download/index.jsp)
Optional:
VirtualBox (https://www.virtualbox.org/)
SoapUI (http://www.soapui.org)
JMeter (http://jmeter.apache.org/)
Helpful:
A local subversion or Git repository
OS of preference: Linux (Ubuntu)
There are numerous ways to install Jenkins: as a Windows service, using the repository management features of Linux such as apt and yum, using Java Web Start, or running it directly from a WAR file. It is up to you to choose the approach that you feel is most comfortable. However, you can run Jenkins from a WAR file, using HTTPS from the command line, pointing to a custom directory. If any experiments go astray, then you can simply point to another directory and start fresh.
To use this approach, first set the JENKINS_HOME environment variable to the directory you wish Jenkins to run under. Next, run a command similar to the following command:
Java –jar jenkins.war –httpsPort=8443 –httpPort=-1
Jenkins will start to run over https on port 8443. The HTTP port is turned off by setting httpPort=-1 and the terminal will display logging information.
You can ask for help by executing the following command:
Java –jar jenkins.war –help
A wider range of installation instructions can be found at https://wiki.jenkins-ci.org/display/JENKINS/Installing+Jenkins.
For a more advanced recipe describing how to set up a virtual image under VirtualBox with Jenkins, you can use the Using a test Jenkins instance recipe in Chapter 1, Maintaining Jenkins.
This book is for Java developers, software architects, technical project managers, build managers, and development or QA engineers. A basic understanding of the software development life cycle, some elementary web development knowledge, and a familiarity with basic application server concepts are expected. A basic understanding of Jenkins is also assumed.
In this book, you will find several headings that appear frequently (Getting ready, How to do it, How it works, There's more, and See also).
To give clear instructions on how to complete a recipe, we use these sections as follows.
This section tells you what to expect in the recipe, and describes how to set up any software or any preliminary settings required for the recipe.
This section usually consists of a detailed explanation of what happened in the previous section.
This section consists of additional information about the recipe in order to make the reader more knowledgeable about the recipe.
In this book, you will find a number of text styles that distinguish between different kinds of information. Here are some examples of these styles and an explanation of their meaning.
Code words in text, database table names, folder names, filenames, file extensions, pathnames, dummy URLs, user input, and Twitter handles are shown as follows: "The job-specific configuration is then stored in config.xml within the subdirectory."
A block of code is set as follows:
<?xml version='1.0' encoding='UTF-8'?> <org.jvnet.hudson.plugins.thinbackup.ThinBackupPluginImpl plugin="[email protected]"> <fullBackupSchedule>1 0 * * 7</fullBackupSchedule> <diffBackupSchedule>1 1 * * *</diffBackupSchedule> <backupPath>/data/jenkins/backups</backupPath> <nrMaxStoredFull>61</nrMaxStoredFull> <excludedFilesRegex></excludedFilesRegex> <waitForIdle>false</waitForIdle> <forceQuietModeTimeout>120</forceQuietModeTimeout> <cleanupDiff>true</cleanupDiff> <moveOldBackupsToZipFile>true</moveOldBackupsToZipFile> <backupBuildResults>true</backupBuildResults> <backupBuildArchive>true</backupBuildArchive> <backupUserContents>true</backupUserContents> <backupNextBuildNumber>true</backupNextBuildNumber> <backupBuildsToKeepOnly>true</backupBuildsToKeepOnly> </org.jvnet.hudson.plugins.thinbackup.ThinBackupPluginImpl>
When we wish to draw your attention to a particular part of a code block, the relevant lines or items are set in bold:
server {
listen 80;
server_name localhost;
access_log /var/log/nginx/jenkins _8080_proxypass_access.log;
error_log /var/log/nginx/jenkins_8080_proxypass_access.log;
location / {
proxy_pass http://127.0.0.1:7070/;
include /etc/nginx/proxy.conf;
}
}Any command-line input or output is written as follows:
sudo apt-get install jenkins
New terms and important words are shown in bold. Words that you see on the screen, for example, in menus or dialog boxes, appear in the text like this: "Click on Save."
Feedback from our readers is always welcome. Let us know what you think about this book—what you liked or disliked. Reader feedback is important for us as it helps us develop titles that you will really get the most out of.
To send us general feedback, simply e-mail <[email protected]>, and mention the book's title in the subject of your message.
If there is a topic that you have expertise in and you are interested in either writing or contributing to a book, see our author guide at www.packtpub.com/authors.
Now that you are the proud owner of a Packt book, we have a number of things to help you to get the most from your purchase.
You can download the example code files from your account at http://www.packtpub.com for all the Packt Publishing books you have purchased. If you purchased this book elsewhere, you can visit http://www.packtpub.com/support and register to have the files e-mailed directly to you.
Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you find a mistake in one of our books—maybe a mistake in the text or the code—we would be grateful if you could report this to us. By doing so, you can save other readers from frustration and help us improve subsequent versions of this book. If you find any errata, please report them by visiting http://www.packtpub.com/submit-errata, selecting your book, clicking on the Errata Submission Form link, and entering the details of your errata. Once your errata are verified, your submission will be accepted and the errata will be uploaded to our website or added to any list of existing errata under the Errata section of that title.
To view the previously submitted errata, go to https://www.packtpub.com/books/content/support and enter the name of the book in the search field. The required information will appear under the Errata section.
Piracy of copyrighted material on the Internet is an ongoing problem across all media. At Packt, we take the protection of our copyright and licenses very seriously. If you come across any illegal copies of our works in any form on the Internet, please provide us with the location address or website name immediately so that we can pursue a remedy.
Please contact us at <[email protected]> with a link to the suspected pirated material.
We appreciate your help in protecting our authors and our ability to bring you valuable content.
If you have a problem with any aspect of this book, you can contact us at <[email protected]>, and we will do our best to address the problem.