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

Introducing Continuous Integration into Your Organization

Continuous Integration is not an all-or-nothing affair. In fact, introducing CI into an organization takes you on a path that progresses through several distinct phases. Each of these phases involves incremental improvements to the technical infrastructure as well as, perhaps more importantly, improvements in the practices and culture of the development team itself. In the following paragraphs, I have tried to paint an approximate picture of each phase.

Phase 1—No Build Server

Initially, the team has no central build server of any kind. Software is built manually on a developer’s machine, though it may use an Ant script or similar to do so. Source code may be stored in a central source code repository, but developers do not necessarily commit their changes on a regular basis. Some time before a release is scheduled, a developer manually integrates the changes, a process which is generally associated with pain and suffering.

Phase 2—Nightly Builds

In this phase, the team has a build server, and automated builds are scheduled on a regular (typically nightly) basis. This build simply compiles the code, as there are no reliable or repeatable unit tests. Indeed, automated tests, if they are written, are not a mandatory part of the build process, and may well not run correctly at all. However developers now commit their changes regularly, at least at the end of every day. If a developer commits code changes that conflict with another developer’s work, the build server alerts the team via email the following morning. Nevertheless, the team still tends to use the build server for information purposes only—they feel little obligation to fix a broken build immediately, and builds may stay broken on the build server for some time.

Phase 3—Nightly Builds and Basic Automated Tests

The team is now starting to take Continuous Integration and automated testing more seriously. The build server is configured to kick off a build whenever new code is committed to the version control system, and team members are able to easily see what changes in the source code triggered a particular build, and what issues these changes address. In addition, the build script compiles the application and runs a set of automated unit and/or integration tests. In addition to email, the build server also alerts team members of integration issues using more proactive channels such as Instant Messaging. Broken builds are now generally fixed quickly.

Phase 4—Enter the Metrics

Automated code quality and code coverage metrics are now run to help evaluate the quality of the code base and (to some extent, at least) the relevance and effectiveness of the tests. The code quality build also automatically generates API documentation for the application. All this helps teams keep the quality of the code base high, alerting team members if good testing practices are slipping. The team has also set up a “build radiator,” a dashboard view of the project status that is displayed on a prominent screen visible to all team members.

Phase 5—Getting More Serious About Testing

The benefits of Continuous Integration are closely related to solid testing practices. Now, practices like Test-Driven Development are more widely practiced, resulting in a growing confidence in the results of the automated builds. The application is no longer simply compiled and tested, but if the tests pass, it is automatically deployed to an application server for more comprehensive end-to-end tests and performance tests.

Phase 6—Automated Acceptance Tests and More Automated Deployment

Acceptance-Test Driven Development is practiced, guiding development efforts and providing high-level reporting on the state of the project. These automated tests use Behavior-Driven Development and Acceptance-Test Driven Development tools to act as communication and documentation tools and documentation as much as testing tools, publishing reports on test results in business terms that non-developers can understand. Since these high-level tests are automated at an early stage in the development process, they also provide a clear idea of what features have been implemented, and which remain to be done. The application is automatically deployed into test environments for testing by the QA team either as changes are committed, or on a nightly basis; a version can be deployed (or “promoted”) to UAT and possibly production environments using a manually-triggered build when testers consider it ready. The team is also capable of using the build server to back out a release, rolling back to a previous release, if something goes horribly wrong.

Phase 7—Continuous Deployment

Confidence in the automated unit, integration and acceptance tests is now such that teams can apply the automated deployment techniques developed in the previous phase to push out new changes directly into production.

The progression between levels here is of course somewhat approximate, and may not always match real-world situations. For example, you may well introduce automated web tests before integrating code quality and code coverage reporting. However, it should give a general idea of how implementing a Continuous Integration strategy in a real world organization generally works.

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