CloudBees Reviews

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 started with the continuous integration product and have now adopted continuous deployment for my current projects. We have a cloud-based product for other environments, like our dev environment and one of our CAT environments. These are the two environments we are using right now. Initially, we mainly used CloudBees for continuous integration. Now, we are utilizing both CloudBees for continuous integration and CloudBees CD for deployment.

When a build starts in CloudBees, it progresses from continuous integration to continuous deployment and monitoring. These are the three areas we're focusing on. We have successfully onboarded over 150 applications, which allows us to gather deployment and CI/CD pipeline metrics. We also have a dedicated service template for different application types, such as Java with Maven, .NET using MSBuild, and Node.js. 

We use CloudBees for continuous integration, deployment, and monitoring. We also started leveraging CloudBees CD Analytics for enhanced metrics and insights.

We deploy several applications using ECS and EKS, enabling us to achieve blue-green deployments. This allows for rolling updates and changes, benefiting many of our customers.

Another important aspect is our analytics capabilities. By leveraging these analytics, we can identify areas for improvement and increase our deployment frequency. We can predict trends and forecast business needs.

We are a centralized team that provides all the CI/CD and automation best practices for our internal teams. We chose a cloud-based product because it allows for end-to-end process automation. Using Cloud-based CI and CD, we can achieve effective release orchestration, enabling us to plan new releases efficiently.

One standout feature is build promotion. With this feature, we can promote builds across different environments with a single click, simplifying our workflow significantly. Additionally, we can easily identify where errors occur at any stage, making it straightforward to resolve issues.

Our automation supports not only on-premises deployments but also integrates with cloud solutions like AWS, GCP, and Azure. This flexibility allows us to deploy in both on-prem and cloud environments.

When I started with CloudBees, I found the configuration at the CD level to be quite challenging when creating end-to-end orchestration or release execution flows.

If industry-standard templates were available—based on surveys of what other companies are doing with their deployment models—it would simplify the configuration process. Collecting this information and providing standardized templates would make it much easier for teams to configure and use the platform.

Most of our configurations were done manually. On the CI side, customization options or APIs could improve the experience when dealing with Kubernetes execution or pod template configurations. 

It would be beneficial to integrate AI solutions like ChatGPT into our CI and CD processes. Many distributed networks and CI tools, like GitLab, are adopting such integrations.

I have been using CloudBees for three and a half years.

When we started using cloud technologies, we faced initial challenges. We initially opted for CloudBees and later integrated CloudBees CD. We encountered setup and stability issues at that time, including connectivity problems and occasional downtimes. The system is now running smoothly.

It's scalable because we've deployed it on high-throughput servers, allowing for efficient operation. The applications can be deployed without any interruptions.

We have 200+ users using this solution.

When we interact with the CloudBees team, we utilize the CloudBees University for support. This platform provides access to technical expertise, and if we need customized solutions, we can reach out to CloudBees representatives through the university.

Positive

When I started working with CloudBees, we focused on creating service catalogs. Given that we have over 2,000 components and applications, we follow various deployment strategies, including ECS-based, SAML-based, and Windows IIS-based deployments. Each of these requires specific template configurations.

We also explored blue-green deployments involving customized configurations we've implemented externally. While I’ve noticed some templates already available, expanding the library of deployment strategy templates would be beneficial. Adding templates for Tomcat, WebLogic, WebSphere, and Node.js deployments would enhance support for our diverse solutions.

Once we onboard an application, we hand off the maintenance and deployment responsibilities to the application team. Our role is to provide the initial solution and support them in getting started.

We have a team of twenty. It takes us one or two days to onboard a new application. This efficiency is due to our well-defined templates and process documentation. When a new application team approaches us for their DevOps journey, we can onboard them quickly, often within one or two days, with an end-to-end solution.

We assess their current deployment setup. If it aligns with our existing processes, we begin onboarding immediately. If not, we work with them to create a suitable deployment model. We have a solid understanding of our major deployment procedures, which allows one person to establish a complete end-to-end solution in about a day.

Once the application is onboarded, the application team takes over the entire release flow. We’re available to provide guidance and support if they encounter any issues or need training.

Even with full automation, some level of maintenance is necessary. Currently, we have a dedicated SRE team to handle this. Our DevOps journey with CI/CD involves a combination of various tools, not just the CloudBees CD product.

Some applications are heavily dependent on GitLab. We are currently focusing on migrating a few of these applications and building them directly on GitLab.

I recommend this solution for smaller projects or teams, as it can be quite effective for them. For those seeking a consolidated CI/CD and comprehensive metrics solution, CloudBees CD is an excellent choice.

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

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.

I worked on the DevOps team and was responsible for automating build and deployment processes. My focus was on the automation side using CloudBees. Our CloudBees Jenkins instance was used globally by around 8,000 developers. We created numerous templates because CloudBees offers additional benefits over the open-source Jenkins.

One key advantage was the enterprise support from CloudBees, which was extremely helpful. Whenever we performed upgrades or needed assistance, we had support from the CloudBees team, which was valuable for leveraging the features CloudBees provides, such as template creation.

We developed templates for various build types, including Python, PyPI, NPM, and Maven. Developers used these templates for their builds and application onboarding. Our CloudBees instance had a high-availability architecture integrated with security tools like SonarQube and Checkmarx. Additionally, our builds were containerized and managed on OpenShift, which helped streamline agent management and regular cleanups.

CloudBees's assistance was crucial, especially with features like template creation and the fully cloud-native architecture that CloudBees offers.

Integration with other tools was generally smooth, but we encountered some issues with version mismatches. For example, if the CloudBees Jenkins instance was on one version but a plugin was on an older version, upgrading the plugin often required an upgrade to the Jenkins instance. This dependency sometimes caused delays, so we had to be cautious with the plugin and Jenkins upgrades.

We did face some challenges, particularly with the infrastructure. Our CloudBees Jenkins instances were deployed on virtual machines, and we experienced downtime in production environments. This downtime was often related to infrastructure issues rather than problems with CloudBees itself. CloudBees' team consistently advised us to maintain a robust infrastructure and ensure high availability to mitigate these issues.

I have been using CloudBees for seven or eight months.

I rate the solution’s stability an eight out of ten.

Scalability largely depends on how the tool is set up within your infrastructure. It’s crucial to configure scalability, availability, and fault tolerance for banking customers who often use on-premises setups. The effectiveness of CloudBees in these aspects will depend on how well the infrastructure is managed and set up to meet these needs.

The support team was excellent. They consistently adhered to their SLAs and KPIs and were very responsive during outages. We had several meetings to address issues, and they were always helpful in resolving any problems we faced.

Positive

The initial setup depends on your application's specific requirements and nature. CloudBees provides the tool as a vendor, but how effectively you use its features depends on your team's technical skills and how well your application integrates with the automation tool.

Sometimes, we had to make adjustments to ensure compatibility with CloudBees. Initially, we had to thoroughly review documentation to understand the additional features CloudBees offers beyond open-source Jenkins.

We had to implement many customizations because CloudBees offers significant flexibility in CloudBees Jenkins. While Jenkins is consistent globally for automation, CloudBees Jenkins is essentially an enhanced version of the open-source Jenkins with added enterprise support.

Relying on open-source solutions alone isn't practical for industries like financial services and healthcare due to their need for enterprise support. CloudBees effectively addresses this need. Jenkins remains one of the most widely used CI/CD tools, and with CloudBees providing robust enterprise support, many organizations continue to rely on it.

I've advised using Jenkins because it’s well-supported and reliable. From my time at Oracle, where we used open-source Jenkins, I experienced firsthand the challenges of inadequate support in open-source forums. Delays in resolving issues could impact deadlines and customer satisfaction. For industries like banking, healthcare, and finance, having enterprise support is crucial to avoid such problems and ensure smooth operations.

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