CloudBees Reviews

I work for a client. We have a CloudBees-based infrastructure, a microservice-based infrastructure. To deploy the applications, we have around 200+ microservices.

To deploy all those microservices within different environments, we use CloudBees. We use it for deployment purposes. We use Docker, Kubernetes, and all those kinds of things. To integrate all those features, we use CloudBees.

The master-slave Jenkins structure has improved overall deployment efficiency. In other places, we have to keep waiting for the nodes to be available, but I haven’t seen that issue with CloudBees, which helps us do our deployments faster.

Other than that, the availability of plugins is very helpful. We can easily integrate multiple tools, and the authentication process is also very easy. We can use SSH keys, usernames, and passwords. There are multiple things we can do.

Also, the kind of logs we get. If an issue occurs, we can easily find out what the issue could be. These things are very helpful.

I haven't encountered any compliance issues with CloudBees. They update their features frequently, so if we need something like SSL login, they enable it. If we don't want to allow username and password login for all users, we can manage that easily within CloudBees. 

I'm very positive about CloudBees because I've been using it for a long time and have never had a negative experience. It aligns perfectly with the compliance requirements of any organization. I've worked for multiple clients and it has always met their needs.

The easy availability of all the plugins is the most valuable aspect. When I use any other open-source tools, there are multiple options available similar to CloudBees. I found it a little difficult over there because I have worked on those as well, such as GoCD and IBM. Integrating multiple tools was a bit challenging. With Cloudbees, I found it very easy. 

Also, the use of Jenkins files and integrating Groovy scripts is beneficial. When you create a pipeline, you can easily create the Groovy script automatically. That feature is very beneficial as it reduces stress and makes the work easier. These are the main features I like.

We are in development of an AI tool. In CloudBees, we basically use Groovy. There are multiple other tools available, like those present in Google, where you can create the Groovy code automatically. But I work for Cognizant, and we are in the process of creating a Groovy generator where we can generate our Groovy code. This will take care of client compliance more perfectly. We are in progress of doing that. 

Also, there is an initiative in the market, which is "low-code, no-code" development, where organizations are reducing their dependies on code to minimize the possibility of errors. We are exploring the creation of an AI-based tool that integrates with Jenkins to facilitate this low-code approach and further reduce the likelihood of failures.

We can create such a tool and integrate it with Jenkins to reduce the amount of code needed, thus decreasing the possibility of failures and errors. We're thinking of something like templating the CI/CD pipeline. If CloudBees offered something like this, it would be even more beneficial.

I would like to see improved speed and availability. It's much faster nowadays, but that could always be improved. 

Other than that, it's quite easy to understand. I've seen development teams get confused when using other open-source CI/CD tools, but Jenkins' options and features are very clear and easy to access.

Most people are dependent on Jenkins these days, and they have their pipeline as code. I would like to see this functionality within CloudBees so the pipeline code (the Groovy file) can be generated automatically when we provide the variables or requirements. This would make things much easier. 

People already do this within AWS, Azure, and other platforms, but we don't have such a feature in Jenkins. If we could add that, it would be a significant improvement.

I have been using it for seven years now. 

We have seen stability issues very rarely. Sometimes, one or two times in my whole career, I have seen issues after an upgrade where our nodes are not able to come up. But that’s very rare. So, I have never faced any significant issues with CloudBees.

It is scalable. We have a Microsoft-based infrastructure. So we have to scale and contract it very frequently as per the requirement. And we do that, and it responds in a very good way.

We have a very big infrastructure. It has around eight environments. We use microservices, and some of our pipelines and environments are for other teams because the output of our application is used as input for another application. Some of our environments are for other teams. We have Dev, Test, Pre-Prod, Prod, but a few other environments are for another team that uses our application. They need a separate infrastructure for testing because they don't want our work to be interrupted. So, we have multiple environments.

So, I would rate the scalability an eight out of ten. 

Many times, some plugins or other components have become corrupt and stopped working. Our pipeline would start failing without providing any clear errors. We've contacted tech support numerous times, and because we're using the paid version, we get responses quickly, and they resolve the issues fast as well.

I've worked for multiple organizations and multiple clients.

The con about CloudBees is Groovy coding aspect. Learning Groovy is a different skill that you need. That's why I asked if they could create a code generator like Google's, which would be beneficial. That's one of the cons.

On the pros side is that the UI is very understandable, even for beginners. The freestyle jobs, the plugins they have for everything, the easy installation and integration of multiple other tools, and code-based logs are all pros.

I've worked on multiple kinds of projects. In some cases, it was very easy, where we just integrated Git, did the checkout, then integrated Maven, created the build, integrated SonarQube and ran the test cases, integrated artifacts with Nexus, stored them there, and then directly ran the deployment script. 

I've also worked on more complex environments, where we do all of that and more. 

In my current scenario, we handle deployments to multiple environments with a single pipeline. We have the whole pipeline code written in Groovy and reduced our dependency on freestyle jobs. When it comes to microservices, the infrastructure changes completely, and there are multiple microservices and pipelines. I've worked on a variety of infrastructures, from basic to extensive.

If it's a single monolithic service, it's very easy. You can do it within a day or two. But our infrastructure is microservice-based, and we have a lot of old Groovy code, so it took a lot of time. However, it's more dependable now. We've enabled multiple features and such.

Usually, it takes one or two days, but it can take longer, depending on your needs. If you want to enable all the features of CloudBees, it might take six months or more because you have to write everything in code.

Usually, we don't do any maintenance. Maintenance is typically handled by CloudBees as far as I know. We only do cleanups.

For example, if there are a few pipelines that are no longer needed or there's too much load on our CloudBees server, we clean things up. That's the extent of our maintenance. We don't do any other kind of maintenance.

On average, three to four resources are needed for the deployment process, depending on ISD and ESD, because some of our deployments, such as production, happen in ESD. We had US clients, so we utilized ESD resources at that time - two resources from ISD and two from ESD. This allows us to handle deployments in lower environments or other tasks. 

The developers are usually from the US, so we need two DevOps engineers there to support them. So, on average, four to five resources are enough to handle both ISD and ESD at all times.

ROI is good. It's much better. That's why we've been using it for the last eight years, across multiple clients and organizations. Everyone uses it, so I believe the ROI is good. That's the only reason they use it. Otherwise, there are multiple competitors, and they would have chosen another one.

I would recommend CloudBees to other users who are looking into implementing it.

I would recommend that if users have a microservice-based infrastructure, they should have some engineers who are proficient in Groovy scripting. They should also know the deployment procedures and the steps involved in deployment.

So, once you know the steps, I don't think implementing it within Jenkins is tough, but you should be aware of all those things. Groovy is the most important part; you should have a very good knowledge of it. That's the only con that Groovy is only used in Jenkins. Other than that, it is not used anywhere.

Overall, I would rate the solution a seven 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.

We have five or six client controllers, referred to as ClientMasters, each serving a different region. For instance, we set up a client controller for the Europe region, where we manage multiple scheduled jobs.

With CloudBees, we handle everything end-to-end, including installation, configuration, maintenance, and pipeline execution. These pipelines deploy our applications on Kubernetes. We also manage user access within CloudBees, using RBAC to define roles and responsibilities.

Admins can access the operation center and all client controllers, while project-specific users only access their designated controllers. This setup ensures a structured and secure management of CloudBees resources.

CloudBees is used as a CI/CD pipeline. It is similar to Jenkins but offers a more seamless and user-friendly experience. It’s easy to use and well-suited for managing your CI/CD processes.

CloudBees operates seamlessly. Deploying to a cluster is straightforward—just one click, and the job is done. The logs are precise, and vendor support is excellent. They offer prompt assistance, often through calls, to resolve any issues.

A notable feature is their premium support for customers. For instance, if we have a license for 300 users, the billing is handled at the start of the year. If we exceed this number slightly, CloudBees will be flexible and will not impose excessive charges for a few additional users. This flexibility is particularly useful around renewal times or when user counts fluctuate.

Everything works well with deployment, application management, running jobs, and pipelines, and RBAC is effective. However, one area of concern is tracking license usage. With a ProCloud license, for example, there's no centralized console to monitor how many licenses have been used. This lack of visibility can lead to untracked consumption and potentially overshooting license limits.

Additionally, we use the UAM plugin, but it doesn’t provide details on when users were added. This lack of tracking features is disappointing, especially given our status as a premium CloudBees customer. Better tools for monitoring license usage and user activities would be beneficial.

We've noticed occasional issues with folder permissions changing unexpectedly. Specifically, permissions sometimes shift from the CloudBees user to the root user. This can cause pipeline failures, as pipelines require the correct CloudBees user permissions to execute properly.

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

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

It's scalable. 500+ users are using this solution.

Support has cleared all my queries on time.

Positive

It is quite expensive.

I would advise you to understand your environment and familiarize yourself with CloudBees and its terminology. It is crucial to gain a clear understanding of each term and concept on the control panel. Once you get the hang of it, exploring and using CloudBees becomes quite straightforward. It took me a couple of days to get up to speed with CloudBees, and I found it easy to navigate after that.

Overall, I rate the solution a nine 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.

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.

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. 

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.