CloudBees Reviews

In general, as a DevOps user, I mostly build pipelines and deploy them. That is mostly used for deployment and release for our products and services. 

But with my profession, I'm more towards taking care of the service. I take care of the CloudBees service, which is used by teams to build and deploy their releases for production services.

We also use it for our own purpose, for our own build and releases. So you can say that I use it as a service and also as an admin who takes care of the service. So, on both sides.

CloudBees is a market leader in the CI/CD space. Jenkins, as a product, developed the CI/CD space, which holds a major portion of the DevOps area. DevOps is mostly CI/CD. So, you do your build and releases or automation using the CI/CD service.

That's what I like about it. It's very flexible. You can trigger your builds using multiple sources, you can integrate with multiple platforms, and you can automate your end-to-end product life cycle. You can automate your infrastructure builds using Terraform and other IAC tools. You can do many things with the CI/CD approach.

One challenge I'd like to highlight is that with CloudBees CI growing bigger and bigger, there are limitations in terms of managing old plugins and services and upgrading them with time.

There's always a priority thing that comes into the picture where you want something to be upgraded and fixed, but it all depends on how the priorities are set at the CloudBees side. As it is a proprietary tool, not an open-source tool, you always need to depend on the vendor. That is one challenge which I feel. It's not completely open source. Jenkins is an open-source software, but large organizations will rely more on proprietary software. 

And hence, you need to depend on them to manage the releases for their services, for their products, like for their plugins or for their features or whatsoever. So that is one thing which I feel is lagging a bit. But, overall, it's a great tool. It's a great service.

I have been using it for past six years. 

I had a couple of experiences when we went to upgrade the service. Sometimes, the plugins won't be compatible. Sometimes, some portion of the service won't be compatible with the new version, and it breaks. And when it breaks, you reach out to the support. That also comes as a new kind of error or bug at the support point of view, then it takes time for resolution.

And to be very honest, the rollback approach of this product is not that great. That is one limitation which I have, and I've faced it a couple of times with the releases.

I would rate the stability a six out of ten.

It's scalable. But, obviously, there's a limitation in terms of the number of jobs you can host. It's mostly based on the number of jobs you can host on a particular tenant. 

When you go more than eight thousand or ten thousand, which is the maximum that you can go through, the product specifies that you cannot go more than 6,000 to 8,000 jobs per host. If you go more than that, the service will get synced, it'll not be good, and it will be too slow.

That is one limitation. You cannot scale vertically on a single tenant, but you can scale horizontally with multiple tenants and scale the job. That is feasible, but it all depends on how the customer manages their infrastructure. So, there is that limitation in terms of managing instances on a single tenant. But, that completely depends on your architecture.

Scalability from one to ten, I'd rate it a seven out of ten, with ten being highly scalable. It's not really a product drawback, it's completely based on how your usage is and how your architecture is defined.

In my organization, it's approximately 6,000 developers using it across 200 tenants. So, it's a large-scale deployment.

Our company has a partnership. We have multiple orgs within the organization, multiple departments, that use Jenkins or CloudBees. In my department, I'm taking care of that.

The customer support is good. You get good representatives from CloudBees to help you and understand your requirements. They're really approachable, and you get value for money.

But there's room for improvement as it's all about priorities. They need to set some priorities, understanding the user's point of view, rather than just focusing on backlogs. It all depends on user satisfaction, which comes when the user's requirements are fulfilled. But, it obviously takes priority assessment and metrics gathering on the product side. But overall, it's good. It's decent.

Positive

It's worth it.

It is expensive for sure. But we go through ULA licensing, so that's something that is a bit cheaper compared to small-scale organizations. 

I would recommend it. CloudBees is based on open-source Jenkins. So if the users have already experienced open-source Jenkins, then they can go for CloudBees to gain that support, that customer and product support. 

So far, it's been a great tool and a great service, and it's good for agile and maintaining DevOps practices. There are other open-source software also coming into the market, but it all depends on preferences. And if you need good product support, then CloudBees is a good option.

Overall, I would rate it a seven out of ten.

CloudBees is a user-friendly tool.

I think the pipeline design we had on CloudBees was not very intuitive. There were a couple of reasons for this. The first reason was the way we went about merging our code. When we have code, we would just put it on GitLab. Realistically, GitLab already provides CI/CD pipelines. We shouldn't be using CloudBees because it's a third-party source we don't need.

We started realizing that CloudBees was not the right tool for that. The problem with CloudBees is that when you merge it, the pipelines would randomly fail multiple times. The failures wouldn't be related to a test that we would have.

It became such a huge problem that pipeline issues became a whole other domain that we would end up exploring through different developers. Because of that, we're actually moving away from CloudBees now and looking into just making GitLab pipelines.

I rate the solution’s stability a five out of ten.

We scaled the solution, and it's a major part of the company. Since tons and tons of products are using CloudBees, I don't think it has a problem with scalability.

I've worked a bit with the deployment of the pipeline. I don't want to say I made my own pipeline, but I merged two repositories and made my own pipeline out of them. It took me almost a week's worth of work and a lot of random failures here and there.

The setup will not be too complicated if you have good knowledge of it. It wasn't that easy for me because I was still like an intern who had just started.

I wouldn't say anybody can use the solution. CloudBees is a user-friendly tool, but it's a bit confusing to navigate in certain places. It wasn't confusing, but it was a bit unintuitive. On the other hand, the GitLab pipelines we started migrating towards were significantly more user-friendly.

The solution's integration with other tools is fine, and I rate it a six out of ten. We integrated with GitLab, and it was fine. We did have a lot of problems, though, and we would have people working until past midnight trying to fix those. It was kind of a problem on that end. It was getting the job done eventually, but it had many ghost problems.

People would end up waiting for weeks to merge perfectly good code just to make it work for this pipeline that was having problems. It was very annoying from that standpoint.

I don't think there's any actual problem with CloudBees. Our problems with CloudBees could have been specific to our code, development practices, and how we used the tool. At the end of the day, it's not about the tool itself, but it's about how you use the tool. There may be a problem with the way we were using the tool. I think CloudBees is still good.

At the end of the day, it did get the job done for a lot of things. I have to give it credit where it's due. I would recommend CloudBees to other users. In my opinion, having a third-party pipeline when your repository already provides a pipeline doesn't make any sense to me. If GitLab is providing a pipeline, use that pipeline, which is more intuitive. It's also fine if you want to use CloudBees as a secondary pipeline support.

Overall, I rate the solution six and a half out of ten.

We use a pipeline to deploy our application. All our organization checks and requirements are added to the CloudBees pipelines, ensuring code quality and checking vulnerabilities. We use Jenkins and SonarQube as part of the deployment process.

CloudBees has streamlined our deployment process. Previously, deployment involved manual file transfers and checks, which were time-consuming. Now, with CloudBees, many tasks are automated, making our work easier and more efficient.

CloudBees assists by automating tasks, previously done manually, in the pipeline setup. This saves time and improves efficiency. The features set rules that are regularly updated, reducing the need for constant oversight. One-click deployment processes also highlight the flexibility and ease of the platform.

Sometimes, there are performance issues, however, they may be due to our organization's configuration. Currently, I do not have specific improvements in mind as these might be related to our side.

Previously, our organization had an on-premise solution, but we have moved to the cloud version.

Due to security constraints within our organization, the performance can appear slow. It is difficult to discern if the issue is with CloudBees or our organization's configuration.

CloudBees is scalable, but I cannot provide specific details on how this scalability impacts us.

We experience issues with the CloudBees pipelines occasionally, like resource limits or permission errors. The DevOps team generally resolves these, and I would rate CloudBees support eight out of ten.

Positive

Before CloudBees, we used FTP for deployment, which involved no pipelines.

The setup was managed by a separate team. My experience starts with using the product, which was straightforward.

A separate team, the DevOps team, manages the CloudBees setup and any technical support needed.

CloudBees saves time and resources by executing automated deployment processes, which would otherwise have been manual and time-consuming.

I am not aware of the pricing, setup cost, or licensing details.

I have not evaluated other solutions, as my interaction began with CloudBees directly.

I would recommend CloudBees, especially to those using traditional ways of deployment, because it simplifies and automates many processes.

We use tools like BuildNow for creation and Jenkins for labeling and deployment. These tools effectively serve our CI/CD needs. While they are good tools for deployment and build levels, their time can vary depending on the code we provide in the labels.

The feature is good because when I click ‘Build Now,’ the labels are automatically created in 10-15 minutes. The build quality is also fine.

To improve efficiency, they should focus on smoother label deployment. For example, if my build has four to five levels, using the ‘Build Now’ option in the Cloudreach tool currently takes about ten to fifteen minutes to complete. Reducing this time by one or two minutes would be beneficial.

I have been using CloudBees for three to four years.

I rate the solution’ stability a nine out of ten.

15-20 users are using this cloud tool.
I rate the solution’s scalability a ten out of ten.

The initial setup is easy. I have approximately four years of experience with CloudBees and various other tools, such as Bitbucket, Jira, and ServiceNow. 

I have used Jenkins. It is a highly scalable and comfortable tool, making it an excellent choice for any DevOps developer. I recommend Jenkins to DevOps professionals because it is an open-source tool with great support and flexibility. It provides a smooth pipeline experience. It allows us to create CI/CD pipelines in the cloud easily.

The CI/CD pipeline is effective for integration and deployment processes, making it more client-centric. Jenkins is a good tool for this purpose, and despite the many CI/CD tools available in the market, such as Teradata and others, Jenkins remains a very reliable and widely-used tool.

Overall, I rate the solution a nine out of ten.

The primary use case for CloudBees is for continuous integration and deployment. It is primarily used for production deployments. We use it to trigger Autobahn, such as CloudBees, well in advance to clear out many issues upfront, trigger change requests, and test in various environments to be ready with the production deployment on the actual date.

CloudBees has helped our organization by integrating with various systems like version one, GitHub, and PDSM. It reduces the need for documentation by automating processes, saving time when creating documents and testing the application. This reduces the amount of time spent on deployments and helps pull out all the test results and create change requests, providing a more streamlined process for deployment.

The most beneficial aspect is that CloudBees integrates with everything, like version one, GitHub, and PDSM. It automates documentation and testing processes, reducing the need to create documents manually. By creating automated processes, it saves time and effort.

It could improve the document upload process. Currently, documents need to be uploaded manually to the PDSM request. An enhancement could be to have a feature where you can upload documents directly to go into the PDSM request.

For about two to three years, approximately two and a half to three years.

CloudBees has improved a lot over time. Initially, there were challenges setting it up, but once we understood its functions and processes, there were no stability issues.

CloudBees is scalable as it integrates with various complex systems and offers the flexibility to scale to many other application integrations beyond those currently used.

I have not personally interacted with customer service or support since the DevOps team handles template creation and maintenance, and they might have contacted support during the initial phase.

Positive

Before CloudBees, we did not use a similar tool. However, we are currently considering a transition to GitHub Actions.

The initial setup involved creating a template that checks pull requests in GitHub. It verifies approvals, mergers, and other criteria necessary for a build. The setup includes extensive integration with other systems, stringent checks, and a series of deployment stages from QA to production.

The DevOps team is responsible for creating templates and handling integration with various systems. They play a crucial role in supporting the implementation and deployment processes.

The measurable benefits of using CloudBees include a significant amount of time saved during deployment because of the automation and integration capabilities it offers.

I am not aware of the pricing, setup cost, or licensing details for CloudBees.

We are currently using GitHub Actions, with an effort to transition from CloudBees to GitHub Actions.

Follow the guidelines and step-by-step processes thoroughly. If you encounter integration issues with your tools, seek support from CloudBees to ensure integration. Once set up, CloudBees is a reliable tool for deployment.

I'd rate the solution nine out of ten.

CloudBees is the Jenkins tool for building and deploying. There's open-source Jenkins, which is free and can be used by any organization, but it offers a different architecture for Jenkins. If your organization is larger, you might choose the architecture. This way, you can have different masters for different applications, and different teams can manage their masters separately. However, a single person can still control all the masters, whoever manages it for the organization.

It has dynamic node allocation for the code we're building. When we trigger a build, like for Java code, it pulls a Docker image from a repository. Then, a pod spins up. If you have ten nodes, the solution uses a Kubernetes architecture. There's one master node and ten different nodes connected to the master. Whenever we trigger a build, a pod spins up and gets scheduled on any of the slave nodes in the Kubernetes cluster. That's the best thing I see about the product. 

The management is good. You don't need to manage different nodes individually. You don't have to specify which node to build the code on. In CloudBees, you can avoid that. You mention the node, and it will automatically schedule the pod on whichever node is free.

You can also configure different nodes. Another good point is that you can configure Elastic File System to store the data.

The setup is somewhat complicated. You need a cloud architect and engineer to set it up properly. The initial setup will take time, so you need a good engineer and architect to handle it.

I have been working with the product for three years. 

I have no issues with the tool's stability. 

I find the product scalable. Currently, we're using a Kubernetes architecture and working on-premises. However, other teams are working on the cloud version of CloudBees with AWS infrastructure. There, we can also scale the nodes.

I'm currently working for an organization that has over 200 applications. They've adopted the CloudBees architecture. So, these 200 applications have 200 different masters. All of this is managed by a single team, which is a separate team. The different applications and different members are managed by a single person who oversees the entire organization, similar to how we have it in AWS.

The tool's support is good. 

Neutral

I don't think CloudBees requires much maintenance, but some things must be considered. As I said, they have a Kubernetes architecture, so Kubernetes patching and Jenkins patching will also be required. It publishes upgraded versions on its website. You can purchase the latest license and upgrade the Jenkins version through that purchase.

I rate the overall solution an eight out of ten. 

We use CloudBees for deploying the code in higher environments, such as QA, C2, staging, and production.

CloudBees has made deployment faster compared to on-premise solutions. It also facilitates working with multiple machines, improving efficiency and performance.

I find the automation feature most valuable. CloudBees is highly scalable and supports both small and large teams. The deployment process is also faster when compared to on-premise.

There are connection issues with CloudBees, specifically between Sybase and CloudBees. We often encounter connection problems, and there are issues with the pipelines.

I have been working with CloudBees for one and a half years.

There are a lot of connection issues with CloudBees. We experience disconnections frequently.

CloudBees supports the deployment of large amounts of data efficiently across multiple machines.

I haven't gone through the technical support, so I can't comment on it.

Positive

Before CloudBees, we were using Jenkins on-premises. We switched to CloudBees because we moved our SQL servers to the cloud, which made deployment easier.

The initial setup of CloudBees took approximately fifteen to twenty minutes.

We used UrbanCode deployment to deploy it in different environments, but I was not directly involved in the implementation part.

I am not aware of the return on investment metrics for CloudBees.

I am not sure about the pricing, setup cost, and licensing for CloudBees. The team takes care of it.

I am not aware of any other solutions that were evaluated before choosing CloudBees.

I would recommend CloudBees to others because building jobs is much easier than with other solutions.

We are running over 200 applications in CloudBees. We integrate different DevOps tools like Vault, SonarQube, Nexus, Nexus IQ, and Ansible with CloudBees. We use the tool to create multiple pipelines, like multi-branch pipelines, declarative pipelines, standalone pipelines, and parameterized pipelines.

We upgrade CloudBees on a time-to-time basis. We create the Docker images and push them to Harbor using CloudBees. We also create nodes like the Ansible and Docker nodes to run the images on that particular node. For the dot net application, we configured the Windows slave machine on CloudBees.

CloudBees's user interface is very simple and user-friendly. If anyone knows a little bit about CloudBees, they can understand it better regarding where to go, how to go, how to create a pipeline, and what parameters they have to configure. Users don't have to dig too much. They just need to log in, and everything is there for them to read and operate.

I noticed that CloudBees runs too slowly because some applications run more than 50 pipelines. When we try to open it, it takes too long and shows an error message saying the service is unavailable. While raising a case with the vendor, the vendor asks us to share the support bundle logs for the pipeline. When we try to download the support bundle logs, it still shows me the service unavailable error.

When we tell the support team about our problem, we don't get the exact solution. The same issues keep repeating, and they ask us to upgrade the plug-in for many issues. However, upgrading the plug-in does not help fix the issue.

We are facing some issues for which we have tried everything, but it hasn't been fixed. The support team told us to upgrade the version to fix those issues, but I don't know whether that was correct.

Neutral

The solution's initial setup is simple for someone who knows CloudBees well.

We have an option called configuration management in the cloud. We have installed a Vault plugin and mentioned the Vault URL and the token in the configuration management. Using that, we have integrated CloudBees with Vault. For SonarQube, we installed a SonarQube plugin and then mentioned the URL, username, and password. Using that, we integrated SonarQube with CloudBees.

I would recommend the solution to other users. New users should see the plug-ins and features, regardless of their version. When you try to implement CloudBees in your environment, you should build the infrastructure based on how many applications CloudBees can support and how many pipelines you will run on those applications. This prevents CloudBee's performance from becoming slow.

Customers will get upset and give bad reviews if the solution's performance worsens. Users must keep these things in mind before implementing CloudBees in their environment.

Overall, I rate the solution an eight out of ten.