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.

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.

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.

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 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 had a couple of projects we were working on. Much of it has to do with the combination of a recently acquired brand over at our parent company, and we were considering consolidating our cloud platform and our domain. We were also looking at moving applications from one team to another so that we could leverage them.

We also want to increase our production automation. That may have been the most leveraged part of that. There were a lot of teams, and they were doing a lot of work. It was causing levels of concern, confusion, risk, oversight, and over-expenditure.

We were looking at various applications, and CloudBees was selected so that we could consolidate and combine all of our efforts. We wanted to reduce the number of tools we were using to help deliver and standardize a lot of our processes and procedures.

The solution's most valuable feature is its flexibility. I like how CloudBees functions and how it can communicate and message progress. I like how it can be containerized, and developers can use certain aspects of it without interjecting. They can have a target audience where they can review their progress before it gets integrated into the larger scale of things.

To use the tool, you need to be familiar with the tool itself and with how it will be incorporated into the culture.

I have been using CloudBees for about a month.

I haven’t faced any issues with the solution’s stability.

I have no issues or complaints with the solution’s scalability.

We had just got to the licensing part of CloudBees, signed up, and got ready to use it. We were going to apply it to a couple of our projects, but our project was put on hold due to budgetary constraints. We really didn't get much further on the tool other than doing some independent research and studying it.

To use the tool, you probably need to do some onboarding. To use the tool, you need to be familiar with the tool itself and with how it will be incorporated into the culture. You have to be familiar with those who use it and those who get reports or information from it. The solution is worth the money.

Although CloudBees may not be the tool for everybody, I would definitely recommend that people review it and see for themselves how it can help them.

I would ask a new user to look at the main website and understand what this tool has to offer. I would also ask them to do some independent research. There are a lot of YouTube videos out there that could help break down or containerize the information they might be looking for.

They should talk with individuals who have used the tool before and get their impression. They should sign up for the free trial and see what they think about it. There are several different ways to go.

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

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.

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 are using it for continuous integration and continuous deployment purposes.

It can manage multiple Jenkins instances. In standard Jenkins setups, you're typically limited to a single master configuration. However, with CloudBees, you can partition the system into multiple Jenkins servers, allowing each team to have a dedicated instance. This is useful when dealing with high workloads. Instead of relying on a single worker node, you can distribute the load across multiple worker nodes, improving efficiency and performance.

If you're logged in and working for about thirty minutes and then go idle for five to ten minutes, Jenkins will prompt you to re-authenticate. You need to enter your user details and password again. This reauthentication requirement is a drawback. We contacted CloudBees support to extend the idle time, but it didn't work out as expected.

On the other hand, we receive efficient support from the technical team. Whenever we face an issue, whether it's related to user accounts or backend problems, we get a prompt response, and they're actively working to resolve these issues.

I have been using CloudBees for four years.

We haven't faced any issues like breakdowns, except for one instance during a version upgrade. We made some mistakes while upgrading the version, which caused a brief issue lasting about two minutes. Other than that, we haven't encountered any significant problems. When we were upgrading the version, we made some mistakes, which led to issues. However, the technical mobile team helped us revert to the previous version. Later, with their help, we successfully upgraded to the latest version.

There were no issues with support. Based on the license purchase, you'll receive a prompt response. It might get some delays, but not usually.

If you choose to use the regular Jenkins, you won't receive official support if you encounter bugs or issues. This can be challenging, especially when working on large projects for big organizations, where accuracy and reliability are crucial. Using open-source tools without support can lead to difficulties in maintaining uptime. To address this, we opted for a licensed version, like CloudBees, which provides strong support from their tech team. CloudBees has a robust master-slave architecture, which enhances project efficiency.

The initial setup is easy. We have been using the Helm package manager for installation purposes.

If you're using CloudBees for the first time, you might find the Helm process confusing. You need to understand how Helm operates in real time. It's essential to maintain a separate override file and a values.yaml file. If you need to change any values, you'll modify them in these files accordingly. While the setup might seem confusing initially, it becomes much easier to use once you get familiar with the tool.

If interested, you can try out CloudBees with a free trial, typically lasting about 15 days. This will give you hands-on experience with the platform, and you might find its features quite appealing. Unlike standard Jenkins, CloudBees offers additional packages and features unavailable in the regular Jenkins distribution. I recommend giving it a try, as exploring new technologies can be beneficial. The availability of free trials makes it a great opportunity to see what CloudBees offers.

CloudBees is quite easy to use as a beginner. It operates similarly to Jenkins, with some additional features and options available. You might notice extra functionalities and configurations, but it's quite similar to Jenkins overall. I recommend trying out the trial version to get a feel for it.

I rate CloudBees as nine out of ten. The client tech team has been very responsive, and their support has been excellent. We have split our development across multiple teams—eight in total. Instead of overloading a single Jenkins server, we've distributed the load. We are running CloudBees on a Kubernetes cluster, with eight nodes handling the workload. The master manages these nodes efficiently.

As a consulting company, I implement CloudBees for our customers to standardize and globalize the use of Jenkins. This helps in providing automation for DevSecOps by automating pipelines and controlling them. 

Additionally, I use it for traditional development projects and a security audit product, which provides ROI by automating audit processes.

CloudBees helps streamline DevSecOps by automating pipelines and providing standardization and control, thereby enhancing the efficiency of my clients. The security audit product offered by CloudBees is particularly beneficial in automating audit processes, which reduces the time developers spend on audits.

The most valuable features of CloudBees include its scalability for large teams and complex pipelines, advanced security features, and extensive integration with various tools. It also offers application delivery automation, pipeline release orchestration, compliance, and audit features, and provides visibility into deployment processes.

There could be improvements in the ease of use. A better GUI instead of code-based interaction would make it more accessible to a broader audience. Additionally, incorporating more AI features in the future could enhance usability as AI becomes more advanced.

I have been using CloudBees for approximately two and a half years.

CloudBees is very stable. Issues usually arise when recommendations aren't followed, such as overloading the server.

CloudBees scales excellently. There are no significant limitations, and it can be expanded as needed by adding more servers.

CloudBees customer service and support are very good. They respond quickly, and the support quality is commendable.

Positive

I have not extensively used alternatives because I'm more involved in managing implementations rather than being a developer. However, I acknowledge that there are alternatives available in the market.

The initial setup of CloudBees is straightforward if you have the right personnel. The integration of pipelines is what requires more time and effort.

A team approach is generally needed within a corporation, involving multiple people from different departments like developers, scrum masters, architects, and SysAdmin personnel to handle installation, setup, and integration.

The licensing model of CloudBees opens up a true ROI, especially with their security audit product. It offers significant benefits by targeting the DevOps process from a security audit standpoint.

The licensing model is considered good, and while CloudBees is not cheap, it is worth the cost because of its extensive benefits. The core product and security audit product in particular provide substantial value.

There are alternatives to CloudBees, such as those offered by GitHub and Amazon. In my opinion, CloudBees leads in integrating with Jenkins, and competitors are behind in this aspect.

My advice would be that before starting, align all groups required for the project to avoid delays. Plan which teams and pipelines to target first, especially since large companies have thousands of pipelines. Detailed project planning and resource alignment are crucial to moving quickly.

I would rate it an eight out of ten.

We use the product primarily for automation tasks. It handles various processes that don't require human intervention, making it a crucial part of our workflow.

One recent product feature that stands out is the pipeline explorer, which is providing significant value for us right now.

The platform could integrate better with other tools and support external tools directly.

I've been using CloudBees for about five years.

Over time, we have encountered product performance issues at large scales. However, at small to medium scales, there are no issues at all.

Overall, I rate the stability an eight. 

As long as you follow the vendor's recommendations on scaling, the platform performs well. Adapting to more complex organizational challenges outside those recommendations could be better. However, the support team does their best to handle the issues. 

I rate the scalability a nine. 

The VM-based infrastructure setup is easy. However, Kubernetes-based setup is difficult, even for experts who find bugs and report them back to the vendor.

To effectively use the platform, you need to know Jenkins, as the product is essentially a layer on top of Jenkins.

It's a powerful and flexible system, but it's important to implement proper guardrails from the outset because making systemic changes down the road can be difficult for your organization.

I rate it a nine out of ten.