- Run automated tests with release pipeline.
- Run tests against different environment.
- Manage selenium grid.
- Integrate with slack, browserstack and AWS.
- Run automated tests with release pipeline.
- Run tests against different environment.
- Manage selenium grid.
- Integrate with slack, browserstack and AWS.
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.
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.
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 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.
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.
Customer Service:
I have never used them.
Technical Support:
I have never used them.
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.
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.
When I moved automation tests from TeamCity to Jenkins, I did not experience any difficulties, but I have learning curve for circleCI.
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.
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.
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.
It's more structured, using naming conventions.
It's very useful when you want to automate different processes from beginning to end.
Maybe centralized user management. (We are not using all the functionalities of the product).
I would say it's a quite stable system.
As I mentioned, we are not using all the feature of it, so it's very easy to scale it.
It's free software with a big community behind it, which is very good.
No previous solution.
It's pretty straightforward. Use apt-get to install Jenkins, and then there is just some minor configuration work.
Some of the add-ons are too expensive.
No. When I started, Jenkins was broadly used.
Start with Jenkins as your first CI solution.
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.
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.
Upgrading and maintaining plugins can be painful, as sometimes upgrading a plugin can break functionality of another plugin that a job is dependent on.
No issues.
No issues.
Excellent.
No previous solution.
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.
Jenkins is open source.
We explored other open source CI tools like Travis CI and CircleCI.
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.
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.
It improves our release. It makes the release faster by adding an automated deploy and automation tests.
The bug fix speed is very slow.
More than six years.
Some plugins have critical bugs and are not able to be used.
Most of time, Jenkins is works well. But when you scale up, you need an administrator to manage Jenkins.
You need an internal admin for Jenkins.
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.
Yes. CircleCI and TeamCity.
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.
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.
