- 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.
It is essential for software development and team collaboration. Without this tool, we would be helpless.
Immediate feedback on build errors, regression.
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.
Sometimes, out-of-memory problems, but lately this has not occurred often. Sometimes there are obscure Java errors which are hard to understand.
No issues.
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.
I used CruiseControl but this died.
Very easy setup which has even improved over the years. Now I use Docker. Installation of plugins is also very easy.
It is a free product.
BuildBot and CruiseControl.
Don't forget to look into the plugins. It's not only Jenkins but also the plugins which make it a very valuable product.
In this solution, you can write scripts and put job parameters in them with time and dates when to activate. We can create a web book that is automatically configured. The automated elements are easy to use and you can put them into your server. Additionally, there are plenty of plugins available. You can use the plugins to push your code into a target or container. There are many features available in this solution.
The scriptwriting process could be improved in this solution in the future.
I have been using the solution for one and a half years.
The solution is stable.
We have not had any issues with scaling the solution.
I have previously used Bamboo and it is really easy to use, user-friendly, and the UI well designed. The control output of Bamboo is highly interactive for the user.
I have also previously used Sonar but it is a lot different than this solution and Bamboo.
The solution is one of the lowest costs compared to competitors.
When selecting a solution I would advise checking their budget, the volume size they are performing, and what full-stack they are performing on. Based on this information, they can better determine what solution is best for them. If they have a low budget this solution would be great for them.
I rate Jenkins an eight out of ten.
Potential deployment problems pop up almost instantly during the development process. The developers are more confident about their committed code.
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.
I've used it for six months.
There were some issues with deployment.
There were some issues with stability.
There were some issues with scalability.
No other solution was used previously.
It wasn't complex.
We did it in-house.
It's infinity as the developer's happiness are endless.
It's free.
We did not do a deep evaluation but we did look at Bamboo.
Stay calm and mind the gap between your QA automation team and developers.
This solution is the primary component for our automatic release process, including code smell, integration, and deployment.
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.
There are a large number of plugins available for integration with third party systems.
The user interface could be updated a little. I think that a REST API is needed to expand the integration capabilities.
We used it for all continuous integration parts, like automation testing, deployment, etc.
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.
The interface.
Yes, in Jenkins v.2. However, I am guessing that is because we used it right after the first release.
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.
It was enough for me.
No, I did not.
As I remember, there was just one command on Linux. Pretty easy.
It is free.
I didn't choose, but in my opinion, this is the best open source solution for CI and CD.
Nice functionality, but does not have a very user-friendly interface.