Jenkins Reviews

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

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

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

Since 2009. At that time it was called Hudson

No. Deployment easiness is one of the advantages of Jenkins

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.

No

Never had a chance to communicate

Never had a chance to communicate

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

Setup is pretty straightforward

Both in-house and vendor

It's free. There's no advice required

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

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.

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.

Two years.

No stability issues.

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

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

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.

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

We went directly to Jenkins.

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.

I can build slaves and extensions through plugins.

Automation in general has been improved.

Provisioning of VMs during deployment.

Five years.

Provisioning VMs during deployment was an issue.

No issues encountered.

No issues encountered.

Not needed.

Not needed.

We previously used Hudson, and CruiseControl.

Initial set-up was straightforward.

We implemented in-house.

We compared Jenkins to CruiseControl.

It works.

Jenkins is used for triggering my test automation. I use Selenium WebDriver for test automation.

The most valuable features of Jenkins are the ease of use and the information about how to use the features is readily available on the internet. Additionally, with the solution, I can use other reporting tools, such as Flow.

Jenkins could improve by adding the ability to edit test automation and make time planning better because it is difficult. It should be easier to do.

I have been using Jenkins for three years.

Jenkins has been stable in my usage. However, I have had colleagues say they have had stability problems. They experienced these problems after six months to a year of use.

We have approximately four engineers using Jenkins and they use it as needed. It could be weekly or monthly.

There is not any support for the solution since it is open-source. However, you can find all the information needed online.

For triggering I use Jenkins, but for local systems, I used Selenium WebDriver. Additionally, I have used Cypress.

The initial setup of Jenkins is in the medium-difficult range.

Jenkins is a free solution, it is open source.

I rate Jenkins a seven out of ten.

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

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

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

The upgrades need improvement.

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.

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.

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.

They should improve the Version Control tracking system in Jenkins.

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.

• 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).

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.

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.

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.

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

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.

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.

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

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.

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.