Google provides a service similar to Jenkins called Cloud Build, but we'd have to purchase it because it's not open source. And since it's provided a GCP service, it's on the cloud. Most of the features that Jenkins offers is are available GCP. However, the server infrastructure is managed by GCP, so we don't have the flexibility to configure and change many things about the way the system works. 

There is a set of features available to us, and we can put some parameters in place to make it work. But the problem is that Cloud Build isn't very flexible in terms of its configuration. We have the same issue with AWS CodeDeploy, another service like Jenkins.

Most of the configurations we do have already been set by the cloud provider. Let's say Jenkins asks us to configure five to 10 things, and the cloud provider only asks us to configure one or two. Again, the problem is we do not have the option to customize. 

What's more, GCP or AWS services for CI/CD pipelines are tied to the other services in the cloud. For example, AWS has its own source control system called as CodeCommit. CodeDeploy is connected to it and another service called Pipeline.

You can fluidly orchestrate code with minimal administration or configuration. All changes you make on CodeCommit go through the workflow by just inputting the scripts. You don't have to do a lot of configuration like you need to do in Jenkins. AWS takes care of all of that. You can put some approval process to see if the build has succeeded. You need someone to go in and approve it before it's deployed. All those things can be done that aren't possible in Jenkins.

I am not aware of the available options in the market right now compared to Jenkins, but I am pretty much happy with the service that Jenkins is providing our company.

I use CircleCI, which is a platform-as-a-service solution. Since I left HPE, I've used App Actions, and I would prefer either over Jenkins.

We also use Bamboo. Bamboo is more difficult to use than Jenkins. Jenkins is better with respect to networking.

Jenkins was the first product I used. Apart from Jenkins, there are other tools I've used, like Bamboo. Then, specific to the cloud, we have other DevOps services, and other pipelines.  I have used multiple options. Still, I'm kind of a Jenkins fan. I definitely recommend Jenkins over other tools.

I have previously used GitLab and Azure DevOps tools. I have found them both to be more complicated than Jenkins and this is why I switched. I am more familiar with Jenkins and this is another factor of why I use it.

Jenkins' main advantage over other solutions is multiple plugins and ease of setup. Open-source and secured versions are also available, so maybe that's why there are multiple processes. Other deployment tools cost more, and the setup is messy. These are some reasons management decided to use Jenkins instead of other solutions.

I've also used Bamboo, which is a bit more user-friendly. It has good integrations and licensing.

I was previously using Ansible.

The only competitor to Jenkins is Argo CD for Jenkins. We are not using it yet.

The approach is now changing to GitOps. People are moving towards the GitOps rather than the old DevOps model. That's where the Argo CD or Flex comes in as alternative tools that are picking up interest in the market.

We have previously used an FTP server and we would copy and paste the files manually. I still prefer to use Bash scripts directly and deploy using SSH, or there are situations where we will not use an application because it would be overkill for such a simple deployment. We continue to use alternatives alongside Jenkins because sometimes it is pointless to build an entire Jenkins job just for deploying a website.

We wrote our own custom scripts before Jenkins. 

I did not use a solution other than Jenkins.

Prior to using Jenkins, we were using Maven. We decided to switch because of the cloud enablement and the continuous integration.

No previous solution.

I have not used another solution prior to Jenkins.

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.

We have previously used Bamboo. I use both Jenkins and Bamboo per our project requirements. Jenkins is more suitable for commercial projects and is more scalable and flexible as compared to other tools because its core focus is on integrating and updating automatically.

I have previously used Bamboo, but it is a smaller solution than Jenkins.

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.

We didn't have any solution in place previously.

No previous solution used.

We were using another solution from Automic.

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

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

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.

We previously used Hudson, and CruiseControl.

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.

We upgraded from Hudson which is similar.

We used GitHub.

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.

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.

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

We did not use another solution previously.

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

No previous solution.

I used CruiseControl but this died.

No other solution was used previously.

No, I did not.