The venerable open source build tool trusted by companies large and small
November 13, 2017

The venerable open source build tool trusted by companies large and small

Jonathan Yu | TrustRadius Reviewer
Score 8 out of 10
Vetted Review
Verified User

Overall Satisfaction with Jenkins

I used Jenkins to manage both development and release builds of software at my two previous roles (IBM and Red Hat.) In both cases, each department had its own instances, so that plugins could be customized and managed on a per-team, per-product basis. It enables teams to manage a fleet of build servers (slaves in Jenkins parlance) that can build source code and run tests in an automated fashion, across platforms - this enables cross-platform software to be tested against various versions of Windows and Linux, for example. It can also be used for simple automation tasks, though other tools like Ansible are better suited for those tasks.
  • Minimal but extensible and flexible: Out of the box, Jenkins provides rudimentary capabilities to manage a host system with a framework for running build tasks and installing tools. There are many extension points available for plugins, and so a rich ecosystem of plugins is available. Many version control systems are supported, and integrations with other tools through plugins is excellent.
  • Cross-platform: Supports many platforms and architectures quite easily, thanks to its implementation in Java
  • Design focus: With Blue Ocean, you can get a nice-looking web interface for free
  • Rich ecosystem: As Jenkins has been around for quite some time, there is a rich ecosystem of blogs, tutorials, guides, and documentation available for performing most of the day-to-day tasks you would need. There are also various vendors like CloudBees that offer hosted services.
  • Ease of deployment: Jenkins can be deployed quite easily as a standalone JAR file. There are also system packages available for many Linux operating systems, such as Debian.
  • Difficult to manage build configurations: builds are generally configured through the user interface, which is easier to modify (especially for casual users rather than dedicated release engineers), but this results in changes that can be difficult to track, especially if multiple people have write access to the system. Some teams manage this by restricting people that can modify builds, but this creates a bottleneck. Ideally, the system would provide a good audit trail and change history, allowing changes to be tracked and reverted easily. Competing offerings get around this by version-controlling their configuration (e.g. Travis CI, Drone, AppVeyor) but this results in a slightly higher learning curve.
  • Quality of plugins varies widely: plugins are in various states of maintenance, and some are woefully incomplete and no longer updated. It can be difficult to know whether a plugin is well-written or not, or even actively maintained.
  • Builds are often not easily reproducible: By default, builds are run on the slave systems, which can retain state between runs that cause difficult-to-debug failures. It's possible to get around this by using VM snapshots and periodically reverting to clean systems, or by using the Docker plugin to run builds inside ephemeral containers.
  • Plugins are globally scoped: Because plugin versions and the Jenkins version are per-installation, companies with multiple teams typically run multiple instances of Jenkins. This leads to a maintenance nightmare and a lot of duplicated effort across teams keeping the systems patched, but is necessary because software requires different toolchains. It would be nice if Jenkins supported plugins on a "per tenant" basis, even though the running version would still be one-per-instance. Some platforms (such as OpenShift) get around this by running Jenkins inside a container, but that leaves out Windows slaves.
  • Low investment: As the software is open source, there is no purchase required for on-premises installations, and there is a low barrier to entry for companies offering hosted solutions. This leads to competition on price, and therefore lower prices.
  • Saves time by automating manual tasks: There are often a lot of repetitive tasks that need to be done to prepare for a release, and Jenkins enables these tasks to be run easily and frequently (for example, running tasks on every pull request)
  • Near-immediate returns: Spend a day or two and easily automate most common tasks. Reports are visible so that managers and team leads can keep an eye on code quality.
Travis CI and AppVeyor are good services that provide rudimentary support for builds, but they focus on Linux/OSX and Windows respectively, meaning that cross-platform builds will need to use both services. They are free for open source projects on GitHub, so they are seen quite frequently in the wild. They're easy to use and do a great job for simple projects, but have limitations that quickly become apparent for larger projects. Out-of-the-box, there's a limited ecosystem of tools available on these systems, though for Linux builds on Travis, builds can be run inside a Docker container, yielding greater flexibility and reproducibility. Docker and Drone are great alternatives that are container-native technologies but they are Linux only.
Jenkins works pretty well for what it does, is easy to use, and aggregates logs as you would expect. For simple builds (especially Java builds), Jenkins works fairly well. It can run on full systems or headless systems, so tests requiring a graphical interface (such as those driven by Selenium and the WebDriver API) have no issues running. It can be used to manage systems to some extent (installing and managing software across a cluster by SSHing into slave machines) but its ecosystem is not geared for that; for a general automation solution, look to Ansible instead.