CloudBees Reviews

Deployment and other processes are feasible for me, making this a smooth process. The integration part is good. We can use multiple things by integrating with CI/CD pipelines, and this is very feasible for us. This allows us to do our work easily. The productivity is very good. CloudBees is a good and efficient tool. We can work in client-facing scenarios, and since clients have provided these types of tools, we are able to work on them effectively.

For CloudBees, I can suggest that the log is very high, which is very hectic for us when trying to find which error is coming. This creates complexity. If possible, we could sort the logs so we can get the exact error on one page.

I have been using ServiceNow for the last five plus years.

This is dependent on our JAR files and other code elements. If the code is large, it takes more time. If the code is less, it takes a short time. The deployment can take a couple of hours or a couple of minutes.

We can upload the JAR file and deploy at the Jenkins level during our deployment. These types of labels and IDs can be deployed using CloudBees. Once we click to start the build, it automatically runs and automatically outputs the result, showing whether it succeeded or failed. If anything failed, we can check the logs in CloudBees, which is very interactive. I would rate this review 9 out of 10.

I use it for CI/CD. Majorly for continuous integration. We have around 2,000+ project teams using it. My team actually manages 2,000 Jenkins instances.

It’s the feature management that’s very good, wherein you can visualize the whole pipeline as well as the other tools that are integrated with Jenkins. That’s a very good feature, which gives you a visualization and a brief overview of where your workflow gets stuck and where the actual cause is. 

It’s a very good tool for auditing your project pipelines as well. Since you have 2,000 instances, it becomes very difficult. So that’s a really good feature, which I really admire about it.

With respect to this monolithic Jenkins, it mostly involves a lot of integrations, wherein the whole pipeline integrates with Jira, where all the planning and collaboration happens, and the build happens to the agents, which are required to build your projects and stuff like that. It’s very interesting and very helpful in those aspects.

Improvement in the sense that they can do better in terms of management of logs and stuff like that because the console logs are very extensive, and that causes a lot of storage issues. That is one of the things which is there. 

Also, with respect to the traditional platform and the modern platform, many things have upgraded, and it has quite improved. But when we talk about the performance of the agents, it’s still very crucial because it’s not up to par. It takes a lot of time to provision the agent and to finish the build because of the SSH connection and the JNLP connection. 

Due to that, sometimes the agent doesn’t get provisioned. Those are some of the blockers that meet up the time in terms of administering the instance.

I have been using it for six to seven years now.

A lot of stability issues are there with CloudBees. When it goes down due to patching activity or any such kind of activity, it becomes very difficult to bring it back. 

In terms of clustering, if it’s set up on Kubernetes, it really depends on how your internal container network works. The host network has a different effect than that of the container network. So your container networks and the networking should be very nicely configured. Otherwise, it won’t work. You’ll face a lot of containers that might just be unable to communicate.

I would rate the stability a five out of ten because it requires a lot of hard work to set up Jenkins.

Scalability, I believe it’s very good. But it does consume a lot of resources.  

So it’s a memory-extensive application. You’ll need to have a good chunk of resources based on the kind of setup you are doing in your enterprise.

For scalability, once you set it up, it’s easily scalable. So I would rate it an eight out of ten.  

There are around 5,000 end users in my organization. 

The initial setup is not straightforward. It’s a difficult setup because it requires a lot of understanding in terms of clustering. 

So what kind of clustering do you want to take it to and the initial planning, like:

• What is your scope of Jenkins? 
• Is it an enterprise-level Jenkins you want to create, or per team, you want to create? 
• How do you want to create it? 

It really depends on those, and then you would try to set it up.

Users need to have Java experience, which is really good. Java or Groovy is required in order to use Jenkins. 

Apart from that, users need to have a deeper understanding of how Maven works because otherwise, users won’t be able to build the projects. So Maven is the key to build your C++ or Java projects.  

It’s a very good product. So I would really recommend that.

My recommendation: If you want to start your DevOps journey, start with Jenkins. CloudBees, even at a smaller team level, you can integrate your Jira and your deployments via Jenkins and Ansible as well. It’s a very good tool for your app deployment. 

In terms of setting up at a smaller scale, you’ll be able to make it work with three to four nodes at a basic level. So it’s a really good investment.

Overall, I would rate it an eight out of ten. It's a very good tool. 

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.

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.

We use it as one of the DevOps tools in continuous implementation. We use the tool for continuous deployment. There are two parts to the tool: continuous integration and continuous deployment. We work for continuous deployments of applications. We have multiple pipelines in our environment and multiple applications. There are about 1,000 applications within our environment. Each application has multiple pipelines and branches configured. We pull the source code from Git. There's also something called a repository. We use Groovy scripts to provision pipelines. These pipelines have multiple stages, starting with SCM checkout, build stage and Sonar scan stage. Finally, it gets deployed to a particular server defined in the code. Before we execute the pipeline, we have different environments for development and production. For development, we test by executing directly. We hand it over to the production team for production to test on the specific branches.

It is a standalone tool, so no networking is possible by itself. However, it can be integrated with multiple vendors. CloudBees, in particular, supports integration with multiple vendors and offers enterprise support, including vendor support. Whenever we encounter issues, we can troubleshoot them with their help, as they provide continuous support. They also offer monthly knowledge transfer sessions for the team working with the tool. Jenkins is a standalone tool without cluster or networking capabilities; you can't integrate it similarly. CloudBees, however, supports different networking components, such as pods, Kubernetes, and Docker, which can all be integrated. CloudBees continues to develop and release new features.

Improvements in resolution time may vary since every environment has different needs. CloudBees is still a growing platform, but it has proven to be capable of supporting enterprise-level pipelines and CI/CD requirements.  

They could increase the number of support channels to expedite resolutions or introduce a chat option similar to what Amazon and other vendors offer. A chat option would make resolving issues quickly and efficiently easier.

New features and updates in the market for tools like Jenkins and others are often developed as open-source projects. Since CloudBees is an enterprise-level platform, it ensures thorough testing for critical environments like production. While CloudBees is doing well in this regard, it's not yet adopted in all areas. We have a dedicated team for CloudBees and receive proper support whenever we deploy.

I have been using CloudBees for seven to eight months.

We haven't encountered any performance issues with CloudBees. CloudBees is hosted on a particular server, either a clustered or standalone one. CloudBees' performance might also be affected if the server's performance is impacted. CloudBees has been stable.

In our setup, the Jenkins server's hard disk, which hosts Jenkins, is used to host the NAS. The NAS contains the CloudBees files. We performed a migration where Jenkins files were copied to the NAS for CloudBees. Through CloudBees' GUI, we refresh or reload to retrieve the required files. This affects every pipeline.

Scaling can be done through the parameters we configure in the pipelines. The parameters are not limited to just one; whatever we need, we rely on plugins, and these can be integrated. As these scripts are further developed to meet future needs, scaling CloudBees becomes even more flexible. Teradata integration has been working perfectly for us.

Scalability depends on the number of pipelines we have. As the number of pipelines increases daily, the number of DevOps engineers required to handle the workload must match. This is because multiple teams are involved, often encountering issues that need troubleshooting. Multiple issues still arise even if we are disconnected, and engineers must resolve them. It depends on the environment and the current number of pipelines.

In our environment, we have almost 1,000 applications. Of those, around 45 to 50 applications are actively in use. Each pipeline is managed based on the environment, such as development or production. There are approximately 713 development pipelines, and the production pipelines are about half that number. The number of users is difficult to count, as different application teams use each pipeline. To be efficient, each pipeline requires at least one dedicated engineer, so it's typically a one-to-one ratio between pipelines and engineers.

A DevOps engineer needs some knowledge to implement CloudBees. Once they approach the CloudBees team, they provide knowledge transfer during a scheduled conference call. They share comprehensive information using reference guides, making it easier to implement. However, engineers should have prior knowledge of Jenkins or CloudCI, which is essential for a smooth implementation.

We have implemented CloudBees in Kubernetes nodes, which are basically in the cloud only. In the initial migration stage; we have it in our local NAS. There'll be a future production, and one will be more for the CloudBees.

We are primarily involved in migrating pipelines from Jenkins to CloudBees. Migration is not difficult for us, but creating a new pipeline and ensuring it matches the Jenkins setup while executing can present challenges. One of the main issues we face is when new plugins are unavailable or when application support for plugins such as Java, Node.js, or Git.js versions is lacking. If the necessary versions aren't available, it becomes a problem.

There are costs involved, but the tool is useful and worth it. While we can rely on Jenkins, it lacks vendor support in a production environment. We are solely responsible for troubleshooting issues. This can be time-consuming, and if it's a production issue, it affects production time. With enterprise support, we benefit from immediate troubleshooting when issues arise, making it a valuable feature.

If you use any plugins or whatever plugins you get, you'll have access to the latest versions of pipelines and branches. Everything, including the most recent versions, will be available. Whether it's a Java version or any other plugin, for example, if it's related to Java, they will provide the latest updates for the currently available versions.

It comes with vendor support and continuous assistance. CloudBees provides regular knowledge transfers about new and upcoming features and supports any issues that arise. For example, if new features are unavailable in the tool, we can raise a ticket or concern, and they promptly address it. They also communicate with us by scheduling calls with our tech leads to resolve any issues in real-time. Since different environments and development teams have varying needs, CloudBees ensures these are consistently met.

Similar to other infrastructure areas, it requires maintenance. Having the right options available is essential to maintaining it properly.

The core advantages of this tool are its enterprise-level vendor support and its ability to handle cluster-level and network-level configurations, which facilitate high availability in the environment—capabilities that other tools often do not provide. These are the two main pros: cluster concepts and enterprise-level support.

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

I use the solution in my company as it just packages up to create or build virtual machines and for deploying AMIs.

The most valuable feature of the solution is that its GUI is quite simple. I wasn't involved in the original setup phase of the tool. I am able to see the results in real-time feedback and the way it has been set up. You can see different steps that are going through. I suppose it is much the same as a lot of deployment tools, but I find the clarity of the GUI to be quite good.

When there is a failure or an issue, what happens now is that you check the logs, which is a good thing. I think a preview of the errors would be good just at the point where the error occurs. If you are looking or working on a strip, you can see the line, so instead of having to click through to the error and then click back when you are done.

I have been using CloudBees for a year and a half to two years. I am a user of the tool.

It is a fairly stable solution.

Several teams are using it, and I just work with a small team of two who use it. The company has hundreds of products. I imagine a lot of people will be using it in our company.

I believe whoever worked on the initial setup phase might have contacted the solution's technical support.

The solution is deployed on our company's own version of the cloud.

I guess its cloud nature was the reason my company chose it over other tools. In my company, we work a lot with AWS, which is a good match with CloudBees.

Learning the tool to begin with is important. Once you are comfortable with YAML, I think you should be fine with it. I use just some users and as many variables as I can, and it just stays in the GUI as much as possible.

I don't think it is difficult to learn because the thing with it is once it has been set up, one hardly ever needs to change it. You provide the steps required, and you can figure out where something is broken and go to change it.

I rate the tool a nine out of ten.

We use CloudBees Jenkins with Jenkins and Sonar validation for our pipeline. We use it for all microservices, web system payment integrations, and overall pipeline configurations and deployment processes.

CloudBees has improved our DevOps practices by allowing us to deploy features and fixes efficiently. It supports our business rules, security analysis, and overall deployment process while simplifying the configuration.

The most valuable features are Java features, microservice communication, payment validation, Jenkins Sonar, management master to CloudBees, Blue Ocean, JobConfig, and support.

The user interface of CloudBees is good but could be even more intuitive. Improving the user-friendliness of the interface and having simpler setup configurations would greatly benefit new users.

I have been working with CloudBees for around two to three years.

CloudBees is very stable and reliable. From one to ten, I would rate the stability a ten.

CloudBees offers high scalability. On a scale from one to ten, I would rate its scalability a ten.

Customer service and technical support are excellent. I rate the technical support from one to ten as a ten. They provide fast, simple, and efficient support.

Positive

Before using CloudBees, we used Jenkins SonarQube, Nexus, Azure, and AWS. The decision to switch to CloudBees was made for better integration and deployment capabilities.

The initial setup of CloudBees is very easy and straightforward. It takes around 20-30 minutes to deploy completely without any complicated steps.

Our configuration team handled the setup and deployment. Twenty people were involved in the deployment and maintenance processes, and they ensured everything worked perfectly without delays.

CloudBees provides a robust and efficient solution for our DevOps needs. Ensuring an intuitive user interface and simplifying the setup process can further enhance its usability for new users.

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.