You are previewing Jenkins: The Definitive Guide.

Jenkins: The Definitive Guide

Cover of Jenkins: The Definitive Guide by John Ferguson Smart Published by O'Reilly Media, Inc.
  1. Jenkins: The Definitive Guide
    1. SPECIAL OFFER: Upgrade this ebook with O’Reilly
    2. Foreword
    3. Preface
      1. Audience
      2. Book Layout
      3. Jenkins or Hudson?
      4. Font Conventions
      5. Command-Line Conventions
      6. Contributors
      7. The Review Team
      8. Book Sponsors
      9. Using Code Examples
      10. Safari® Books Online
      11. How to Contact Us
      12. Acknowledgments
    4. 1. Introducing Jenkins
      1. Introduction
      2. Continuous Integration Fundamentals
      3. Introducing Jenkins (née Hudson)
      4. From Hudson to Jenkins—A Short History
      5. Should I Use Jenkins or Hudson?
      6. Introducing Continuous Integration into Your Organization
      7. Where to Now?
    5. 2. Your First Steps with Jenkins
      1. Introduction
      2. Preparing Your Environment
      3. Starting Up Jenkins
      4. Configuring the Tools
      5. Your First Jenkins Build Job
      6. Your First Build Job in Action
      7. More Reporting—Displaying Javadocs
      8. Adding Code Coverage and Other Metrics
      9. Conclusion
    6. 3. Installing Jenkins
      1. Introduction
      2. Downloading and Installing Jenkins
      3. Preparing a Build Server for Jenkins
      4. The Jenkins Home Directory
      5. Installing Jenkins on Debian or Ubuntu
      6. Installing Jenkins on Redhat, Fedora, or CentOS
      7. Installing Jenkins on SUSE or OpenSUSE
      8. Running Jenkins as a Stand-Alone Application
      9. Running Jenkins Behind an Apache Server
      10. Running Jenkins on an Application Server
      11. Memory Considerations
      12. Installing Jenkins as a Windows Service
      13. What’s in the Jenkins Home Directory
      14. Backing Up Your Jenkins Data
      15. Upgrading Your Jenkins Installation
      16. Conclusion
    7. 4. Configuring Your Jenkins Server
      1. Introduction
      2. The Configuration Dashboard—The Manage Jenkins Screen
      3. Configuring the System Environment
      4. Configuring Global Properties
      5. Configuring Your JDKs
      6. Configuring Your Build Tools
      7. Configuring Your Version Control Tools
      8. Configuring the Mail Server
      9. Configuring a Proxy
      10. Conclusion
    8. 5. Setting Up Your Build Jobs
      1. Introduction
      2. Jenkins Build Jobs
      3. Creating a Freestyle Build Job
      4. Configuring Source Code Management
      5. Build Triggers
      6. Build Steps
      7. Post-Build Actions
      8. Running Your New Build Job
      9. Working with Maven Build Jobs
      10. Using Jenkins with Other Languages
      11. Conclusion
    9. 6. Automated Testing
      1. Introduction
      2. Automating Your Unit and Integration Tests
      3. Configuring Test Reports in Jenkins
      4. Displaying Test Results
      5. Ignoring Tests
      6. Code Coverage
      7. Automated Acceptance Tests
      8. Automated Performance Tests with JMeter
      9. Help! My Tests Are Too Slow!
      10. Conclusion
    10. 7. Securing Jenkins
      1. Introduction
      2. Activating Security in Jenkins
      3. Simple Security in Jenkins
      4. Security Realms—Identifying Jenkins Users
      5. Authorization—Who Can Do What
      6. Auditing—Keeping Track of User Actions
      7. Conclusion
    11. 8. Notification
      1. Introduction
      2. Email Notification
      3. More Advanced Email Notification
      4. Claiming Builds
      5. RSS Feeds
      6. Build Radiators
      7. Instant Messaging
      8. IRC Notification
      9. Desktop Notifiers
      10. Notification via Notifo
      11. Mobile Notification
      12. SMS Notification
      13. Making Noise
      14. Extreme Feedback Devices
      15. Conclusion
    12. 9. Code Quality
      1. Introduction
      2. Code Quality in Your Build Process
      3. Popular Java and Groovy Code Quality Analysis Tools
      4. Reporting on Code Quality Issues with the Violations Plugin
      5. Using the Checkstyle, PMD, and FindBugs Reports
      6. Reporting on Code Complexity
      7. Reporting on Open Tasks
      8. Integrating with Sonar
      9. Conclusion
    13. 10. Advanced Builds
      1. Introduction
      2. Parameterized Build Jobs
      3. Parameterized Triggers
      4. Multiconfiguration Build Jobs
      5. Generating Your Maven Build Jobs Automatically
      6. Coordinating Your Builds
      7. Build Pipelines and Promotions
      8. Conclusion
    14. 11. Distributed Builds
      1. Introduction
      2. The Jenkins Distributed Build Architecture
      3. Master/Slave Strategies in Jenkins
      4. Associating a Build Job with a Slave or Group of Slaves
      5. Node Monitoring
      6. Cloud Computing
      7. Using the CloudBees DEV@cloud Service
      8. Conclusion
    15. 12. Automated Deployment and Continuous Delivery
      1. Introduction
      2. Implementing Automated and Continuous Deployment
      3. Deploying to an Application Server
      4. Conclusion
    16. 13. Maintaining Jenkins
      1. Introduction
      2. Monitoring Disk Space
      3. Monitoring the Server Load
      4. Backing Up Your Configuration
      5. Archiving Build Jobs
      6. Migrating Build Jobs
      7. Conclusion
    17. A. Automating Your Unit and Integration Tests
      1. Automating Your Tests with Maven
      2. Automating Your Tests with Ant
    18. Index
    19. About the Author
    20. Colophon
    21. SPECIAL OFFER: Upgrade this ebook with O’Reilly

Continuous Integration Fundamentals

Back in the days of waterfall projects and Gantt charts, before the introduction of CI practices, development team time and energy was regularly drained in the period leading up to a release by what was known as the Integration Phase. During this phase, the code changes made by individual developers or small teams were brought together piecemeal and forged into a working product. This was hard work, sometimes involving the integration of months of conflicting changes. It was very hard to anticipate the types of issues that would crop up, and even harder to fix them, as it could involve reworking code that had been written weeks or months before. This painful process, fraught with risk and danger, often lead to significant delivery delays, unplanned costs and, as a result, unhappy clients. Continuous Integration was born to address these issues.

Continuous Integration, in its simplest form, involves a tool that monitors your version control system for changes. Whenever a change is detected, this tool automatically compiles and tests your application. If something goes wrong, the tool immediately notifies the developers so that they can fix the issue immediately.

But Continuous Integration can do much more than this. Continuous Integration can also help you keep tabs on the health of your code base, automatically monitoring code quality and code coverage metrics, and helping keep technical debt down and maintenance costs low. The publicly-visible code quality metrics can also encourage developers to take pride in the quality of their code and strive to improve it. Combined with automated end-to-end acceptance tests, CI can also act as a communication tool, publishing a clear picture of the current state of development efforts. And it can simplify and accelerate delivery by helping you automate the deployment process, letting you deploy the latest version of your application either automatically or as a one-click process.

In essence, Continuous Integration is about reducing risk by providing faster feedback. First and foremost, it is designed to help identify and fix integration and regression issues faster, resulting in smoother, quicker delivery, and fewer bugs. By providing better visibility for both technical and non-technical team members on the state of the project, Continuous Integration can open and facilitate communication channels between team members and encourage collaborative problem solving and process improvement. And, by automating the deployment process, Continuous Integration helps you get your software into the hands of the testers and the end users faster, more reliably, and with less effort.

This idea of automated deployment is important. Indeed, if you take automating the deployment process to its logical conclusion, you could push every build that passes the necessary automated tests into production. The practice of automatically deploying every successful build directly into production is generally known as Continuous Deployment.

However, a pure Continuous Deployment approach is not always appropriate for everyone. For example, many users would not appreciate new versions falling into their laps several times a week, and prefer a more predictable (and transparent) release cycle. Commercial and marketing considerations might also play a role in when a new release should actually be deployed.

The notion of Continuous Delivery is a slight variation on the idea of Continuous Deployment that takes into account these considerations. With Continuous Delivery, any and every successful build that has passed all the relevant automated tests and quality gates can potentially be deployed into production via a fully automated one-click process, and be in the hands of the end-user within minutes. However, the process is not automatic: it is the business, rather than IT, that decides the best time to deliver the latest changes.

So Continuous Integration techniques, and in particular Continuous Deployment and Continuous Delivery, are very much about providing value to the end user faster. How long does it take your team to get a small code change out to production? How much of this process involves problems that could have been fixed earlier, had you known about the code changes that Joe down the corridor was making? How much is taken up by labor-intensive manual testing by QA teams? How much involves manual deployment steps, the secrets of which are known only to a select few? CI is not a silver bullet by any means, but it can certainly help streamline many of these problems.

But Continuous Integration is a mindset as much as a toolset. To get the most out of CI, a team needs to adopt a CI mentality. For example, your projects must have a reliable, repeatable, and automated build process, involving no human intervention. Fixing broken builds should take an absolute priority, and not be left to stagnate. The deployment process should be automated, with no manual steps involved. And since the trust you place in your CI server depends to a great extent on the quality of your tests, the team needs to place a very strong emphasis on high quality tests and testing practices.

In this book we will be looking at how to implement a robust and comprehensive Continuous Integration solution using Jenkins or Hudson.

The best content for your career. Discover unlimited learning on demand for around $1/day.