How CloudBees CI Brings Enterprise Scale to Jenkins

Video Statistics and Information

Video
Captions Word Cloud
Reddit Comments
Captions
[Music] hello this is dr. wolf for cloudBees over the next few minutes we'll be talking about cloud BCI which you may know as cloud bees core cloud BCI delivers Enterprise Jenkins at scale we'll talk about some of the most common problems people have when they try to scale Jenkins and we'll look at how cloud BCI solves them we'll start though with a few numbers three goals and three unpleasant truths our first number is 15 Jenkins is more than 15 years old it is battle tested it is used everyday by hundreds of thousands of people for 10 of those years cloudBees has been helping customers scale Jenkins and make the most of this technology that large and active Jenkins community has created more than 1,600 plug-ins that means if you need to integrate a tool with your build pipeline there's probably an existing plugin that will do that for you for cloudBees customers there is the cloudBees assurance program which ensures and reassures you that the most popular of those plugins are secure and stable and safe to use in your production environment our next number and our very favorite is the number one with more than 70% market share Jenkins is the number one technology in the CI space for the open source version of Jenkins in addition to building cloud BCI Club's employees contribute more than 80 percent of the code changes to the open source Jenkins project let's talk about some of your goals I'm going to guess these are your goals because there pretty much everyone's goal the first goal is innovation we'll pretend that's a lightbulb and not a mushroom you want your employees to spend their time innovating as much as possible the more time they spend on administrative tasks the less time they can spend innovating and giving your company an advantage over the competition another important goal is eliminating risks we'll use a shield with a check mark to represent lowered risk that includes the risk of shipping buggy software it also includes the risk of not adhering to rules and regulations and compliance issues that may be applicable to your organization the last goal again one that we feel is common and non-controversial is efficiency we need to move faster than ever before we need to do more with less our competition is doing that you have to do that as well we'll talk about these goals and how cloud BCI can help you achieve them now for our three unpleasant truths our first unpleasant truth comes from our friends at Forrester they have found that 48% of all organizations have more than 100 tools in their various tool chains so if you look across the organization there are lots of tools that have to work together to automate builds and deliver software the next number is 73% also from Forrester and that's the percentage of companies and organizations that take more than three months to deliver software if you look at testimonials from cloudBees customers we'll talk about a couple in just a minute you'll find that our customers have used cloud BCI to go from delivering quarterly to month weekly daily in some cases almost hourly thanks to the efficiencies that club ECI provides our last number and to me the most troubling is the number eighty percent that's the percentage estimated by Gartner the percentage of DevOps efforts that won't scale that's because of a lack of collaboration a lack of tools that help organizations share best practices across different teams we'll talk more about that problem in just a minute as well now let's talk about how Jenkins tends to get started and the first problem with scalability people tend to run into in your organization you have a group of forward-thinking engineers they put together a Jenkins server and start using DevOps best practices that means they start shipping software that's of higher quality and they're shipping it faster than ever before the rest of the organization of course looks at this and says we need a server too so we'll have a server here and we'll have a server here and we'll have this server and we'll have this server I intentionally drew all of these with different shapes because they're all different each one has the tooling the plugins etc that each group needs to do their work there are some problems here however the first problem is the problem of hidden costs especially this is an opportunity cost because probably the best engineers on each team are keeping the Jenkins server up and running and patched keeping the latest levels of plugins installed on them and so forth that means they're not innovating so you're actually spending a lot of time a lot of money and wasting a lot of resource by keeping all of these separate Jenkins servers up and running the next problem is that there is no collaboration so if this team discovers a new way of doing things that makes them much more efficient they're not connected to any other team there's no guarantee there's no mechanism for them to share their learning to share those best practices with the other teams that is also a problem it gets back to the 80% of DevOps efforts that won't scale but the biggest problem is that we have no governance here this team being the forward-thinking engineers that they are they make sure that every pipeline running on that Jenkins server requires a code bill to include a security scan that's a best practice that's great but from an administrative point of view we have no idea that that's happening here we have no idea if it's happening on the other servers we have no oversight no control no idea what these individual Jenkins servers are doing so this is a problem we call the islands of Jenkins problem because what we end up with is lots of servers each of which has overhead each of which is completely different and we have no no policies no guidelines no governance in place to make sure everyone's doing the same thing so in response most organizations take an approach that we'll discuss on the other side of the board in a different color the other approach organizations take next to make Jenkins scale is to create a monolithic Jenkins server so we have this nice lovely server and it has a pipeline here and it has a pipeline here and it has a pipeline here and so forth basically every pipeline from every one of these Jenkins servers is now running inside the monolithic Jenkins server but there are still problems the first problem is the issue of scalability how many CPUs how much RAM how much disk space do we need to throw at this monolithic server to keep it up and running and make sure it performs to our needs and even if we do that for today will it be enough a month from now will it be enough on the last day of a sprint mmm that can be a difficult problem to solve the second problem which is somewhat related to that is that this can become a single point of failure for the entire organization if your Jenkins server goes up in flames goes up in flames that was fun wasn't it if your Jenkins server goes up in flames no one in your organization is building anything until it's back online the last problem and the one you may not be able to solve is the question of technical diversity so if you look across these islands of Jenkins they have different levels of Java for example they have different levels of plugins this Jenkins server and this Jenkins server may have two different incompatible versions of the same plugin the problem here is that you may not be able to solve this with a single configuration if that's the case then some of your teams are going to go back to the island of Jenkins from which they came this server meets my needs this server does not in this case we've got the worst of both worlds I have islands of Jenkins that are not governed I'm not sure what's happening and I'm spending a lot of time and resource maintaining those instead of innovating and I've got a monolithic server which takes substantial resources to keep up and running but it's not meeting everyone's needs either however shall we solve this problem the answer to our scalability problems and governance issues is cloud BCI the reason that we're here with Club ECI you have some number of managed masters we have master number one master number two master number three and so on each of these is independent so they can have different software stacks different tools different plugins each of these can meet the needs of an individual organization or project they are also all managed by cloud BCI so we have Central Management here which can give us the governance and compliance that we need a couple of things that are great about this one is that onboarding becomes really easy if we have a new project or a new team we just create a new master and everything is good that team is up and running very quickly another issue is that I can keep these managed masters separate or I can have them collaborate so these may be working together they may be completely separate I have that flexibility the last issue here and what I think is the most powerful feature is that I can define these with templates so if I have a best practice if I have a governance or compliance issue I can roll out rules and policies across all of those masters if we discover new best practices in our organization we roll those out across all the masters as well so with cloud BCI we've solved the problem of islands of Jenkins because we're centrally administering these masters each of which has exactly what these teams need and we're solving the problems of monolithic Jenkins and that we can have the technical diversity that we we can have scalability and we have stability because the Masters are independent of each other in terms of the environment in which they're running I'll leave you with three case studies of cloud BCI customers first of all Autodesk estimates that their developers thanks to the automation features and team management features of cloud BCI are 10 times more productive that allows them to deliver innovation instead of spending their time on mundane tasks secondly at surra when we talk about reducing risk their use of cloud BCI led to a roughly 75% decrease in defects that's amazing and again lowers risk by taking more and more defects out of the picture and finally at Centene they worked with globby support and services to move from their islands of Jenkins to cloud BCI they estimate that it would take five to ten engineers to maintain the islands of Jenkins they had before those engineers are now free to make the business more efficient so plot BCI is a win for governance and control it's a win for development teams that need to get up and running quickly we encourage you to take a look at cloud be stuck come to learn more about this product thanks for watching for copies this is Doug temple Cheers [Music] you
Info
Channel: CloudBeesTV
Views: 2,454
Rating: undefined out of 5
Keywords:
Id: u5rEHc5a2Z8
Channel Id: undefined
Length: 16min 0sec (960 seconds)
Published: Wed Jun 03 2020
Related Videos
Note
Please note that this website is currently a work in progress! Lots of interesting data and statistics to come.