It has drastically improved our workflows and the speed of our troubleshooting
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.
- Leave a Comment |
- Mark review as helpful
It has easy connectivity for getting our pipelines into the cloud on AWS
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
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?
I could lose my entire Jenkins infrastructure all at once and it could reconstitute the entire environment directly from code
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.
Provides consistency throughout our entire environment
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.
showing 1 - 5