Sign in
Categories
Migration Mapping Assistant Your Saved List Partners Sell in AWS Marketplace Amazon Web Services Home Help

CloudBees Core

Survey after survey shows Jenkins® is the most popular open source automation server - and for good reason. However, Jenkins alone often lacks what teams need as continuous delivery scales across an organization. CloudBees Core extends Jenkins with functionality that embeds best practices, supports... See more

Customer Reviews

9
Create Your Own Review

It has drastically improved our workflows and the speed of our troubleshooting

  • By SeniorSofcae
  • on 01/16/2019

We use it primarily for the commercial support, and there are some plugins which make integration and scripting a little easier on the commercial side. Our primary use case is being able to call somebody and know a lot about Jenkins. However, we don't pretend to be Jenkins experts, since we are not Jenkins coders. We can just call somebody and have assistance instantly, which is the reason we chose to use CloudBees. The support is there when you need it.
We have not been using it that long. We have only been using it for a little more than six months. It was a migration from Jenkins to CloudBees, which was seamless.
How has it helped my organization?
Prior to using CloudBees, if we couldn't figure something out, we would try to figure it out. We would waste a couple hours, or weeks, on some particularly hairy issues. It slowed us down. We had more people focusing on our build management systems than we had focusing on using it, in some cases.
CloudBees drastically improved our workflows. If something didn't work, we could have it working again. We weren't spending time troubleshooting and Googling for stuff. E.g., "We know this guy had a similar issue. We will contact him and see what he did about it."
When we hit a barrier, we hit a barrier. We had to almost guess and feel our way in the dark at how we could get around it. Now, we still hit barriers. While there are some cases where we submit an issue, and they say, "Give us a couple days to look at the particularly issue, because it is a hairy issue." It always comes back with an answer. Importantly, it's access to an entire company of knowledgeable people.
While we can't abuse these relationships, we can call them and know that they aree there. We pay for it. and they are okay with us calling them. It's a different thing than, "Well, I know Bob, so I will call Bob." I can't call Bob every week.
The benefit is support and the speed that it provides for troubleshooting.
What is most valuable?
All its technical features are valuable, but we could do 90 percent of those with Jenkins. The difference with CloudBees is when one of those features doesn't work, we can't figure it out, or it doesn't work the way we expect to there is somebody that we can contact who can make it work.
What needs improvement?
CloudBees has a lot of features. It has a core product with some special build stuff and purchase, which is great, but where they can improve is around the messaging. We use it for support, but a lot of our clients could possibly use some of the other features around it.
As an example, the Kubernetes skew stuff. A lot of people are just using the plugins for Jenkins, but it's not clear to a lot of our clients why they need CloudBees, because it's a hidden away thing. E.g., you are using the internet, but you don't usually think about what it takes to keep it on. In a lot of cases, the people making the purchasing decisions don't understand why Jenkins isn't enough. "Why do we need that? My team knows Jenkins." Great, your team knows Jenkins, but they don't know all of Jenkins. They know the pieces they use, which is fine. They shouldn't know all of Jenkins, because that's not what they're meant to be doing. They're meant to be using it for coding, etc.
I still find the messaging really confusing. It's not immediately clear what the value-add is yet. It's not clear enough to pitch it in an easy, prepackaged way. If you already know their ecosystem, it's easy to figure out. However, if you don't, you have to learn their ecosystem first. The guys who are making the purchasing decisions are usually not the ones who will take the time to learn the ecosystem. If we had to justify the solution less, then we could just slide them some information which would be simple to consume. This would make our lives a lot easier.
For how long have I used the solution?
Less than one year.
What do I think about the stability of the solution?
I have not noticed any stability problems. No crashes come to mind, but we have not been using it for an extremely long time. We may eventually see issues, but I don't think so. We have found them to be stable, and previously, we found Jenkins to be stable. I imagine things will continue to be stable.
What do I think about the scalability of the solution?
In terms of the scalability aspect, some of our customers do a release every two weeks. They roll up on the small side of approximately 30 different containers into a release and deploy to a couple environments, then rollout a week later. Other clients are doing 50 releases a day, because every time that they modify code, it builds something new. They are deploying into an environment per developer, an integration environment, and end-to-end.
This is partly a test of the scaling's usability. However, we haven't seen an issue. Our biggest environment has about 50 active users with about a couple hundred different services being built. We've occasionally had to resize a VM and give it more resources, etc., but we have not noticed any blockers where we can't move faster. Sometimes, we have to give it more horsepower, but beyond that, I can't think of a case where we've hit a wall.
I think we have hit the upper maximum on what we will ever need in terms of scaling. Their license model makes it easy to break out from that. If we need to break up projects into multiple build systems, that's fine too. I don't see any hidden scalability issues.
How is customer service and technical support?
A lot of our team who speaks with their technical support are heavily technical. Traditional support is used to dealing with the managers or an IT department. Development doesn't usually call support, because they tent to want to fix it and discover it themselves. I have noticed a lot of our developers are comfortable calling CloudBees, or speaking to them in general, whether it be on Slack, email, or calls. They tend to work alongside you, so it feels like a colleague helping you with your issue, more than it does just some random person. At heart, they are a group of developers too.
Everyone who has spoken with them has said that they interfaced well with our development team. The main people who are calling them on a case-to-case basis have found this really nice. We have great interaction with them: It's not an us versus them. When we call them, they are temporarily part of our team. They come in, and they help us, then they go away after. However, they are right there when we need them. This is a completely different model than a lot of other software solutions.
Which solutions did we use previously?
Because it is Jenkins, ultimately in the core, all of our Jenkins plugins with it worked. That was a big boon. Usually, when you switch to a product, you have re-evaluate everything. We didn't. We just moved our plugins over. Everything just worked, and where it didn't, they helped us fix it.
How was the initial setup?
The initial configuration and integration was seamless. We migrated from Jenkins. As we had originally done our built in Jenkins, except for the fact that it was a slight version upgrade, it was seamless to move over to CloudBees. All of our integrations continued to work.
What's my experience with pricing, setup cost, and licensing?
Their support model is a recurring model. It is not a one-off fee. We pay on a yearly basis. We are already gearing up to justify our user license count for next year. When it comes time for renewal, we will have to tell all of our projects and customers why that cost is there. While we will be able to justify it, I feel like if they could add more information that it would make it easier for us.
I can't tell you if we purchased it direct or from the AWS Marketplace.
Which other solutions did I evaluate?
We had already done an evaluation of Jenkins versus other products, such as CircleCI and a bunch of the other ones, and we had already settled on Jenkins. When we moved to CloudBees, at that point, it was a question of open source, which we're fine with, versus commercial support. We needed the commercial support and had already settled on Jenkins. We were comfortable with Jenkins features and just needed the support.
What other advice do I have?
We use it for everything from from building a container to deploying a container, and in some cases, for kicking off environment creation. It integrates well with other products in our AWS environment. The core concept is fully scriptable. We do use it to integrate, and it is infinitely integratable with everything in AWS.
It depends on what product that you want on CloudBees, but if you want the support or core stuff, it's absolutely a no-brainer to just go to CloudBees. You don't have to change much at all.
It's like when you have a cell phone, and you buy the same brand on a newer version. You do the WiFi sync, then all your pictures, contacts, and everything else comes over automatically. This is the same thing. If you're on Jenkins already, and you're happy with it and not looking to move products, just needing support and additional features, CloudBees is a no-brainer. I wouldn't even evaluate other products. I would just look at them.
If you're in the mood to just look at products similar to this, I would suggest installing a few of the big commercial ones. If you're working at CloudBees, you're obviously into the commercial side of it. This means that you will be looking at things, such as CloudBees, CircleCI, and a couple of the other big ones, depending on what features you need.
The unfortunate things with build systems and a lot of code bases is you can't fully implement them as a test, because of the amount of hours, especially if you're switching (though not in all cases). If you're switching it can be a huge time sync to implement to evaluate. If you pick a simple project, there are a bunch of GitHub projects which are meant to sample applications for learning build systems. Install one of those and use all the systems on that one and get a feel for what they offer you.


It has easy connectivity for getting our pipelines into the cloud on AWS

  • By ProjectA10de
  • on 01/14/2019

The primary use case is CI/CD.
How has it helped my organization?
It has improved our pipeline automation. It has been there from the initial phases, just manually deploying everything that we need to by doing the builds. It does all the sanity checks to having a completely automated pipeline. This is where we sit now. It has been there all the way along the road for us.
It does everything that we need it to do for our team.
What is most valuable?
It works. It has easy connectivity for getting our pipelines into the cloud on AWS. We have no complaints, as it has always done what we wanted it to do.
What needs improvement?
Nothing is perfect, and there is room for improvement in the product. I am reserving judgment for the unknown.
For how long have I used the solution?
One to three years.
What do I think about the stability of the solution?
Our team does not put much stress on it, but it's a shared instance. I'm sure enterprise-wide that there's a lot of stress. Teams are constantly building and deploying, but it works seamlessly for us. We don't see any performance degradation.
What do I think about the scalability of the solution?
It is being used enterprise-wide. We have never had any performance issues. It does what it's supposed to do.
How is customer service and technical support?
We have not used the technical support.
From an organizational perspective having technical support available, even though we haven't needed it, is definitely a nice thing to have rather than rely on the open source community as a whole for a baseline product like Jenkins. It is worth the money to have that support available when you need it.
Which solutions did we use previously?
We were using an open source version of it, Jenkins. When we found out it was available enterprise-wide and a license already existed, we transitioned into it.
How was the initial setup?
The integration and configuration of CloudBees in our AWS environment was pretty much plug and play. We have admin rights anytime we need to plug into a new service. We just download a plugin, and it spins up and works.
What's my experience with pricing, setup cost, and licensing?
Pricing must be fair because we just renewed our license a couple months ago.
What other advice do I have?


Gives devs granular access to what is required rather than a generic login with broad access

  • By Aimee W.
  • on 01/13/2019

We use it with software development of FMCG e-commerce websites.
How has it helped my organization?
It allows us to continuously deliver new builds quickly.
Also, devs at different levels can get granular access to whatever is required rather than getting a generic-style login that gives them access to large sections. This provides an audit trail for mistakes (not for finger-pointing but just to learn from them).
What is most valuable?
* Ease of access control (granular)
* Scalability
* Analytics
What needs improvement?
It can be slow producing Beekeeper reports but I think this was ironed out in a later release. (It was a multi-thread issue).
There are a lot of features, so some really good learning materials in various formats would be handy. I know there are a lot of webinars, but more high-level resources would be great for new staff; we all had to start somewhere.
How was the initial setup?
AWS makes it simple to use most products, as that’s its bread and butter: "Whatever you want to use, we can provide you with an environment." And it's the same with CloudBees. It’s no different to loading into a server in a back room, offshore, near-shore, virtual environment, etc. We didn’t have issues setting it up to run in a container on a Linux machine.
It's super-simple to start a stack, bootstrap, IAM role, SSH key pair, command-line updates, etc. These are fundamentals of AWS anyway.
What's my experience with pricing, setup cost, and licensing?
We chose to procure this solution via AWS Marketplace because the devs are a load of button-pushers so they are always trialing software on AWS to see how we can leverage AWS’ flexibility, scalability, and granular pricing model. Also, it made sense for us to use this as we had multiple clients. We got great control out of our builds this way.
What other advice do I have?


It provides better visual reporting for the data

  • By DevOpsMa22d9
  • on 01/08/2019

We use it for migrating and scaling Jenkins infrastructure.
How has it helped my organization?
It provides better visual reporting for the data, whether it succeeded or failed. It also has a lot of plugins.
What is most valuable?
* It has a wide variety of plugins.
* It has a good reporting solution.
What needs improvement?
The integrations with Kubernetes has become challenging when it comes to scaling on a machine. We don't have the proper agent release to do this.
For how long have I used the solution?
Less than one year.
What do I think about the stability of the solution?
We haven't had any stability issues.
What do I think about the scalability of the solution?
We don't have any scaling issues. We have about 400 servers with three Jenkins masters.
How is customer service and technical support?
I would rate the technical support as an eight out of ten. We are receiving constant support from the cloud-based support team.
How was the initial setup?
With Kubernetes and the cloud-based configuration, it is a little tricky. We are still trying to figure out the best way to do it.
What was our ROI?
We have dedicated Jenkins masters for our different teams. This way, teams are not stepping on each others toes. They can build something and it is ready, then export their jobs to the main master.
What's my experience with pricing, setup cost, and licensing?
They need to improve the licensing. With a few of the companies, when you have the agent installed, once the instance dies, you are released from the license. However, with cloud-based, you have to contact the cloud-based support to release the license and map it to the new instance.
Which other solutions did I evaluate?
We looked at Jenkins and Bitbucket Pipelines. Since our developers were already used to the Jenkins infrastructure, we continued building on top of our previous platform using the cloud infrastructure.
We had been using Jenkins for the last six years and wanted to continue with the same type of infrastructure.
What other advice do I have?
I would recommend this product rather building your own homegrown solution.


It was easy to integrate into our AWS environment, but it needs scripting in other languages.

  • By Jose F.
  • on 12/25/2018

We use it for CI/CD (continuous integration and continuous delivery).
How has it helped my organization?
It does continuous deployment and development. Plus, all the ways that it does deployment into the various environments.
What needs improvement?
It needs scripting in other languages and support for it.
For how long have I used the solution?
One to three years.
What do I think about the stability of the solution?
We put a lot of stress on the product, as it is used every day for development.
What do I think about the scalability of the solution?
We have between 100 to 200 engineers using the product.
How is customer service and technical support?
I have never used technical support.
How was the initial setup?
It was easy to integrate into our AWS environment.
Cloudbees also integrates with Bitbucket.
What's my experience with pricing, setup cost, and licensing?
We chose to go through the AWS Marketplace because of scalability.
Which other solutions did I evaluate?
We did not evaluate any other products.
What other advice do I have?
Play with it a lot before you do anything for real.


I could lose my entire Jenkins infrastructure all at once and it could reconstitute the entire environment directly from code

  • By CEO2961
  • on 12/19/2018

It is used for CI/CD, and where we work in the federal government, CI/CD is not proliferated quite as extensively as it is in the private sector and startup community. Therefore, CI/CD is still an important message in the government, and Jenkins is a big part of that message.
How has it helped my organization?
Its CI/CD capabilities are invaluable to the government. Typically, the government manually builds software, then manually deploys that software onto a machine. With Jenkins, it hooks into AWS and its ability to deploy directly to operating systems. We are able to not only automate infrastructure in AWS with Jenkins, but we are able to do the actual delivery of our software on operating systems and instances themselves.
What is most valuable?
* Its scalability.
* Ease of use.
* The community and support available for it.
Its ability to recreate our entire Jenkins environment, jobs, and seed jobs from code. Therefore, I could lose my entire Jenkins infrastructure all at once, and it could reconstitute the entire environment directly from code.
What needs improvement?
Sometimes on a heavily used Jenkins instance, if we are not scaling appropriately, we can have a lot of job failures without a whole lot of information telling us why jobs are failing, if we don't know that it's a performance issue. This is sort of expected out of the open source product, and I understand that the commercial CloudBees product has a lot more insight and tools to help you see these things ahead of time before they become issues. So, it is the nature of using the free open source version, and we just have to be a little bit more diligent.
We would like a little more native automation in the cloud spaces that there in.
For how long have I used the solution?
Three to five years.
What do I think about the stability of the solution?
We put an extreme amount of stress on it. All of our developers in the federal agency that I work for use Jenkins on a daily basis to do their jobs. We support about a half dozen teams right now, and we're looking at doubling that number very shortly.
We have had no infrastructure nor stability problems with the software.
What do I think about the scalability of the solution?
The scalability is outstanding. We can scale entire Jenkins boxes, which helps us scale our builds, our delivery, and our executors.
The size of the environment that we operate is anywhere from 300 to 500 EC2 instances at a time between development, test, and production. Jenkins is our primary orchestrator for all of them.
How is customer service and technical support?
The community is fantastic. The Jenkins technical support community on Stack Overflow is wonderful. We absolutely love it. Since we are on the free, open source, we don't necessarily get access to their private community and other commercial forums. However, the open source community has been fantastic for us.
Which solutions did we use previously?
We switched to Jenkins because it is so powerful.
How was the initial setup?
The integration and configuration in our AWS environment was very easy. It was very fast to get started.
There are a 101 tutorials out there to tell you how to do exactly what it is you want to do. It is free, fast, and easy. If you don't know what you're doing, the community is exceptional.
What was our ROI?
The amount of time that it takes to build software, test it, pass the testing, and get it deployed onto a server instance has dropped for a developer to do all these processes from about a day to a couple of minutes. Where we previously had a developer who might only have only been able to do one build, deployment, and test per day, they can now do dozens before lunch. That is the ROI. We're able to bring software to the government faster because of Jenkins.
Which other solutions did I evaluate?
There were some Atlassian products, like Bamboo, which we considered. We just didn't like their licensing model. We didn't like the lack of flexibility in some of these tools. Jenkins is the easiest CI/CD tool to start with.
What other advice do I have?
Always to pick what's best for you and your environment. Jenkins doesn't work for everybody. Try it first, give it a shot, and let it prove itself that it doesn't work for you, because there is literally nothing that you can't custom build in Jenkins. If it doesn't do something that you want it to do, you can write your own module or capability in it. The tool is very flexible.
We have been using the CloudBees open source version of Jenkins for about four years now. It's a fantastic product. It doesn't do anything that we need it to do. We absolutely love the product.
We have deployed this product in other environments, such as on-premise and other clouds. Amazon allows us to scale Jenkins and manage Jenkins in a more effective manner than deploying on-premise or on other clouds. We just use the open source version and haven't really dabbled in the different flavors.
We use Ansible to automate a lot of our infrastructure components that we might not be able to do with some other tools. We also integrate Jenkins with SonarQube for static code analysis and Nexus Repository for our object and binary repositories. It integrates beautifully with all of these. We are able to orchestrate deployments, testing, and everything from Jenkins. We used Jenkins to kick off our Ansible automation and have it do all of our automation.


Our clients can spin up all the containers that they want and shut them down as needed

  • By LeadDevO65cb
  • on 12/18/2018

Our primary use case is we use it for our deployments and our CI/CD pipelines. Then, we allow our developers to take control of their environments.
How has it helped my organization?
It simplifies our entire process because we used to have to do everything manually every time a new client came on, every time a new build came on, or we wanted to launch a new product. We would then have to go through all the work manually, where now it is just a very automated, simplified process. It has made our licensing and our licensing tracking significantly easier because it is all right there in our account.
What is most valuable?
The ease of use as far as getting it up and running, especially now that we have hundreds of applications wanting to go online and wanting their own built. We simply hand clients a CloudFormation template, and say, "Here is your account. We put the restrictions on your account. You can take care of yourself. If you don't like it, we will destroy and rebuild it." This allows us to focus on working with the developer on developer issues, not having to sit there and work through all the problems which come with setting up a pipeline, then setting up a Jenkins server, setting up GitHub hooks, and setting up everything else. It has helped us to really simplify our process.
What needs improvement?
The one thing that CloudBees Enterprise Jenkins does not do well is backup. We have to create our own backup systems in order to manage it, because our clients like to store thousands of jobs in their build histories. The problem that we have is that takes up space. We have to then back these up and get them out of the main system. We need a better integrated backup solution, which also can also do pruning in it and have time constraints with retention and restore.
I would like to see a more click-through, automatic creation of AML files. Sometimes, we give guides for developers in order to do things, but not all of them are familiar enough with AML, as they are Java developers. They are not familiar enough with some of the concepts that Jenkins uses. It would be nice to have more click-through where they could just select pieces.
For how long have I used the solution?
Three to five years.
What do I think about the scalability of the solution?
It is extremely scalable. We go over it with our CloudFormation template, and our clients can go ahead and select their scaling capabilities. They can spin up all the containers that they want, and shut them down as needed, so it is one of the more scalable products that we have used.
We make a lot of use of the AWS infrastructure when it comes to AWS Auto Scaling and automatic deployments. It allows us to package it up and make a set thing. Then, using CloudFormation, it allows us to make an AWS environment with CloudBees Jenkins Enterprise. This is something that our developers can to launch by themselves.
We have anywhere from 1000 applications to 2000 applications deploying on it at any given time.
How is customer service and technical support?
The few times that we have needed technical support, it has been great. There have been very few problems with it to begin with. The times that we have run into an issue, it was just been a matter of opening a CloudBees ticket, then working with CloudBees through emails usually to get it resolved. Nine out of ten times it was resolved within one or two contacts.
Which solutions did we use previously?
It used to take weeks for us to:
* Get Jenkins up and running.
* Get the GitHub integrations going.
* Get all the permissions set up.
* Get the hardware provisions.
Now, instead of it taking weeks to do this along with the approval processes alone (which was just a nightmare), we now say, "This application team needs their environment set up," and we hand it to them. It has changed from a three to six week process down to a one hour approval process deciding whether an app team is allowed to do something or not. We just hand them their template and the product does what it needs to do.
How was the initial setup?
The integration and configuration of this product in our AWS environment was easy.
It integrated with GitHub, which was a seamless integration. There is the Jenkins plugin that we use. We use also Pivotal Cloud Foundry, and there is a plugin for that, which we found seamless to integrate too.
What was our ROI?
It has simplified our lives so much. It has reduced our time from three to six weeks for deployment down to just a few hours. In doing so, it has freed us up to do the important stuff that we need to do with developers.
What's my experience with pricing, setup cost, and licensing?
Purchasing on the AWS Marketplace was easy. We don't worry about licensing and keeping track of it. We don't worry about negotiating contracts. It just happens. We get the bill, which is billed to our account. It is very painless.
We chose to use the AWS Marketplace for the simplicity of being able to allow our developers to just launch it and its availability in all regions. Through the AWS Marketplace, you point the region that you want your development in, and it works.
The AWS Marketplace pricing is on par with going directly to CloudBees. It's always nice if it is cheaper, but it's on par. This is not a pain point for us.
Which other solutions did I evaluate?
We considered solutions, like TeamCity, GitLabs, and a built-in CI/CD. We looked at a bunch of other little solution, but because CloudBees had the enterprise support, this set it apart from all the other solution that we looked at. Plus, everyone already had familiarity using Jenkins to begin with.
What other advice do I have?
Use the AWS Marketplace. Going through the AWS Marketplace makes life ten times easier, and you can be so hands off of it.
Go for Jenkins, as it is the industry standard and everyone knows it. There are a million plugins available for it. I see no other reason to go with anything else.
We put a lot of trust in CloudBees. The enterprise version of the backup that we have with the CloudBees support team is the extra that they put on top of it which the open source version of Jenkins doesn't have. The extras really help solidify it and make it a true enterprise solution. As opposed to the open source version of it or the free version of it where we sit there and struggle with it thinking, "Alright, how do we get support for this? This person ran out of disk space." We don't have those problems with this because it does have scalability built into it that the open source doesn't have.


Provides consistency throughout our entire environment

  • By Hamzah M.
  • on 12/16/2018

For our organization, we are using the enterprise CI/CD build tool. We have been using it for about a year on the CloudBees platform. Before that, we were on the open source Jenkins.
What is most valuable?
Their plugin support is its most valuable feature. Since it is open source, having a company backing these plugins and supporting them all the way throughout their lifecycle makes it easier for us to use it.
What needs improvement?
It being the only company or tool that provides you enterprise support with Jenkins, we don't have other options, and we're sort of stuck with it.
For how long have I used the solution?
One to three years.
How is customer service and technical support?
Once in awhile, we'll reach out to technical support because we have something in a DocPress container, and we have run into some issues there. Their support has always been helpful for us.
Which solutions did we use previously?
Before CloudBees, we had about 40 to 50 Jenkins instances. There was no management on them. Each one was running different versions. There were no one master nodes and spin up. Our support worked really hard because everyone was running different versions, types of build tools, and versions of plugins. When we got CloudBees, we obtained the consistency of everyone having one master and the multiple nodes all being the same. From the support side, that was the biggest part for us.
How was the initial setup?
In our AWS environment, we have Jenkins integrated with our GitLab, which makes it really easy. Once you check in your code or building on a pull request, it will automatically do our build, then we also use either GitLab for deployments, Ansible Tower, or UrbanCode. It integrates with all of those as well.
What was our ROI?
I think we will see return in investment in a little while once we start seeing all the teams transitions over to the product.
What's my experience with pricing, setup cost, and licensing?
From our viewpoint, the price point is high for the product. It goes by a "per developer" price. Being an open source tool, and having their plugins being created on a stable platform, it is very highly priced. That is the only downside to it.
Which other solutions did I evaluate?
There aren't many companies who have an enterprise platform for Jenkins. Therefore, we were sort of left with CloudBees. However, they are also the industry trend. If you have Jenkins, and you want an enterprise-ready version, you will go with CloudBees.
What other advice do I have?
* You need to figure out how big your enterprise is. Because when you go to CloudBees, spinning out multiple nodes, you need to be able to have the infrastructure to back up all of those nodes, even if it is in AWS.
* I would take a look at different build tools. If you have GitLab, it can also build. Even though it is not a fully integrated plugin, you can save a lot of money for your enterprise.


It provides an all-in-one product, but the installation documentation is hard to find

  • By Lester M.
  • on 12/12/2018

We use it for pipelines and CI/CD.
What is most valuable?
The product is all-in-one.
It is based on Kubernetes, and we will be going to cluster, which is better.
What needs improvement?
The initial setup and its compatibility with LDAPS needs improvement. It took us a long time to get it configured, which caused us some issues. Some of the settings of the configuration were causing issues along with our on-premise, e.g., firewalls, and its integrations with other tools.
I would definitely use their Professional Services to install it, especially with the Kubernetes clusters. There are a lot of underlining configurations that would be hard to find out about in the documentation.
It is hard to find documentation, even their professional services on some of the issues were having a hard time finding it.
For how long have I used the solution?
Less than one year.
What do I think about the stability of the solution?
So far, so good. We have not had any issues since it has been up.
We are putting about a 50 percent workload on it right now.
What do I think about the scalability of the solution?
The scalability has been good so far.
We have only been in AWS for about three years. We have about seven applications running in production mode right now and that is continuing to grow.
What other advice do I have?


showing 1 - 9