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. 

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.

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.

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 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 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.

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.

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 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.

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.