We just raised a $30M Series A: Read our story

Jenkins OverviewUNIXBusinessApplication

Jenkins is the #2 ranked solution in our list of top Build Automation tools. It is most often compared to Tekton: Jenkins vs Tekton

What is Jenkins?

Jenkins is an award-winning application that monitors executions of repeated jobs, such as building a software project or jobs run by cron.

Jenkins Buyer's Guide

Download the Jenkins Buyer's Guide including reviews and more. Updated: October 2021

Jenkins Customers

Airial, Clarus Financial Technology, cubetutor, Metawidget, mysocio, namma, silverpeas, Sokkva, So Rave, tagzbox

Jenkins Video

Archived Jenkins Reviews (more than two years old)

Filter by:
Filter Reviews
Industry
Loading...
Filter Unavailable
Company Size
Loading...
Filter Unavailable
Job Level
Loading...
Filter Unavailable
Rating
Loading...
Filter Unavailable
Considered
Loading...
Filter Unavailable
Order by:
Loading...
  • Date
  • Highest Rating
  • Lowest Rating
  • Review Length
Search:
Showingreviews based on the current filters. Reset all filters
PauloBorges
Senior IT Professional at Novabase
Real User
Fully integrates with many other solutions for more effective ALM

What is our primary use case?

We use this solution for Build & Deploy Automation. It is integrated with Git or TFS, Nexus and Ansible for deploying to premises servers in Linux or Windows.

How has it helped my organization?

This solution provides us more effective ALM and deployment automation compared to the previous solution with Serena (now Micro Focus) Dimensions CM.

What is most valuable?

The most valuable features are Jenkins Pipelines for ALM and full Deploy Cycle. This solution fully integrates with a lot of other solutions like Git, TFS, Nexus, SonarQube, etc.

What needs improvement?

I would like to have more Steps commands for better integration with other platforms. Better and easy-to-use integration with Docker would be an improvement.

For how long have I used

What is our primary use case?

We use this solution for Build & Deploy Automation. It is integrated with Git or TFS, Nexus and Ansible for deploying to premises servers in Linux or Windows.

How has it helped my organization?

This solution provides us more effective ALM and deployment automation compared to the previous solution with Serena (now Micro Focus) Dimensions CM.

What is most valuable?

The most valuable features are Jenkins Pipelines for ALM and full Deploy Cycle. This solution fully integrates with a lot of other solutions like Git, TFS, Nexus, SonarQube, etc.

What needs improvement?

I would like to have more Steps commands for better integration with other platforms.

Better and easy-to-use integration with Docker would be an improvement.

For how long have I used the solution?

I have been using this solution for three years.
Disclosure: I am a real user, and this review is based on my own experience and opinions.
WA
Managing Director at Technocure
Real User
Valuable plugins and automation, but the upgrades need improvement

What is our primary use case?

We use this solution for continuous integration and deployment, using Groovy Script for pipeline node configuration.

How has it helped my organization?

This solution has helped us in automating the build and test process, reducing time.

What is most valuable?

The most valuable features are plugins that make my server highly available.

What needs improvement?

The upgrades need improvement.

For how long have I used the solution?

Three years.

What is our primary use case?

We use this solution for continuous integration and deployment, using Groovy Script for pipeline node configuration.

How has it helped my organization?

This solution has helped us in automating the build and test process, reducing time.

What is most valuable?

The most valuable features are plugins that make my server highly available.

What needs improvement?

The upgrades need improvement.

For how long have I used the solution?

Three years.
Disclosure: I am a real user, and this review is based on my own experience and opinions.
Learn what your peers think about Jenkins. Get advice and tips from experienced pros sharing their opinions. Updated: October 2021.
542,029 professionals have used our research since 2012.
FH
Software Quality Assurance Team Lead with 11-50 employees
Vendor
Useful for us to collect and manage automatic processing pipelines

Pros and Cons

  • "It is very useful for us to be able to collect and manage automatic processing pipelines."
  • "The learning curve is quite steep at the moment."

What is our primary use case?

Jenkins is part of our test infrastructure. We organize the test execution mainly of our performance tests, based on JMeter.

Second, the deployment of release candidates in our test infrastructure is managed using Jenkins.

In the future, we want to use Jenkins more in the field of continuous integration and continuous deployment.

How has it helped my organization?

For test automation, Jenkins seems to be our main and central solution at the moment. We want to extend this in the future towards Jenkins pipelines, which can be very useful for having a more dynamic test infrastructure.

What is most valuable?

Currently, using Jenkins for automatic testing is the most valuable feature for us.

It is very useful for us to be able to collect and manage automatic processing pipelines.

What needs improvement?

We have issues with the following points:

  • The usability and user interface could be improved.
  • Clearer feedback for problems and errors would be useful.
  • The learning curve is quite steep at the moment.
  • Our security policy does not allow normal users to introduce additional modules. A simpler way of extending the basic functionality would be nice.

For how long have I used the solution?

One year.

What do I think about the stability of the solution?

When there is enough disk space and RAM, the solution is stable.

What do I think about the scalability of the solution?

Scalability is not an issue for us.

How are customer service and technical support?

There is a large open source community where you can find a lot of workarounds and solutions when you have a problem.

Which solution did I use previously and why did I switch?

We did not use another solution previously.

How was the initial setup?

The setup is straightforward.

What about the implementation team?

Our in-house SysOps team managed to install Jenkins.

What's my experience with pricing, setup cost, and licensing?

Jenkins is open source and free.

Which other solutions did I evaluate?

We also evaluated Bamboo but decided to go with Jenkins because it is open source and free.

What other advice do I have?

We recommend having the proper infrastructure, and to ensure the maintenance of the server is performed.

Disclosure: I am a real user, and this review is based on my own experience and opinions.
OU
Software Test Automation Engineer at Colpatria
Real User
The ability to connect with multiple tools and technologies has helped us increase productivity

What is our primary use case?

This is our CD solution for Java APIs and Microsites.

How has it helped my organization?

This solution automates the deployment process and therefore increases productivity.

What is most valuable?

The most valuable feature is its ability to connect with different tools and technologies.

What needs improvement?

This solution would be improved with the inclusion of an Artifactory (Universal artifact repository manager).

For how long have I used the solution?

Five years.

What is our primary use case?

This is our CD solution for Java APIs and Microsites.

How has it helped my organization?

This solution automates the deployment process and therefore increases productivity.

What is most valuable?

The most valuable feature is its ability to connect with different tools and technologies.

What needs improvement?

This solution would be improved with the inclusion of an Artifactory (Universal artifact repository manager).

For how long have I used the solution?

Five years.
Disclosure: I am a real user, and this review is based on my own experience and opinions.
OG
Lider de Diseño y Arquitectura de Soluciones with 11-50 employees
Real User
Enables us to automate many procedures like code review, testing, and deployment

What is our primary use case?

This solution is the primary component for our automatic release process, including code smell, integration, and deployment.

How has it helped my organization?

This solution has provided us with better quality and less time to market for our software products. We can also automate many procedures like code review, testing, and deployment.

What is most valuable?

There are a large number of plugins available for integration with third party systems.

What needs improvement?

The user interface could be updated a little. I think that a REST API is needed to expand the integration capabilities.

For how long have I used the solution?

One to three years.

What is our primary use case?

This solution is the primary component for our automatic release process, including code smell, integration, and deployment.

How has it helped my organization?

This solution has provided us with better quality and less time to market for our software products. We can also automate many procedures like code review, testing, and deployment.

What is most valuable?

There are a large number of plugins available for integration with third party systems.

What needs improvement?

The user interface could be updated a little. I think that a REST API is needed to expand the integration capabilities.

For how long have I used the solution?

One to three years.
Disclosure: I am a real user, and this review is based on my own experience and opinions.
Ujjwal Gupta
Senior Technical Consultant at Adobe
Real User
Leaderboard
Your True Friend when you're out (CI/CD)

What is our primary use case?

I use Jenkins for Continous Integration or Continous Deployment to run test case execution in Nightly build atmosphere. Integrating test scripts to Jenkins is easier and it can run based on the frequency mentioned in settings.

How has it helped my organization?

Jenkins has helped us in executing our test scripts without the Dev team during night time.  It automatically fetches the latest build or codes and execute all your test scripts and share the report with the respective team and stakeholders.

What is most valuable?

I have found the following features extremely helpful.

  • It is open source & user-friendly.
  • It can deploy code instantly & generate test reports. The requirements for continuous integration and continuous deployment can be configured manually.
  • Integration work is automated.
  • It can be integrated with other major tools.

What needs improvement?

They should improve the Version Control tracking system in Jenkins.

For how long have I used the solution?

Three to five years.
Disclosure: I am a real user, and this review is based on my own experience and opinions.
it_user867459
dev app engineer
Real User
Incorporated with the code, we don't need a UI to design the build process

What is our primary use case?

We use it for build.

How has it helped my organization?

It improves our process because it's incorporated with the code. We don't need a UI to design the build process. It's like code for building.

What is most valuable?

Pipeline.

What needs improvement?

I think we have everything we need in Jenkins, really we're content with what we have in it. If I had to name something, I'd like to see more on the cloud, cloud integration, like to Amazon and  Google. I'd like to see more plugins for those.

What is our primary use case?

We use it for build.

How has it helped my organization?

It improves our process because it's incorporated with the code. We don't need a UI to design the build process. It's like code for building.

What is most valuable?

Pipeline.

What needs improvement?

I think we have everything we need in Jenkins, really we're content with what we have in it. If I had to name something, I'd like to see more on the cloud, cloud integration, like to Amazon and  Google. I'd like to see more plugins for those.

Disclosure: I am a real user, and this review is based on my own experience and opinions.
ITCS user
Senior Automation Test Developer/Automation Test Architect at a computer software company with 51-200 employees
Real User
My experience with Jenkins and TeamCity for CI

What is our primary use case?

- Run automated tests with release pipeline.

- Run tests against different environment.

- Manage selenium grid.

- Integrate with slack, browserstack and AWS.

How has it helped my organization?

CI tools such Jenkins and TeamCity, totally helps our release and tests. It saves our money, time and labour cost. And make release/delivery of the our product more visible. It drives the development team and other departments’s ambition.

What is most valuable?

Jenkins: pipeline/delivery pipeline and we can use shell script in the configuration. Jenkins has a lot of plugins.

TeamCity: We can run automaton tests.

What needs improvement?

For Jenkins: It needs to have less bugs. I do not how they test the plugins, but sometimes, the plugins have issues. I have no time to check where to report the issue.

For TeamCity: It need to be cheaper.

For how long have I used the solution?

More than five years.

What do I think about the stability of the solution?

For automation tests, Jenkins nodes some times experience instability. I have no better solution yet, since I have concerns with the networking and firewall as well.

What do I think about the scalability of the solution?

I do not know if it is scalability problem or not. In one Jenkins instance, we had many jobs and we created so many views, it is not easy to find them.

How are customer service and technical support?

Customer Service:

I have never used them.

Technical Support:

I have never used them.

Which solution did I use previously and why did I switch?

I prefer to use Jenkins more, because I have used it for a long time and am familiar with it. To me, TeamCity is OK too, but it is not free as Jenkins is. We need to consider the budget, so Jenkins finally won our development’s heart.

How was the initial setup?

I experienced the development switch from TeamCity to Jenkins, and I do not know the exact reason. My current company switched from Jenkins to circleCI.

What about the implementation team?

When I moved automation tests from TeamCity to Jenkins, I did not experience any difficulties, but I have learning curve for circleCI.

Which other solutions did I evaluate?

We use AWS codepipeline + jenkins.

Before using jenkins + AWS, we used CircleCI.

What other advice do I have?

We use the Groovy language to maintain the Jenkins job configurations which is very convenient. I do not know if we can do that to team city or not, I have not had a chance to try yet. I love Jenkins more without considering budget and the technology trend.

Disclosure: I am a real user, and this review is based on my own experience and opinions.
Axblade
Software Engineer at a tech services company with 11-50 employees
Real User
Significantly reduces build times, automates frequent manual tasks, reduces errors

Pros and Cons

  • "Having builds and test tasks triggered on commit helps not to break the product."
  • "We significantly reduced build times of large projects (more than 80k lines of Scala code) using build time on Jenkins as a time sample. It reduced the developer write-test-commit cycle time, and increased productivity."
  • "We have started to integrate Pipelines as a part of a build, and built a library of common functions. It simplified and made our build scripts more readable."
  • "Automation of chores like deployment, frequent manual tasks (like running scripts on test and production systems) reduced the time used and the number of errors made by engineers, freeing them to do meaningful work instead."
  • "Jenkins relies on the old version of interface for configuration management. This needs improvement."
  • "Developer documentation for plugins, plugin development, integrations: Sometimes it’s tricky to do pretty obvious things."
  • "Sometimes you have Jenkins restarting because of OOM errors."

How has it helped my organization?

Most obvious: Having builds and test tasks triggered on commit helps not to break the product.

From my own experience:

We significantly reduced build times of large projects (more than 80k lines of Scala code) using build time on Jenkins as a time sample. It reduced the developer write-test-commit cycle time, and increased productivity.

Integration with GitLab reduced time used for code reviews. Jenkins posted build state and code quality reports into the merge request.

Simplified build scripts: Organisation started to integrate Pipelines as a part of a build, and built a library of common functions. It simplified and made our build scripts more readable. 

Automation of chores like deployment, frequent manual tasks (like running scripts on test and production systems) reduced the time used and the number of errors made by engineers, freeing them to do meaningful work instead.

What is most valuable?

  • Configuration management: It is so easy to configure a Jenkins instance. Migrate configuration to a new environment just by copying XML files and setting up new nodes.
  • Programmable pipelines: In recent versions, Jenkins has a Groovy Sandbox where build scripts execute. I have never seen that powerful a tool in CI solutions yet. On other platforms you can use shell scripts, but Jenkins' solution is much better in terms of readability and portability. And given that you can create your own libraries for the Jenkins Pipelines, it becomes much more powerful and DRYer, simplifying work of DevOps and build engineers.
  • Brand new Blue Ocean UI: Jenkins used to have a pretty outdated UI. Now, you can use the Blue Ocean plugin to make it nice, clean, and modern-looking. Also, it has very good integration with Pipelines (basically it is built to use Pipelines).

What needs improvement?

UI: Jenkins relies on the old version of interface for configuration management.

Developer documentation for plugins, plugin development, integrations: Sometimes it’s tricky to do pretty obvious things.

For how long have I used the solution?

Three to five years.

What do I think about the stability of the solution?

Rarely. I can remember only one time we lost our build info after upgrading Jenkins, somewhere around the 1.6xx versions.

Sometimes you have Jenkins restarting because of OOM errors.

What do I think about the scalability of the solution?

No scalability issues. I used to have up to five worker nodes with one master, and it did not produce any slowdowns. I have never had bigger deployments.

How are customer service and technical support?

I have never used technical support directly. The community, documentation, issue tracker, are pretty good, though not ideal.

Which solution did I use previously and why did I switch?

TeamCity - It’s pretty limited in build runners, mostly targeting enterprise tech (Java, MS Stack, mobile apps) and the price is quite high.

Buildkite - An okay solution, but builds are shell scripts in general. It’s hard to maintain them. Also, I had weird issues with SCM integrations and Github.

GitLab CI - It’s coupled with GitLab too tightly. It’s pretty difficult to configure. It’s slow and requires a lot of resources to run.

How was the initial setup?

As for me, I just start to use it. It runs builds, unless you need something more complicated.

Setup of commonly used plugins is very straightforward, but it can be more difficult to get it running with exotic technologies. Still, it’s much easier than with other solutions.

What's my experience with pricing, setup cost, and licensing?

I used the free OSS version all the time. It was enough for all my needs.

Which other solutions did I evaluate?

I was always choosing between Jenkins, TeamCity, Buildkite, and Bamboo. Most recently, hosted solutions like Codeship and Travis CI added to the list.

For business needs, Jenkins is the most relevant choice because it can be self-hosted, the price is good, it’s robust, and requires almost no effort for maintenance.

For open source projects, Travis CI is standard.

What other advice do I have?

I like it very much, and I'm actively promoting it on my network.

Take your time to get used to the management flows of the application and builds. Jenkins is very powerful when you know how to cook it.

Disclosure: I am a real user, and this review is based on my own experience and opinions.
ITCS user
System Administrator at a marketing services firm with 51-200 employees
Vendor
Customization and the ability to automate processes from end-to-end are valuable

How has it helped my organization?

It's more structured, using naming conventions.

What is most valuable?

Customization Automation It's very useful when you want to automate different processes from beginning to end.

What needs improvement?

Maybe centralized user management. (We are not using all the functionalities of the product).

For how long have I used the solution?

Three to five years.

What do I think about the stability of the solution?

I would say it's a quite stable system.

What do I think about the scalability of the solution?

As I mentioned, we are not using all the feature of it, so it's very easy to scale it.

How are customer service and technical support?

It's free software with a big community behind it, which is very good.

Which solution did

How has it helped my organization?

It's more structured, using naming conventions.

What is most valuable?

  • Customization
  • Automation

It's very useful when you want to automate different processes from beginning to end.

What needs improvement?

Maybe centralized user management. (We are not using all the functionalities of the product).

For how long have I used the solution?

Three to five years.

What do I think about the stability of the solution?

I would say it's a quite stable system.

What do I think about the scalability of the solution?

As I mentioned, we are not using all the feature of it, so it's very easy to scale it.

How are customer service and technical support?

It's free software with a big community behind it, which is very good.

Which solution did I use previously and why did I switch?

No previous solution.

How was the initial setup?

It's pretty straightforward. Use apt-get to install Jenkins, and then there is just some minor configuration work.

What's my experience with pricing, setup cost, and licensing?

Some of the add-ons are too expensive.

Which other solutions did I evaluate?

No. When I started, Jenkins was broadly used.

What other advice do I have?

Start with Jenkins as your first CI solution.

Disclosure: I am a real user, and this review is based on my own experience and opinions.
ITCS user
QA Automation Engineer at a tech services company with 1,001-5,000 employees
Real User
Nice functionality, but does not have a very user-friendly interface

Pros and Cons

  • "We used it for all continuous integration parts, like automation testing, deployment, etc."
  • "It does not have a very user-friendly interface."

How has it helped my organization?

We used it for all continuous integration parts, like automation testing, deployment, etc.

What is most valuable?

In Jenkins v.2, the most useful feature is the Pipeline plugin. The reason why I think so is that you can build your own workflow with Groove and the plugin has many useful features like parallel executing, running commands, etc. and even imagine implementing your own features on Groove.

What needs improvement?

The interface.

For how long have I used the solution?

One to three years.

What do I think about the stability of the solution?

Yes, in Jenkins v.2. However, I am guessing that is because we used it right after the first release.

What do I think about the scalability of the solution?

In my opinion, there is an issue with the scalability. After Jenkins has big count of jobs, it begins to lose performance and you need to start one more server with a separate Jenkins and migrate some jobs there.

How are customer service and technical support?

It was enough for me.

Which solution did I use previously and why did I switch?

No, I did not.

How was the initial setup?

As I remember, there was just one command on Linux. Pretty easy.

What's my experience with pricing, setup cost, and licensing?

It is free.

Which other solutions did I evaluate?

I didn't choose, but in my opinion, this is the best open source solution for CI and CD.

What other advice do I have?

Nice functionality, but does not have a very user-friendly interface.

Disclosure: I am a real user, and this review is based on my own experience and opinions.
Bibhu Ashis Jena
Software Engineer at a retailer with 10,001+ employees
Real User
Facilitates Continuous Integration with almost any systems used for app development

Pros and Cons

  • "Continuous Integration. Jenkins can integrate with almost any systems used for application development and testing, with its plugins."
  • "Upgrading and maintaining plugins can be painful, as sometimes upgrading a plugin can break functionality of another plugin that a job is dependent on."

What is most valuable?

  • Continuous Integration. Jenkins can integrate with almost any systems used for application development and testing, with its plugins. 
  • It is open source and can be hosted on-premise. 
  • Because of its wide usage and support forums, one can easily find solutions to any issues they might face.

How has it helped my organization?

Jenkins has helped make teams more independent. For example, if a developer wants to check if the changes they are working on have any performance impact on their application, they would typically ask the performance engineer to do load tests before and after the change. This might be difficult to accomplish every time, based on the performance engineer's bandwidth. But with help of Jenkins, the performance engineer can create a job, one time, which the developer or anyone else can run anytime, as per their requirement.

What needs improvement?

Upgrading and maintaining plugins can be painful, as sometimes upgrading a plugin can break functionality of another plugin that a job is dependent on.

For how long have I used the solution?

One to three years.

What do I think about the stability of the solution?

No issues.

What do I think about the scalability of the solution?

No issues.

How are customer service and technical support?

Excellent.

Which solution did I use previously and why did I switch?

No previous solution.

How was the initial setup?

The initial setup is straightforward. It can be easily downloaded and installed from the Jenkins website. New plugins can also be added easily, based on the requirement.

What's my experience with pricing, setup cost, and licensing?

Jenkins is open source.

Which other solutions did I evaluate?

We explored other open source CI tools like Travis CI and CircleCI.

What other advice do I have?

Jenkins is a great tool for continuous integration. It has a wide variety of plugins to support anything from development to automation, performance testing, security testing, and many more. It also has the best support and documentation. If one is ready to spend dedicated resources on proper access control and plugin management, Jenkins can easily be the tool of choice for CI.

Disclosure: I am a real user, and this review is based on my own experience and opinions.
it_user781395
Continuous Integration Engineer 
Real User
Enables continuous build and testing, and distributed execution of build and test jobs

Pros and Cons

  • "Distributed execution of build and test jobs."
  • "The documentation on plugin development could be better: more examples. ​"

What is most valuable?

  • Continuous build and testing
  • Distributed execution of build and test jobs

It is essential for software development and team collaboration. Without this tool, we would be helpless.

How has it helped my organization?

Immediate feedback on build errors, regression.

What needs improvement?

Pipelines are still young and promising. But this part still has some room for improvement.

The documentation on plugin development could be better: more examples. 

For how long have I used the solution?

More than five years.

What do I think about the stability of the solution?

Sometimes, out-of-memory problems, but lately this has not occurred often. Sometimes there are obscure Java errors which are hard to understand.

What do I think about the scalability of the solution?

No issues.

How are customer service and technical support?

If there is a problem, I usually find the solution in the community. It is a large community and that helps a lot. Also, there are very valuable conferences.

Which solution did I use previously and why did I switch?

I used CruiseControl but this died.

How was the initial setup?

Very easy setup which has even improved over the years. Now I use Docker. Installation of plugins is also very easy.

What's my experience with pricing, setup cost, and licensing?

It is a free product.

Which other solutions did I evaluate?

BuildBot and CruiseControl.

What other advice do I have?

Don't forget to look into the plugins. It's not only Jenkins but also the plugins which make it a very valuable product.

Disclosure: I am a real user, and this review is based on my own experience and opinions.
ITCS user
Senior Automation Test Developer/Automation Test Architect at a computer software company with 51-200 employees
Real User
It makes the release faster by adding an automated deploy and automation tests

Pros and Cons

  • "Different types of jobs, such as Pipeline, Build, Freestyle, Maven, etc."
  • "The bug fix speed is very slow."

What is most valuable?

  1. CD/CI pipeline
  2. Different types of jobs, such as Pipeline, Build, Freestyle, Maven, etc.
  3. DSL: Groovy for complicated pipeline flow.
  4. Tons of plugins
  5. Is able to integrate with other systems.
  6. Free
  7. Easy to use Jenkins Docker.

How has it helped my organization?

It improves our release. It makes the release faster by adding an automated deploy and automation tests.

What needs improvement?

The bug fix speed is very slow.

For how long have I used the solution?

More than six years.

What do I think about the stability of the solution?

Some plugins have critical bugs and are not able to be used.

What do I think about the scalability of the solution?

Most of time, Jenkins is works well. But when you scale up, you need an administrator to manage Jenkins.

How are customer service and technical support?

You need an internal admin for Jenkins.

Which solution did I use previously and why did I switch?

CircleCI and TeamCity. CircleCI is not strong at release pipelines. TeamCity is not free.

How was the initial setup?

I feel it is pretty easy to set up Docker in my local computer. 

I do not have experience installing Jenkins on the company-wide used server yet, because I am not an Ops/Admin. I am a user of Jenkins.

Which other solutions did I evaluate?

Yes. CircleCI and TeamCity.

What other advice do I have?

It meets most of my requirements, such as CI/CD pipeline and an automated test execution. Even if there are some issues in Jenkins and its plugins, Jenkins provides the workaround ability to us. Other CI/CD system are not flexible like Jenkins yet. Also Jenkins provides an API, which you can integrate easily into your application.

When you have more jobs in Jenkins, find an admin to manage the user, queues, jobs, slaves, etc.

I highly recommend Jenkins. It is my favourite CI/CD system.

Disclosure: I am a real user, and this review is based on my own experience and opinions.
Arwan Ahmad Khoiruddin
Software Tester at a tech vendor
Real User
Enables us to automatically build Python binaries into several operating systems

Pros and Cons

  • "We use Jenkins to automatically build Python binaries into several OS's i.e. OS X, Ubuntu, Windows 32-bit and Windows 64-bit."
  • "In our case, we have several products built using Jenkins. It is quite difficult to navigate into the latest stable build in a given OS."

What is most valuable?

We use Jenkins to automatically build Python binaries into several OS's i.e. OS X, Ubuntu, Windows 32-bit and Windows 64-bit.

How has it helped my organization?

We are a company run by remote workers. Using Jenkins really helps us in moving our products forward into a number of different customer segments.

What needs improvement?

I think the UI and the UX can be improved. In our case, we have several products built using Jenkins. It is quite difficult to navigate into the latest stable build in a given OS.

For how long have I used the solution?

Two years.

What do I think about the stability of the solution?

No stability issues.

What do I think about the scalability of the solution?

No scalability issues. As long as the configuration is set correctly, there is nothing difficult in scaling up.

How are customer service and technical support?

Jenkins is a free and open source application. So, StackOverflow is more than enough for us.

Which solution did I use previously and why did I switch?

From the very beginning, we wanted to target OS X, Ubuntu and Windows users. At first, the developer would manually create some builds and put them in Gdrive to be tested. We started to use Jenkins when we had some multiple developers and testers and needed a system to manage and automatically build our products.

How was the initial setup?

In my company, my role is a software tester. I don't know whether the setup is difficult or not.

Which other solutions did I evaluate?

We went directly to Jenkins.

What other advice do I have?

Don't focus on the fact that Jenkins is open source. It is tough as a rock.

This software is ideal for you who work in software development especially those using Agile methodology.

Disclosure: I am a real user, and this review is based on my own experience and opinions.
ITCS user
Business Technology Analyst at a financial services firm with 10,001+ employees
Vendor
It provides some excellent plug-ins like Repository connector plugin, Sonar Qube plug in and J-Unit plugin.

What is most valuable?

I used it for building Java applications. It provides some excellent plug-ins like Repository connector plugin, Sonar Qube plug in and J-Unit plugin.

How has it helped my organization?

It provides a very user-friendly methodology to build applications. It can be very easily integrated with your repository containing the source code. It builds your applications in a user-friendly manner by just adding the repository URL.

What needs improvement?

One needs to be very careful with the POM file as it takes all the dependencies from the POM to build the application. I would not call it a drawback but a caution.

For how long have I used the solution?

I've used it for 10 months.

What was my experience with deployment of the solution?

Issues with deployment occur primarily because of incorrect run time dependencies. The stack trace of the console can be used to encounter such problems effectively

What do I think about the stability of the solution?

Occasional technical glitches after upgrades.

What do I think about the scalability of the solution?

Easy to run multiple instances simultaneously.

How are customer service and technical support?

Customer Service:

8/10

Technical Support:

7/10

Which solution did I use previously and why did I switch?

We didn't have any solution in place previously.

How was the initial setup?

Initial set-up needs caution in mentioning the dependencies i.e. both runtime and compile time.

What about the implementation team?

We did it in-house.

What's my experience with pricing, setup cost, and licensing?

I believe it's good value.

What other advice do I have?

It can be used effectively with technical expertise.

Disclosure: I am a real user, and this review is based on my own experience and opinions.
ITCS user
Business Intelligence QA Engineer at a tech vendor with 201-500 employees
Vendor
​Potential deployment problems pop up almost instantly during the development process.

What is most valuable?

  • Scalability
  • Controllability
  • Organization of jobs

How has it helped my organization?

Potential deployment problems pop up almost instantly during the development process. The developers are more confident about their committed code.

What needs improvement?

They need more useful tutorials about how to write database related plugins. It also needs a "run only" option without option for changing job configuration.

For how long have I used the solution?

I've used it for six months.

What was my experience with deployment of the solution?

There were some issues with deployment.

What do I think about the stability of the solution?

There were some issues with stability.

What do I think about the scalability of the solution?

There were some issues with scalability.

Which solution did I use previously and why did I switch?

No other solution was used previously.

How was the initial setup?

It wasn't complex.

What about the implementation team?

We did it in-house.

What was our ROI?

It's infinity as the developer's happiness are endless.

What's my experience with pricing, setup cost, and licensing?

It's free.

Which other solutions did I evaluate?

We did not do a deep evaluation but we did look at Bamboo.

What other advice do I have?

Stay calm and mind the gap between your QA automation team and developers.

Disclosure: I am a real user, and this review is based on my own experience and opinions.
ITCS user
Mobile QA Developer at a tech vendor
Vendor
It's a good alternative to become parallel infrastructure purely dedicated for testing, but it lacks the ability to control interim status messages.

What is most valuable?

1) Easy to install and setup (including setup to run as windows service)

2) Free and always available alternative to any other build solutions

3) Relatively simple and intuitive UI

4) Big number of pretty useful plugins

5) Easily configurable and scalable

How has it helped my organization?

In some of my projects I had a chance to participate we used to use some commercial solutions like TeamCity or Bamboo. Since we had limited number of build machines and build agents it was really hard to organize automated acceptance and high-level system test runs as it took a while to perform the run.

Even more, since we had restricted number of build agents the huge number of long-running tests could make serious bottle-neck to the entire build process, hence, the feedback is a bit delayed. Jenkins appeared to be a good alternative to become parallel infrastructure purely dedicated for testing.

The bottle-neck problem was mitigated and we were able to make large scale runs on infinite basis. Thus, we could get results 2-3 times a day instead of 1 which brought us more consolidated and consistent picture about application under test state during the day. This trick was helpful for me on many projects

What needs improvement?

A lot of features (even small ones) can be taken from existing analogs. E.g.:

1) Ability to control interim status messages. This feature exists in TeamCity where you can log a message of specific format and it could change the build text and temporary status. In particular it's useful to see the number of tests already passed/failed without waiting for the completion

2) When we need to restart the server while some jobs are running it could be useful to re-run those dropped jobs after restart automatically.

3) There is some set of plugins which is being set up very frequently for many projects. It could be useful to have some pre-defined installations which either contain all necessary plugins by default or install them at the initial run (to decrease the size of initial application package)

Generally, other systems have lots of features which could be useful to see in Jenkins

For how long have I used the solution?

Since 2009. At that time it was called Hudson

What was my experience with deployment of the solution?

No. Deployment easiness is one of the advantages of Jenkins

What do I think about the stability of the solution?

From time to time Jenkins experiences problems after 1-2 weeks of intensive work (where at least 1-2 jobs are running at any point of time).

There used to be some issues when entire configurations could become invisible from the UI (usually that could happen after unexpected system shut down or even simple configuration rename operation) which was a bit painful. But I didn't encounter such problems in the most recent versions. So, it definitely indicates that some work at this direction was definitely done.

What do I think about the scalability of the solution?

No

How are customer service and technical support?

Customer Service:

Never had a chance to communicate

Technical Support:

Never had a chance to communicate

Which solution did I use previously and why did I switch?

Mainly Jenkins used to be either main system or parallel solution. Major reason for using it was mainly related to:

1) Licensing

2) Limited capacity of build agents

How was the initial setup?

Setup is pretty straightforward

What about the implementation team?

Both in-house and vendor

What's my experience with pricing, setup cost, and licensing?

It's free. There's no advice required

Disclosure: I am a real user, and this review is based on my own experience and opinions.
ITCS user
Software Engineer at a media company with 10,001+ employees
Real User
It enables us to perform project-based matrix authentication, but canceling permissions is problematic.

What is most valuable?

  • Uno-choice parameters
  • Publishing HTML reports
  • Emails on builds
  • Active Directory
  • Role Based and Project Based Matrix Authorisation

How has it helped my organization?

We work on distribution, and are required to build and test packages frequently. Using Jenkins we have configured (generic) and automated the complete build procedure.

What needs improvement?

  1. There's a plugin Monitoring which have certain issues with some versions of Jenkins
  2. Jenkins user login and authorization case-insensitive, eg: if user John is given authorization permission then JOHN, JoHN, johN etc. all should be authorized.
  3. Disabling of cancel permissions to some users in Jenkins is still not working, even if we uncheck the cancel permissions. If build permissions are given to that user, cancel permissions are granted automatically
  4. Plugin to disable Back button navigation in Jenkins#
  5. Uploading multiple files using patch parameter in Jenkins

For how long have I used the solution?

I've used it for around six months.

What was my experience with deployment of the solution?

No major issues, it was pretty smooth.

What do I think about the stability of the solution?

With few plusgins, like Monitoring. it crashes.

What do I think about the scalability of the solution?

Not as of now.

How are customer service and technical support?

Customer Service:

No interactoins as of now.

Technical Support:

No interactoins as of now.

Which solution did I use previously and why did I switch?

We upgraded from Hudson which is similar.

How was the initial setup?

It was pretty straightforward.

What about the implementation team?

We took it from Open Source so there was no vendor involvement.

What was our ROI?

Disclosure: I am a real user, and this review is based on my own experience and opinions.
ITCS user
Senior iOS Developer at a media company with 5,001-10,000 employees
Vendor
Bamboo vs. Jenkins
A biased and subjective comparison of Bamboo and Jenkins as CI servers for mobile development, based on practical experience with both. Continuous Integration and Continuous Deployment (Delivery, Distribution) has been around for quite a while. But surprisingly enough on a global scale it pretty much just got into its teen years in regards to mobile development. Well, subjectively, of course. You can see all levels of mobile CI these days. Some would still install builds from Xcode, others would have a quickly patched up build server under their desk. Xcode Bots meet the needs of yet another group of people. Travis CI is good and for open source projects it’s probably the best option. And guess what, I know few successful iOS development companies that develop apps for enterprise…

A biased and subjective comparison of Bamboo and Jenkins as CI servers for mobile development, based on practical experience with both.

Continuous Integration and Continuous Deployment (Delivery, Distribution) has been around for quite a while. But surprisingly enough on a global scale it pretty much just got into its teen years in regards to mobile development. Well, subjectively, of course.

You can see all levels of mobile CI these days. Some would still install builds from Xcode, others would have a quickly patched up build server under their desk. Xcode Bots meet the needs of yet another group of people. Travis CI is good and for open source projects it’s probably the best option. And guess what, I know few successful iOS development companies that develop apps for enterprise clients, and have no CI at all.

The advanced level of CI would include distributed build systems with multiple build nodes, support for automated unit and UI tests, running tests on simulator and physical devices, automatic deployment to TestFlight, Hockey App, Over the Air, and much more. It becomes not just mobile development, but spans into areas like DevOps and others. Etsy’s blog post is somewhat outdated but still a very good example of where this path can take you.

If you decide to take mobile CI under your total control, you have to pick a build server to start with.

I personally have worked with Bamboo for 1.5 years and I’m dealing with Jenkins right now, so I have few insights and can give some comparison of the two.

Setup & Configuration

Bamboo installation and Jenkins installation tasks are about the same in terms of time and knowledge required. While installing one of the two you’ll climb a certain learning curve which will help you heaps if you ever have to deal with second option.

Both are built using Java. Being Java applications, both will require similar JVM configuration. Default configuration won’t really serve you well. You’ll experience out of memory issues as soon as you add a couple of basic build plans/projects.

And lot of other things are similar: configuration behind proxy, login vs non-login user (Launch Agent vs Daemon), OS X Keychain, iOS Simulator, etc.

GUI

Obviously, this is not a comparison criteria at all. This criteria is as subjective as it could possibly be!

Out of the box Bamboo UI looks much better than Jenkins version.

With Jenkins there are ways to improve your day to day user experience. You can customize theme and even make your custom UI improvements, like adding “Build Now” button where you like it.

You should start by installing Simple Theme Plugin and then configure it with one of the available themes. Not all the themes will look good, it all depends on the Jenkins version you have and browser you use, etc. I tried a bunch of them and ironically enough the only theme that looks good on our production CI box is called “Atlassian”. But I’m dealing with slightly outdated Jenkins version, you could get better results with up to date Jenkins.

There’s multitude of UI, List View and Page Decorator plugins available for Jenkins. Some of them must be good and help you customize you Jenkins look & feel and functionality.

Plugins

This is where the large community plays its role. Subjectively or not, Jenkins has a larger choice of plugins of all kinds, starting from management and organization of build jobs and ending up with reporting.

Via a fancy pie chart diagram we are told that Bamboo has 151 plugins on Atlassian Marketplace.

A quick check on Jenkins Wiki and we get a count of 1,071 plugins.

Reporting is one of the most important plugin categories in my opinion. For example, I prefer to have full control over Xcode build tasks and use makefiles combined with shell commands wrapping xcodebuild rather than use Xcode plugin. Part of the reason is to be able to migrate to another build server with less effort and to be able to run CI tasks on my development laptop. Same goes for other things like uploading to / downloading from S3 bucket, transferring files with rsync or scp, and so on. But in no way I can come up with scripts that will produce good looking reports including HTML formatting, diagrams and images, plus integration into Bamboo or Jenkins UI. For this task I prefer to use plugins.

Jenkins features 127 plugins just for reporting, that’s almost as much as Bamboo can offer in total. Of course, quality of all those plugins deserves a detailed research. Just numbers don’t tell much. But this post is based on some hands on experience, so I’ll compare some reporting plugins I have used over time.

Publish HTML

If you ever used Clang Static Analyzer for your iOS projects, you know then that there’s no proper reporting plugin for this task. You end up with HTML report that needs to be published and made available in build project/plan summary page.

With Bamboo you create a new Shared Artifact, with Jenkins you use HTML Publisher plugin.

Unit Tests

Of course you run unit tests as part of your CI, don’t you? In that case you are well covered by reporting plugin on both Bamboo and Jenkins. Jenkins plugin also includes trending graphs, which is nice.

Cobertura Code Coverage

Of course you don’t just run unit tests, but also gather code coverage data, don’t you?

This is the first time Bamboo falls one plugin short. You can check related discussion for more details.

Jenkins has your back on this one with Cobertura Plugin. You can configure custom threshold values to mark builds as failed if you tests don’t provide enough coverage.

Static Analyzers Reports

OCLint is amazing tool to run another round of static analysis on your code and detect vast number of issues as well as to enforce coding guidelines. OCLint can produce output compatible with PMD output format. So it can then be processed by Jenkins PMD Plugin. You end up with browsable report with issues grouped by priority, category and other criteria. You can navigate all the way down to the line of code causing the warning. Once again, you can configure threshold values to mark builds with lots of warnings as failed.

In fact, the same reporting plugin should be able to pick up output of Clang Static Analyzer which I mentioned before. However I couldn’t figure out the way to make Clang Static Analyzer to spit out correct XML file.

With Bamboo, unfortunately, all you have is publishing HTML report via shared artifact.

P.S. I’m a big fan of Swift programming language, but one thing makes me a bit sad. It will take some time before we get tools like OCLint available for Swift.

Warnings

If you run CI tasks such as build, test, analyze and lint, often you don’t want your build project/plan to stop immediately if it encounters an error, for example test error. You still want your reporting tasks to run and pick up those errors and generate reports for them. This often leads to a problem where you have compilation error but the build is marked as passing. Preferred way to avoid this issue is to have a reporting task which will pick up all the errors and mark build as failed if needed.

Jenkins has Warnings plugin for that. It will scan build logs and detect warnings and errors generated by compiler, and it includes support for clang so xcodebuild is well covered. All you need is to configure thresholds and fail builds if it has compile errors.

I don’t know about Bamboo plugin to do the same job. I remember myself few months ago grepping test logs for errors and then marking builds as failed by doing something like exit 1.

Functional Tests

If you happen to use frameworks like Calabash that produce Cucumber test reports, then Both CI servers have plugins to provide nice reports.

Higher-order Plugins

Forgive me this injection of so popular these days functional slang, but this is how I want to introduce The Mother and The Father of all Jenkins plugins - Jenkins Job DSL Plugin. In short, it allows you to manage your configuration as a code and to generate and update build projects from code. What could be better for a developer?

Check out these resources to find out more.

I plan to write a post about my personal experience with Job DSL plugin.

Jenkins Job DSL plugin was a game changer for me personally. When I started working at new place a while ago, I had year and a half experience with Bamboo and acted as a strong Bamboo advocate initially. Until the moment I discovered unlimited power of Job DSL plugin. I personally can’t imagine going back to Bamboo and dealing with UI to update dozens of similar plans by hand.

That said, I still like Bamboo very much, particularly the way it integrates with the rest of Atlassian products. I hope Atlassian will implement Build Plan DSL plugin or provide API to make it happen. Bamboo Trade Depot Plugin is the only thing that could match Job DSL plugin, but unfortunately it’s not even close.

Build Plan/Project Structure

There is a bit of confusion caused by terminology used by Bamboo and Jenkins.

Bamboo

With Bamboo you start by creating Build Plan.

Each plan consists of one ore more Build Stages. Stages run in sequential order. If one stage fails next stages are never executed. Stages can be configured as manual to be triggered by hand.

Stages contain Build Jobs. Build jobs in one stage can run in parallel if there’s enough build agents for that. Each job can require different capabilities and can be dispatched to run on some designated build agent. Build jobs may produce Build Artifacts and share them with other jobs in consequent stages. Since jobs are parallelized, if one of them fails other jobs will still keep running until they finish on their own. This feature can significantly reduce build time, instead of sequential Build ⟼ Test ⟼ Analyze ⟼ Lint running 10 minutes, you get parallel Build || Test || Analyze || Lint running for about 3 minutes (given that longest job takes around 3 minutes).

Finally each job is made of Build Tasks. Tasks run in order from top to bottom. A task may be a basic shell script or one of the many tasks provided via plugins. Here’s a generalized example of a job and it’s tasks. One large and important group of taks is reporting tasks.

  • Checkout git repository
  • Build
  • Test
  • Deploy
  • Generate test report

A summary of a Build Plan structure

  • Build Stage
    • Build Job
      • Task
      • Task
      • [more tasks]
    • [more jobs]
  • [more stages]

Not So Parallel

Bamboo deserves a special side-note in regards to parallel job execution and iOS build plans.

As I mentioned before, the way you assign build jobs to local or remote agents is via capabilities. An agent defines capabilities it has, a job declares capabilities it wants, and then Bamboo matches the two.

If you are in total control of your CI setup and mobile team is the only one using your particular Bamboo server and all agents, you have all the power to set all the agents’ capabilities and then enforce a requirement that all build jobs created by you or your teammates must explicitly specify which capabilities they need. This way you’ll harness the full power of distributed configuration, all build jobs will run only on the agents they really should run on.

Another situation is when mobile CI is a new addition to company CI setup. There is already a CI server and few dozens of build agents and a lot of other teams using this CI setup. Lots of teams with lots of plans created over the years.

Now imagine that you are adding your specialized Mac build agent to be used for Xcode builds only. You setup and configure remote Mac agent, connect it to the server and… all the other build plans start jumping on your Mac agent! That’s because 99% of those plans declare no capabilities they require, they simply expect that all the agents are identical in terms of capabilities. And that works because all the agents are indeed identical clones. Well were identical clones until a new Mac agent was added.

There’s no easy fix to this problem and you can tackle it in one of 2 ways.

Ideal Solution

Ideally, CI must be done right. All the build plans must be maintained, updated and removed if no longer needed. As a requirement, all build plans must explicitly declare capabilities they require to be able to run. This is something to be enforced at team management level. Company has to have guidelines for creating and managing build plans and there must be a person or even a team (Dev Support team) responsible for keeping guidelines up to date and enforcing them.

Down to Earth Solution

The reality is rough. The number of existing plans is overwhelming, it will take months to chase people responsible for each build plan and communicate the importance of declaring capabilities to them. The whole change has to be made in a safe way so it doesn’t break existing workflows and production deployments.

You don’t have months of waiting allocated in your schedule, you need mobile CI running ASAP. One thing you could do is to setup your own CI server just for mobile and essentially move to “under the desk” setup. This way you get no support from Dev Support team (given that you have one) and all the trouble of setting up, configuring and supporting the server and agents is now yours.

However, you still can do mobile CI as part of company wide CI. There is a plugin that will help you - Bamboo Group Agent plugin. Have a read if you interested, Group Agent plugin offers a solution which is not fully flexible, but will help with original problem.

Jenkins

With Jenkins you start by creating Build Project, which is on occasions called Build Job causing certain confusion. In this post I’ll stick with Project term.

By default all you get is a basic Freestyle project that includes

  • Description
  • Parameters
  • Build Triggers
  • Build Environment
  • Build Steps
  • Post-build Actions

If you draw an analogy to Bamboo, then all you get is a build plan with single stage containing single job and list of tasks (Build Steps and Post-build Actions are nothing but tasks). That’s it. There are no stages and no way to run anything in parallel.

This is where plugins get into play. Mutlijob Plugin does exactly the same thing as Bamboo. Stages are called Phases, phases include Jobs. Jobs run in parallel when possible, while phases execution order is sequential.

One very important distinction is that jobs in multi job project are actually references to existing build projects.

  • Multi Job Build Project
    • Build Phase
      • Build Job 1 ⇢ Build Project 1
      • Build Job 2 ⇢ Build Project 2

In theory you can have a multi job project that includes a job which is a multi job project… You could even unintentionally create build job retain cycles and an infinite build loop.

To satisfy your craving for code Multijob Plugin support is added to Job DSL Plugin.

Once again with a fair bit of work Jenkins can match Bamboo’s default functionality and then with another fair bit of work can surpass it.

I mentioned artifact sharing briefly for Bamboo. For Multijob plugin there is no proper artifact sharing support yet. There’s a number of open tickets (JENKINS-20241, JENKINS-25111, JENKINS-16847, JENKINS-16847) with workarounds available. So the problem can be solved but it’s not part of official Jenkins release yet.

Not So Parallel Either

Jenkins is still prone to the same problem Bamboo is when it comes to adding iOS build nodes to existing infrastructure. Chances are high your Mac build node will be used by all the other build projects if capabilities are not configured properly.

Actually, in Jenkins world there are no capabilities as such, instead labels are used. Semantics are a bit different, but they serve the same purpose after all. Each build node can be labeled with multiple labels and build jobs can use flexible logical expressions to specify target nodes they want to run on. But then, if labels were not used in your corporate CI from day one, the amount of work required for labelling existing build projects can be too big.

At this moment I am not aware of a Jenkins analogue of Bamboo Group Agent.

Branch Management

Branches are an essential part of any source code management workflow. By supporting branches in CI workflow you get a number of benefits.

Timely Feedback

By running CI for each branch you provide developer with earlier feedback on their changes. They will know right away if changes they made are breaking the build, unit or functional tests, introduce static analyzer or linter warnings, etc. Developers can then fix these problems before they create pull request and involve the rest of the team in review process.

Earlier Tests

If you have testable build for each branch, you can make it available to your test team automatically as part of continuous delivery process. This way important and critical changes can be tested before they are merged to upstream branch (doesn’t mean you don’t do integration testing after the merge though). Bugs can be caught earlier and you end up with faster develop-and-test iterations.

Finally, some branches are never destined to be merged upstream. They may contain some experimental feature code, something you still need to build and make available to testers or internal stakeholders. For example have a special build to demo crazy design idea to your UI/UX people.

Branch Naming

I had to mention branch naming in a separate paragraph. For some reason, yet unknown to me, when it comes to naming a branch developers get completely wild. What I mean is that within the same team you can see branch names with and without prefix, using dashes or camel case, dashes and camel case combined, underscores… just anything. Sometimes the same developer would be very inconsistent when naming their branches. The very same developers are very disciplined when it comes to coding, i.e. class, variable and method names, and following coding style guide in general.

The upshot is that you have to have branch naming guidelines in your team, e.g. as a part of Git (other SCM) workflow. If the whole “issue” doesn’t look like an issue to you, wait until you have to manage this branchy havoc in regards to CI.

Bamboo & Branches

Bamboo does a great job with branches. With a single tick of a checkbox you can create branches of a build plan. By the way, you did understand it correctly, you create a branch of a build plan. Essentially, Bamboo clones the original build plan and changes its source repository configuration to point to a different branch. These plans still share same build phases, jobs and tasks, but you can configure some of the branch plan settings differently, that includes notifications, branch merging strategies, etc.

With a standard Java regular expression you can filter branches by their name and instruct Bamboo to ignore branch names that don’t follow guidelines. For example, the regex below will accept only master and development branches, and branches that are prefixed with bugfix/, hotfix/ or feature/ followed by JIRA issue ID and lowercase-with-dashes description.

<code>master|development|((bugfix/|hotfix/|feature/)\w{2,}-\d+(-[\da-z]*)*)

A good Java regex test website is RegexPlanet.

This is a perfect way to indirectly enforce correct branch naming. After missing couple of builds developers will figure out what’s wrong and change their habits. In certain situations you can always add a branch manually via Bamboo UI or CLI tools.

With another simple configuration field you can control aging of the branches. If branch hasn’t been updated for a long time, Bamboo will remove its build plan. Of course you’d want to preserve certain branches forever and there’s yet another checkbox to do that.

I’ve mentioned branch merging strategies and that’s one more feature that Bamboo provides out of the box. Using Branch Updater or Gatekeeper you can configure build plan to do upstream merge before or downstream merge after running the build, and even push merged changes back to the repository. This is a very good way to detect merge conflicts earlier and to keep your git workflow in order.

Bamboo’s branches support also shines when it comes to CI pipelines, more on that later in the post.

Jenkins & Branches

Surprisingly, plugins initially do more harm than good in this case.

On fresh setup Jenkins has no Git support (SCM I get to work with and thus choosing it as an example). You need to install plugin to work with Git and you will most likely install the most popular Git plugin. This plugin is very powerful but of all the things it does not create branches for build projects. Well to be honest it shouldn’t.

When you look for a solution you will think of trying some other plugins first. Thre are a few: Multi-Branch Project, Feature Branch Notifier and others. The common problem with all of them is that they have their own support for SCMs including Git, that means you don’t get to use the Git Plugin and all of its powerful features, instead you end up with a very limited version of it.

I tried Multi-Branch Project plugin, it was OK, but not good enough. I couldn’t get branch filtering to work, it kept picking up all the branches ignoring filters. There’s no option to configure branch aging, no branch merging strategies and so on. Finally, no simple and easy support for branched CI pipelines.

This is what I meant by harm in this case. You spend time trying different plugins and none of them would match Bamboo default functionality.

But all is not lost. Once again you will be saved by Job DSL plugin. Paired with Git Plugin it can work miracles. While Git Plugin can’t branch build projects it can work with branches as such. With one line of Groovy code you can fetch all the branches for your repository including information on their last update. Then with simple string regex match and date comparison you can filter branches just like Bamboo does, and then you can generate build project for each branch, organize them into folders and views to match Bamboo’s UI. Code a bit to generate branch pipelines, same for merging strategies and much more.

Follow this link to find an example of getting branches for GitHub repository.

If you are using Stash there is no direct support for it via Jenkins plugins afaik. But as long as you have API access you can follow Bitbucket example to have basic support for working with branches. If you don’t feel like coding too much, you can wrap some shell scripts in thin layer of Groovy code to get same results.

Yes, it takes time and learning to get used to Job DSL plugin, but the benefits are unmeasurable.

Pipelines

Pipelines is another name for CI/CD workflows. In certain cases single build plan/project is not enough, and that’s when you can create pipelines. Creating a pipeline means you chain build plans together, if first plan (aka parent) is successful it triggers its child plans. Child plans can have children of their own, and so on.

<code>. └── Parent Plan     ├── Child Plan 1     │  ├── Grandchild Plan 1.1     │  └── Grandchild Plan 1.2     ├── Child Plan 2     └── [more children]

A real world example of pipelines for mobile space is UI automation tests, often called Functional or Acceptance tests. UI automation is usually a heavyweight task compared to unit tests. If you run UI automation tests as part of a single build plan it can take too long to complete.

You can create a separate plan for UI automation only, but then you don’t want to trigger it every time there is a commit to SCM. There’s no point running UI automation tests if the build fails. So you add UI automation tests plan as a child plan to the main build plan thus creating pipeline.

This is just one example.

Bamboo Pipelines

Bamboo has support for pipelines out of the box. In parent plan configuration you simply add child plans and configure the way those are triggered, e.g. only when parent is successful.

Child plans don’t have to be configured in any special way, they are completely unaware of being some other plan’s children by default. The very same plan can be included in multiple pipelines acting in a different role.

The real power of Bamboo pipelines is in its support for branches. Child plan will only be triggered if it has the same branch as the parent plan. This means you have to configure branching for both plans to make it work. Normally this also means that both plans are using same repository, but it is not a mandatory requirement. If 2 different repositories have the same branch the feature will work all the same.

When child plan starts it can get artifacts from the parent via Artifact Downloader task. Yet again, the branch of the child plan gets artifacts from the matching branch of the parent plan, all is handled by Bamboo.

Jenkins Pipelines

Jenkins has no pipelines support by default. As usual plugins should be used.

This is something I’m only starting to work with, so this paragraph doesn’t have lots of details.

In general, Jenkins plugins let you match Bamboo functionality with a certain amount of work.

Most popular plugins used for pipelines are

Both are supported by Job DSL allowing you to script complex pipelines in code and change them easily.

Distributed Builds

Both Bamboo and Jenkins have support for distributed builds. Bamboo is using Remote Agents while Jenkins calls them Remote Nodes, sometimes referred as slave nodes or agents.

A side note - both servers support local build agents/nodes as well. Those are running locally (as the name suggests) on the same hardware as the build server.

Back to remote agents/nodes. Complexity of setting them up and configuring doesn’t vary much between the two CI servers.

Both will suffer from issues caused by sitting behind the company proxy, specifically if the server is located somewhere outside your company network (e.g. in AWS cloud).

Why the server is in the cloud and the agent/node is not? - you’d ask. Well, that takes us to next topic.

Mac Support

Right, this whole comparison is focusing on mobile CI after all, meaning you have to deal with one of the most popular mobile platforms these days - that is iOS.

To build an iOS app you must have Xcode, which can run only on OS X (unless you want to follow the path of certain insanity and make it work on other OS).

Hackintosh

Not a very good idea I’d say. The company does iOS development and wants to go with Hackintosh to setup OS X build server. Really?

Cloud (aka OnDemand)

Could be a really good option, but not with industry giants like AWS. AWS or alike is where you’d go if using Bamboo OnDemand feature. I can find posts as old as 2011 discussing this issue: one, two. Apple doesn’t make it easy to run virtual OS X instances to the extent that none of the big cloud providers are brave enough to provide official support for this feature. These days you can go with one of the many Mac Mini colocation services. You either rent a Mac hardware or even provide your own.

Self-hosted

This is also an option. If your company has security concerns about those Mac hosting providers, or doesn’t want to spend money for that, or for any other reason, you can always purchase Mac hardware and host it in your data center.

Whenever you are using self-hosting or remote hosting, you end up dealing with native hardware. I find that Mac Minis with maximized CPU, RAM, and SSD storage are perfect candidates for iOS CI box. The more you have the better.

Next step is to install remote agent/node and get it running. As I mentioned already, installing remote agent for Bamboo is around the same complexity as installing remote node for Jenkins. The problems start popping up when you begin using them.

Bamboo Remote Agent

hings you definitely need to know in regards to Bamboo remote agent.

[The rumor has it that] Atlassian are using Mac OS X to develop their products, including Bamboo, but OS X is never ever listed as officially supported. Indeed, why would you choose to run your JIRA, Stash, Bamboo, whatever, on OS X server? Hopefully with increasing demand for iOS CI Atlassian will put a bit higher priority on fixing Bamboo issues for OS X, and there’s plenty, btw.

Before you even start using remote agent on OS X, you have to experience a bit of pain when trying to set it up.

Major and the most important group of issues is related to Artifacts Sharing.

Whenever your remote agent finishes a build stage it is most often producing build artifacts. It doesn’t matter if those artifacts are shared or not, they must be copied to the server anyway. That is part of distributed build system. Your remote agent can go offline any time, your build plan jobs can run on different agents with different capabilities and artifacts must be passed from one agent to another. All in all, the reality is - the artifacts must be copied to the server.

Problem Proxy

Is your remote agent behind proxy? May I introduce you to HTTP 1.1 Chunked Transfer Encoding then? Well, not to the feature itself, but how it relates to Bamboo: BAM-5182, more.

Bamboo server requires support of HTTP chunked transfer feature of 1.1 protocol version to pick up artifacts. If your proxy doesn’t support this feature, you are in trouble. Strictly speaking, this is not Bamboo’s problem, this is the problem of your company network team. HTTP 1.1 standard was released in 1999! There is a lot of HTTP proxy implementations that support it, nginx for example. However, things move really slow in most of big companies when it comes to changing network infrastructure. If you are so unlucky and you company is still stuck around 1999 in terms of network infrastructure, you will most likely have to find a work-around rather than waiting months and months before you get any progress on proxy upgrade.

Problem Atlassian

But wait then! Too early to take all the blame off the Atlassian’s shoulders!

First of all, Bamboo remote agent JAR totally disrespects JVM flags for HTTP proxy whitelist (nonProxyHosts), upvote! You can find ways around this issue, for example re-routing network calls using tools like SquidMan, but then you will face The Final Blocker: BAM!, BAM!.

Yes, Bamboo remote agent is 27 (twenty seven!) times slower than plain scp (secure copy over ssh) command when it comes to copying a single .zip file which is around few hundred Mb in size.

Imagine that after spending all the time trying to figure out issues around your proxy and enable the agent to share artifacts with the server, you end up facing this beast? It renders all your distributed build setup useless, it takes way more time to copy build artifacts than to produce them. From reports it looks like this issue is specific for Mac OS build agents only.

When I faced this problem I ended up sharing artifacts via Amazon S3 bucket. This is extra work, extra shell scripts to upload and download artifacts, additional expenses for S3 bucket. You become responsible for managing outdated artifacts, you are the one who has to account for multiple build plan branches, and much more. This is really a bit too much of overhead and it is extra annoying when you know this is a core Bamboo functionality and it’s supposed to work right out of the box.

Jenkins Remote Node

Read the Jenkins Remote Node installation post to get initial overview.

As you can see, there are common problems related to running SSH sessions as non-login user and others. I personally ended up running remote node as OS X Launch Daemon. This works, but is not ideal.

I have nothing yet to say about artifact copy speed from slave to master in regards to Jenkins setup, but stay tuned and/or post a comment if you have any knowledge on the matter.

Android

I wanted to mention Android in this last section, after all it’s mobile too.

I wrote one post about building Android - Build Android in The Cloud which already provides some details.

In regards to Bamboo vs Jenkins comparison, almost everything I mentioned for iOS applies to Android, except the very big and troublesome Mac OS X part. You can, and you should build Android on Linux systems, and that’s exactly what AWS instances are running on! It means that if you have 25 build agents/nodes in the cloud, all 25 of them can be used to build Android projects.

I had experience with building Android projects using Bamboo OnDemand setup hosted in AWS cloud. It worked (and what I was last told it still works) flawless and scalability of AWS really pays back. Despite the fact that building Android project was way more slower than building similar iOS project, that wasn’t really a concern given the number of resources available to do the job. I still had to run Android UI Automation tests (usign Calabash) on Mac OS X box, because Linux agents in the cloud didn’t have enough horsepower to run Genymotion or Android Emulator reliably.

Summary

Despite my excitement with Jenkins Job DSL plugin there’s no clear winner for me.

Both solutions can be used for enterprise level mobile CI. Both can be used in pure UI-driven way while Jenkins also offers a code-driven approach with certain trade-offs.

I’d say, whichever server you use, whatever your CI requirements are, just make sure you take it seriously. In some way I’m calling out to all of you to help mobile CI to get out of its teen years.

Disclosure: I am a real user, and this review is based on my own experience and opinions.
ITCS user
Senior iOS Developer at a media company with 5,001-10,000 employees
Vendor
​This is a very good, powerful and flexible product, but requires a lot of time investment to get the maximum out of it.

What is most valuable?

The Jenkins Job DSL plug-in is the most valuable.

How has it helped my organization?

We have been able to create CI jobs for each branch of our repository. Being able to test builds for each branch before it is merged to mainstream branch helped to improve stability of the app and have faster develop-test iterations.

What needs improvement?

The installation process could be simplified, especially on Mac OS X.

For how long have I used the solution?

I've used it for eight months.

What was my experience with deployment of the solution?

Yes because the installation process is not obvious.

What do I think about the stability of the solution?

The default settings do not work properly on Mac OS X. You have to tweak JVM parameters and allocate more heap memory as well as change other parameters to have a stable Jenkins server.

What do I think about the scalability of the solution?

I haven't had to scale up yet. We have one build box which is running two agents on it.

How are customer service and technical support?

Customer Service:

As this is open source, there is no such thing as customer service, but there is a big community to look for information and get answers.

Technical Support:

As this is open source, there is no such thing as tech support, but there is a big community to look for information and get answers.

Which solution did I use previously and why did I switch?

Personally, I previously used Bamboo. I switched because I changed jobs and at my new place Jenkins had been used. It would unjustified to do a move from Jenkins to Bamboo, given that Jenkins is capable of performing same tasks.

How was the initial setup?

It was complex and additional knowledge about launch agents and daemons is required. There are at least three, if not four, different ways to install and configure Jenkins, which is not always good.

What about the implementation team?

We implemented it in-house.

What was our ROI?

It's high because the product is free.

What's my experience with pricing, setup cost, and licensing?

The original setup. for us, was the cost of a new Mac Mini box which costs, from $1,000 to $2,000 depending on the configuration.

What other advice do I have?

This is a very good, powerful and flexible product, but requires a lot of time investment to get the maximum out of it.

Disclosure: I am a real user, and this review is based on my own experience and opinions.
ITCS user
Developer at a tech services company with 51-200 employees
Consultant
It’s not the best looking tool. It’s simple but can be complex and it has a load of plugins available for it.
It’s interesting how many places still don’t use continuous integration tools like Jenkins and how many places don’t automate their deployment systems. If that all sounds like goobledegook to you, or if it makes sense but you’ve never used anything like it then this post is for you. Life before Jenkins Before we talk about Jenkins I think it’s worth talking about my experience of life before Jenkins, which will be familiar to a lot of people. Here’s what might have happened in an average working day pre-Jenkins I would write some code and commit it Occasionally a project manager or designer or someone equally focused on interrupting my programming would ask to see the latest version of the project I’d update my code and show them and then they’d ask if they could have a play with it from…

It’s interesting how many places still don’t use continuous integration tools like Jenkins and how many places don’t automate their deployment systems. If that all sounds like
goobledegook to you, or if it makes sense but you’ve never used anything like it then
this post is for you.

Life before Jenkins

Before we talk about Jenkins I think it’s worth talking about my experience of life before
Jenkins, which will be familiar to a lot of people. Here’s what might have happened in an
average working day pre-Jenkins:

  1. I would write some code and commit it
  2. Occasionally a project manager or designer or someone equally focused on interrupting my programming would ask to see the latest version of the project
  3. I’d update my code and show them and then they’d ask if they could have a play with it from their computer
  4. 4. I would then interrupt someone in charge of deployment and would ask them to deploy it somewhere
  5. This person would probably groan (because they’re in the middle of something) and say that they could do it in 15 minutes
  6. The project manager would roll their eyes and sit at their desk reading emails or updating a GANTT chart (or whatever project managers do) for 30 minutes (because the task the developer was doing took twice as long as expected)
  7. The deployer would open their FTP program and copy files up to the dev server, or SSH the files up or whatever, possibly missing a few files the first time and then having to do it a second time
  8. The project manager would complain the work he wanted wasn’t there.
  9. The deployer would realise he hadn’t updated his code and do the process again
  10. Three hours later the same thing the process would start again…

It’s a slow, error prone, painful process and we haven’t even talked about deploying to staging or live environments yet. A major problem is also that a lot of people are unsure what the exact state of the project is because they never know if what they’re looking at is up to date.

 Jenkins to the rescue!

Here’s how that above process would work with Jenkins running.

  1. I write some code and commit it.
  2. Moments later the code is on a development environment without anyone having to do anything.
  3. The project manager looks at the development environment whenever they want to knowing it has the latest work on it
  4. The QA tester checks the release on the development environment and clicks a button in Jenkins to deploy to the staging environment.

Simple! (I even added an extra staging deploy part in there to look extra clever)

So, what is Jenkins?

The Jenkins CI (that’s its proper name) website describes it as “an awardwinning
application that monitors executions of repeated jobs, such as building a software project or jobs run by cron.”

So Jenkins is a tool that can be used to do any kind of repetitive task, but the added bonus of Jenkins is that these repeated tasks can be monitored and report information and make it easy for people to initiate these tasks or have them initiated automatically.

So for example, you might have a .Net project which is the server aspect to a project with iOS and Android apps. Jenkins can build and deploy the .Net project whenever changes are made so the latest version is available. The iOS and Android applications can also be built when code is changed and can be deployed via tools like TestFlight.

The “continuous integration” part comes into play when you have multiple developers working on a project. Jenkins is constantly building the latest version of the project from all developers' code so your work is being integrated (and deployed) continually.

I’m not going to get too deep into technical details since you can get those from the Jenkins website or via the excellent “Jenkins: The Definitive Guide” book but I’ll talk about what Jenkins would for a .Net project with a simple HTML/CSS/JS frontend codenamed
“Gumboots”.

  1. In Jenkins there is a “Gumboots” job which has been configured with the details of a
    GitHub repos containing the code for the project
  2. GitHub has been configured to hook into your “Gumboots” job whenever the code
    changes
  3. A developer pushes some code to the GitHub repos. GitHub notifies Jenkins about the
    new code.
  4. Jenkins gets the new code and runs a build.
  5. Jenkins has been configured to do a few things when the build is run:
           a) It runs a load of automated test cases
           b) If those pass it then builds the project using the MSBuild plugiN
           c) If that works it then runs a Gulp tasks on the CSS and Javascript to minify                   them and concatenate them.
  6. If that is all successful, then it will deploy the new code over SSH to the developmenT server

If any of these steps fail, then Jenkins will send an email with details of the problem to people involved in the project and most importantly to the person who wrote the last piece of code that may have broken the build.

Setting up jobs for Android and iOS applications is very similar and follows the pattern of “get code”, “build code”, “deploy code”.

There’s even a Chuck Norris plugin to give you extra feedback about the state of your jobs. Now really, what more could you want?

What next?

I’ve described a basic, but powerful Jenkins job set up. This will do a lot for you, but it can be taken further. 

The kind of things that you can get Jenkins to do that might be useful for you are:

  • Create a pipeline which pushes a build to dev automatically, then to staging after a
    manual QA check and then to live when a release is required.
  • Integrate Jenkins with an issue tracker like JIRA so that as Jenkins deploys code it tells JIRA what issues have been released
  • Get Jenkins to automatically run migration scripts on your databases when deploying and also get Jenkins to do one click rollbacks of your project if things go wrong
  • Create a parameterised Jenkins job which takes some input and then spins up a new
    server based on that input for you.

There are lots of other tools similar to Jenkins of varying complexity and approaches. These tools are becoming increasingly popular as cloud services which can handle platform
configuration and provisioning as well as the code deployment aspect.

Jenkins has always worked well for me. It’s not the best looking tool, but it has a large
community, it’s simple but can be complex and it has a load of plugins for it.

Hats off to Kohsuke Kawaguchi and the Jenkins team for building us something so useful.

Disclosure: I am a real user, and this review is based on my own experience and opinions.
ITCS user
Release Manager at a financial services firm with 10,001+ employees
Vendor
Robust community support plugins.

What is most valuable?

The feature of this product that is most valuable to me is the robust community support plugins.

How has it helped my organization?

Jenkins has greatly improved the time it takes to deliver a software package to the market.

What needs improvement?

I can't think of any at the moment.

For how long have I used the solution?

I have used Jenkins and Hudson for about four years.

What was my experience with deployment of the solution?

No issues encountered.

What do I think about the stability of the solution?

No issues encountered.

What do I think about the scalability of the solution?

No issues encountered.

How are customer service and technical support?

The community of people who use this open source tool are very helpful.

Which solution

What is most valuable?

The feature of this product that is most valuable to me is the robust community support plugins.

How has it helped my organization?

Jenkins has greatly improved the time it takes to deliver a software package to the market.

What needs improvement?

I can't think of any at the moment.

For how long have I used the solution?

I have used Jenkins and Hudson for about four years.

What was my experience with deployment of the solution?

No issues encountered.

What do I think about the stability of the solution?

No issues encountered.

What do I think about the scalability of the solution?

No issues encountered.

How are customer service and technical support?

The community of people who use this open source tool are very helpful.

Which solution did I use previously and why did I switch?

No previous solution used.

How was the initial setup?

Jenkins is very straightforward to install. Basically, it's a Java app that runs on an app server.

What about the implementation team?

We implemented Jenkins in-house.

What was our ROI?

100% since it is open source.

What's my experience with pricing, setup cost, and licensing?

No setup/;day to day costs.

Which other solutions did I evaluate?

Yes, we also looked at Hudson and Cruise Control.

What other advice do I have?

Invest in time reading the support forums and newsgroups. Collaborate with other professionals.

Disclosure: I am a real user, and this review is based on my own experience and opinions.
it_user191856
Software Developer with 51-200 employees
Vendor
It's simple and intuitive but the plugins need to be streamlined

What is most valuable?

  • Extensibility
  • Usability

How has it helped my organization?

We've achieved continuous integration and delivery on all our commits, securing the quality of all of our products on their main branches. The features used come almost out of the box.

What needs improvement?

Many of the plugins needs to be streamlined, their terminology needs to be the same and some plugins should be split into multiple smaller plugins.

For how long have I used the solution?

Since 2010, so almost five years.

What was my experience with deployment of the solution?

No issues encountered.

What do I think about the stability of the solution?

Minor, but those issues typically gets fixed after reporting them. Some issues can be addressed as pull requests, fixing them myself.

What do I think about the scalability of the solution?

No, not after the lazy-load of items were introduced.

How are customer service and technical support?

Customer Service:

5/10.

Technical Support:

5/10.

Which solution did I use previously and why did I switch?

I used Hudson before, so the switch was quite natural.

What about the implementation team?

In-house implementation.

What's my experience with pricing, setup cost, and licensing?

My colleagues and I did the setup, so only the hours we spent doing it.

Which other solutions did I evaluate?

We also looked at Buildbot.

What other advice do I have?

Just go for it. It's simple and intuitive.

Disclosure: I am a real user, and this review is based on my own experience and opinions.
it_user188790
QA Automation Lead at a tech company with 51-200 employees
Vendor
​Provisioning VMs was an issue during deployment but ​automation in general has been improved.

What is most valuable?

I can build slaves and extensions through plugins.

How has it helped my organization?

Automation in general has been improved.

What needs improvement?

Provisioning of VMs during deployment.

For how long have I used the solution?

Five years.

What was my experience with deployment of the solution?

Provisioning VMs during deployment was an issue.

What do I think about the stability of the solution?

No issues encountered.

What do I think about the scalability of the solution?

No issues encountered.

How are customer service and technical support?

Customer Service: Not needed. Technical Support: Not needed.

Which solution did I use previously and why did I switch?

We previously used Hudson, and CruiseControl.

How was the initial setup?

What is most valuable?

I can build slaves and extensions through plugins.

How has it helped my organization?

Automation in general has been improved.

What needs improvement?

Provisioning of VMs during deployment.

For how long have I used the solution?

Five years.

What was my experience with deployment of the solution?

Provisioning VMs during deployment was an issue.

What do I think about the stability of the solution?

No issues encountered.

What do I think about the scalability of the solution?

No issues encountered.

How are customer service and technical support?

Customer Service:

Not needed.

Technical Support:

Not needed.

Which solution did I use previously and why did I switch?

We previously used Hudson, and CruiseControl.

How was the initial setup?

Initial set-up was straightforward.

What about the implementation team?

We implemented in-house.

Which other solutions did I evaluate?

We compared Jenkins to CruiseControl.

What other advice do I have?

It works.

Disclosure: I am a real user, and this review is based on my own experience and opinions.
it_user181050
Senior Software Automation Engineer with 501-1,000 employees
Vendor
Open source community with many plugins although stability for all but the most popular plugins needs to be improved.

What is most valuable?

Open source community with many plugins & flexibility as an automation platform.

How has it helped my organization?

Rather than send emails and tickets around we can hand out "buttons" to teams so they can do self-service for actions that used to involve manual effort from the Operations group.

What needs improvement?

Polish for the user interface, stability of plugins beyond the very most commonly used ones.

For how long have I used the solution?

Over seven years.

What was my experience with deployment of the solution?

No issues encountered.

What do I think about the stability of the solution?

No, although in some scenarios memory use can bloat over time.

What do I think about the scalability of the solution?

Not directly, but because of our overcomplicated networking setup we had to spread over multiple Jenkins masters each with a set of nodes.

How are customer service and technical support?

Customer Service:

Open source version, but have occasionally asked a quick question in the IRC channel and sometimes get a clue or two.

Technical Support:

Open source version, but have occasionally asked a quick question in the IRC channel and sometimes get a clue or two.

Which solution did I use previously and why did I switch?

We started with Bamboo, but it wasn't flexible enough (at the time) to also be used for general automation (code deployments, application restarts, etc). Really we might have just expected too much of it.

How was the initial setup?

Easy. Drop in .war file, and restart the Tomcat server.

What about the implementation team?

In-house.

What was our ROI?

Hard to say. Although it was free, so infinite.

What's my experience with pricing, setup cost, and licensing?

Free. Takes some work hours of course, but those come back many fold in improved productivity through automation.

Which other solutions did I evaluate?

No, we picked a long time ago before there were a lot of alternative options on the market. The few others available were expensive. Jenkins (well, Hudson at the time) was free!

What other advice do I have?

Do it! There's really no way you can lose. Even if you decide Jenkins isn't for you then you only spent work hours that helped train your staff and create reusable scripts that can be applied in other tools just as well.

Disclosure: I am a real user, and this review is based on my own experience and opinions.
it_user7542
Director of Operations at a tech vendor with 51-200 employees
Vendor
Strong community of developers and contributors
Jenkins is also open source, in very active development, and has a strong community of developers and contributors. Because Jenkins is a fork of Hudson, the interface is similar, and much of the core code remains the same (although Hudson 3.0 has some significant changes). Without going too far into the debate (you can read more about it from the Jenkins team and the Hudson team), it comes down to what your dev environment looks like. If you’re in an Oracle-heavy company, Hudson may work best for you. If you’re not, consider Jenkins. Jenkins seems to have more active dev going on right now. Both solutions are integrated with Eclipse and are heavily Java oriented (although not to the exclusion of other technologies).

Jenkins is also open source, in very active development, and has a strong community of developers and contributors. Because Jenkins is a fork of Hudson, the interface is similar, and much of the core code remains the same (although Hudson 3.0 has some significant changes). Without going too far into the debate (you can read more about it from the Jenkins team and the Hudson team), it comes down to what your dev environment looks like. If you’re in an Oracle-heavy company, Hudson may work best for you. If you’re not, consider Jenkins. Jenkins seems to have more active dev going on right now. Both solutions are integrated with Eclipse and are heavily Java oriented (although not to the exclusion of other technologies).

Disclosure: I am a real user, and this review is based on my own experience and opinions.
Product Categories
Build Automation
Buyer's Guide
Download our free Jenkins Report and get advice and tips from experienced pros sharing their opinions.