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.

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.

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.

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.

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.

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.

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.

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.