 Okay I'm gonna start recording. So yeah so Ty you had a question for me that I have a lot of opinions around and it's something that people at GitLab ask me about a lot so I thought it might be just better to just hop on. Talk about it sync real quick but record it and post it for posterity. Okay good. So yes the question was around you know we we you know GitLab we're very proud of our RCI but when we're talking Jenkins and and want to know what a how to go about you know a company that's using Jenkins and trying to replace that with with GitLab what are some of the weaknesses that GitLab might have against going against Jenkins? Sure sure yeah so I could I could talk about this I I don't consider myself an expert but I guess I should if I'm the product manager for for CI but I don't I'll pre-empt the pre-empt the whole thing this is all biased to my experience right right but I've used both Jenkins and GitLab CI and actually older tools and both of them you can believe it and and I have some things I like of course about GitLab CI but I think it's a legit question to say you know what is it about Jenkins it's gonna make it hard especially for a large enterprise I think it's hard to do a feature by feature comparison because we're we kind of had very different philosophies we grew up around very different times right Jenkins significantly more like older and I'm not trying to say that as a negative but it's older than the CI and because of that it had like a view of software development at the time I think that's kind of baked into it because GitLab CI was built when it was it has a view of the software development world built into it that in ten years someone you know might say it looks old right again I'm trying not to have all of the negative compensation here because all does not mean bad but it it does you know change your vision when you're building something when when you build it is relevant so I think the biggest thing so that's to say feature to feature is hard well I'll get into that a little bit but I think it's hard to do that because like the biggest thing Jenkins has going for it is the fact that's such an industry standard right like I think most folks would say Jenkins is a industry standard right comes to CI and that that momentum is is not you know that's important like that's and for a large enterprise that's worried about you know shipping reliable code that's that's a big deal because if they've spent a lot of time and energy into building pipelines for CI and CD that work for them then it's it can be hard to say okay why would I switch or oh my gosh am I gonna have to make this up again and and a lot of times what people bring up and I think this this kind of helps it's like and this probably would be the number one feature of Jenkins that I would say that we don't have which is like the plug-in ecosystem right and it's it's very this is you know maybe a central place where we diverge in the way we think about the world you know we think about single application if something is valuable for someone we want to build in the application by default where shinkins is extensible through plugins and there's a massive world of ecosystem of plugins from which you can do anything in the world so if you want to do you know some thing some specific kind of deployment interact with some specific system you kind of have two options if you put GitLab and Jenkins out of your mind for a minute you can take something someone else has done before and leverage it or you can you know gain that knowledge for yourself and do it yourself so there's a lot of value obviously we're an open source company in the you know building on the shoulders of giants that you're able to do with open source right and so theoretically plugins are that too because oh if it's how to do this type of deployment I can just go get a plug-in that doesn't and that's really great in the beginning but can lead to a lot of problems so there's a couple pages I was going to share my screen a couple pages about this one's a stack overflow article that's kind of just general and then one's another article from some other third party okay that illustrates this point so let me just share my screen real quick so this is a GitLab CI versus Jenkins Stack Overflow post and the answer is not GitLab on the post so don't worry the answer Jenkins in general but it's but it's interesting how and why Jenkins right right and so so here's this this person's answer which I really like it's very complete talks about like kind of all the whole world of CI and answers a lot of a lot of the things right so Jenkins is easier to learn because it has but it has the risk of becoming plug-in hell right like so again I think that if you say well GitLab CI you can start from a Docker image and do whatever you want that's great but with Jenkins it might be oh install a plug-in Jenkins has a GUI right so of course we have a graphical user interface too but Jenkins traditionally and when it was originally built was built with can you see it's okay I'm zooming a little yeah yeah I'm just thinking before recording it sorry so Jenkins when it was first built was built around you point and click and say how do I build my thing right and then Jenkins will do the steps that you've clicked in and clone in this way and run you know this kind of maven script and and then publish to this you know maven repository or what what happens and so this this sometimes is a preferred method but in my experience it's it's not the way to move at the speed of modern software delivery right what that leads to is kind of siloed institutional places where someone is the Jenkins admin and now if we want to change slightly the way we're building or deploying we've got to involve a different team that's not our development team right it's a very anti DevOps pattern it's like there's a Jenkins team and there's a development team and they're different they're at odds right and this is this that's what my experience was so when I first joined the company before I joined GitLab the company I was at I inherited as the kind of director of DevOps there I inherited the toolchain that we see a lot right I heard it inherited JIRA to GitLab to Jenkins to Artifactory and Nexus right to deployment and the thing I found was I had engineers working for me that would be spending time configuring stuff in Jenkins or adding another plug-in or troubleshooting the difference why two plugins were being compatible or adding a new tool in rate like we did a lot of Java development there okay but a lot of our customers had very specific requirements on Java so it's like oh we have to have Java one seven one eight one or we have to have Java he did it right right we run into issues like the story I always tell from that is the way that you use Java with Jenkins is the administrator of Jenkins installs a tool what's called a tool and it's actually a free text field right it's a GUI so it's nice it's like you can type and say I want Java there's actually a free text field that names it and someone had installed again as I inherited the server someone had installed the JDK and labeled it JRE which for those in our Java folks two different distributions of Java an open source one and the one with a miracle and the two often times cannot build the other one and it was really confusing for my team to try and troubleshoot because the way it was labeled look like everything was correct and in reality we had to drill into where the binary was in town versus the GitLab methodology there is build and Docker and start from a Docker image you could start from the JDK published Docker image or you could build your own Docker image to build inside right so that that is a big difference okay and then and so then but then it so talks down here about another critical thing right like a long time ago a while ago to be fair there was this addition of proper CI this person calls and I would agree of CI in your build as code right like everything should be as code and so the Jenkins file has that but again it's it's still I think that that Jenkins world is still trying to decouple the concept of having a configurable user interface with the concept of a portable Jenkins file whereas like GitLab the GitLab CI is the only way it's ever been right and so it's it's super easy to just kind of pick that up and move it and says yeah but used to be less coupled to repository which they bring up as a as a positive here right Jenkins can be split off for your repo I guess there's some benefits to that I would say that the costs outweigh the benefits to that and then I think a lot of the where where plug-ins of ours saying what's the advantage that Jenkins has comes in this one right like we are still trying to build a lot of reporting and test results and coverage and other static analysis analysis tools in the GitLab a lot of that was new in 2018 for us right and then being able to see that over time being able to see all the details that's things that our team is working on this year because I do agree that because you can just pull in a plug-in for Jenkins you know graph my test results over time but that's a big advantage that they have over us right now but I think we're going to fix that quickly quickly close that gap and I think that the emergent benefits of a single application again still outweigh that but that's probably my get a bias committed into in the bear interestingly enough they edited it later and said that they've been working more with GitLab CI recently and then brought up some different things right the maintenance is easy right I think this is critical for the enterprise right going back to my example earlier of my previous role is I would walk into executive meetings and I would say the most expensive tool we own is Jenkins and they would say what are you talking about Jenkins is open source we pay for Office 365 and we pay for Gira and I said no I'd like to literally pound the desk and people to know me know that I'm not kidding let's say Jenkins is the most expensive piece of software we own because of the time we spend on it and so again that undifferentiated work that ends up happening I think far outweighs the like oh well but there's a plug in to get started right it's like that's great in the beginning but for maintainability in the long run it's it's it's not great never guaranteed at that play I mean a lot of times plug in our kept the state but you're not always guaranteed at that plug in will be around forever exactly exactly so I wanted to go through this one too but if you had other questions I don't want to just be on one call no just more questions that we have we have a lot yes this is an interesting one called from from slant.co which I have no idea who they are but it's some interesting things that they allow people to comment on and it's interesting this just common questions makes me piqued my interest I don't know when this is from 13 on it I'll see you date but it's interesting because okay we're not number one I don't know who number one was I guess I can go look but what are the best continuous integration services with Docker support and look at this flip right right between the five and one that is a central thing to me because again I'm not going to necessarily claim that we're smarter than anybody else but like when we built the FCI was right a doctor was becoming the industry standards and because of that we built it like with Docker support from the ground up and luckier smart doesn't matter but like because that happened like we have this advantage I think now that we can just move it the modern speed of development move in a cloud native way right Docker the way developers want to support Docker and not see what good would you see that I mean that we when we started doing that when Docker was coming about and now you see and you know the announcements of Jenkins last year that they have their cloud native initiative and it's it's trying to do that same thing but yeah you know a few years delayed and well and honestly I think they're doing it in the right way right because I think with many other like industry changes that have happened over time since Jenkins was created it's been both on right like we saw that Jenkins file thing was kind of like well both it on the Jenkins and we'll make it work because like now like your build as code is a thing but with Docker and the move towards cloud native like I believe obviously because I'm at GitLab and we believe it and and I believe it that's one of the reasons I get lab rights kind of so filling but that like cloud native is like a tectonic shift and Jenkins themselves I think believes that too because they said forget another bolt-on to make make it better like we're gonna do Jenkins X right like we're going to to make a cloud native Jenkins like that to me says yes that's the right way to go and like you said they're behind and we got to stay ahead of them but right ahead of them and that's critical so then and there's a lot of these comments below that I think bring up really interesting things so like free and open source right we're both free and open source which is amazing love it like lens I really like that the first pro on the Jenkins side is safe to store key environmental variable so we also have the ability to like encrypt at rest your environmental variables but we want to have like a more first-class Hashi Corp vault integration and so that's one way one that actually speaks to me and to our vision directly because I think there's a plug-in for Jenkins that does well like we want to just bring it in to get on natively because everybody should be using both for their secrets and like credential rotation and all that great stuff again pro on the Jenkins side a lot of resources and tools and variable right it's been around since 2004 because of that there is just more you know stuff to consume about it right and right that's why we have a tie Davis and marketing to try and close that gap I would even say you know we yeah I'm trying to close that gap and provide more materials but you look at what you're looking at right now slant that code and the fact that we're you know being featured on this and doing comparison shows you know how how prevalent that we're becoming quickly because the ones taking the time to take Jenkins and compare it against us and we've been around for only a few amount of years yeah yeah but then again I think I'm just and again I'm now I'm probably biasing like myself towards get lab but I just think that our file-based configuration is so critical it just opens up a world of doing dev ops the right way you know that's how Travis does it it's how drones drone does it it's how circle does it it's how codefresh does it like that's because that's the way to do it and again Jenkins can do that but like there's a lot of there's a lot of still oh but you got to set it up as a pipeline job oh and you got to tell it where the repository is oh and you got it right like those string to get those little things those little cuts of stringing together applications yeah then on the con section again there's a lot more of this I'll put I'll put the links to this in the video description below very easy thing for me to say because there's a lot more that I'm not going over and the but the cons are very interesting to me right like poor plugin quality that sometimes are difficult to combine right like this idea of combining the plugins together and plugins that do different things or do kind of the same thing is is really bad and then you don't and you don't again this is an anti-pattern in my mind to how we should be building software and deploying software which is there should be a single source of truth which is your defined job right whereas with Jenkins files you might say call this plugin right and then all that plugins code is running and who you don't really know what it's doing and so again it might have saved you time to begin with right it would save time to say I want to build maven give me the maven plugin right but it's better to say well I had to write maven install in my GitLab CI script and oh actually I need another maven variable I can just do that right in my script oh wait I need to run this command first right and just you're at the if you're relying on the plugin you're you're relying on their way of doing it rather than your way of doing it which can be good and can be bad I think it's bad and then just the unstable lack of integration QA process right so like Jenkins Jenkins itself guarantees zero plugins to work I think I could be wrong about that there may be some plugins that are there really to get any assurance on plug-in view it's my understanding again this could all be wrong that that's where like cloudbies comes in heavily to like help support Jenkins in the plug-in system but even then there's only a subset of the plugins that the folks at cloud be a support and if I'm wrong happy to be told I'm wrong but that's my understanding of it okay and that to me is is is a little scary to like kind of again bet my like the ICD pipeline on it I'd rather know I'm starting from a node 8 Docker image I'm running npm install and I'm running a deploy and this is how it works rather than there's this plug-in and this plug-in and if we update Jenkins and this plug-in breaks I've now got to go figure it out for myself or roll Jenkins back and that's again as a Jenkins administrator I had that happen to me all the time the update one thing and it breaks another whereas with GitLab it's a single application that we support everything that it can do and the update is gonna you know be supported you know everything that we decide to support and you can see this in like our public issues and changes to our agent the GitLab runner my engineering team will push back really hard I'm like because if we accept something we accept supporting it right yep so and so that that's a big that's a heavy ball right right and I mean I've seen an actual issue where that that back and forth happened it was you know an outside vendor wanting support and it just that there was you know it's a great it would be great but the pushback was it was just there's a lot of time spent having to you know man that yeah so anyway that's I don't know if I answered your question maybe you did complete I mean it obviously there's a lot of working parts to everything I'm like you like you mentioned it's not a feature-to-feature because you know they're both you know one of the same but you know different tools at the same time so you know I guess another question I'd have is if you have you know an organization or someone that wants to you know and we don't have to we're not going to go into tech goal this is how you do everything but just they're thinking about moving off of Jenkins to GitLab what would be your your recommendations for that and just how to go about that yeah so I mean again I think that for an organization that's got you know entrenched with Jenkins it's gonna be hard right there is no rip-and-replace strategy for that for a large enterprise and so I think I can tell you I'm gonna tell you again how I did it and then how I think the thing I did and I was this was a smaller company and so this might not work for for our large large enterprises but the thing I did at our at our company once I had realized like this wasn't going to work and it wasn't scale what was the most expensive piece of software we have as I said look if you're and I had it was an interest it was a contractor to the US federal government and so they're all these very different teams that were doing very different things little projects and spin-up he's been down right and so because of that there's lots of different things being built and I said so I said to all those teams you know I was in charge of DevOps for the company the whole I said look if your Jenkins but works I'm happy like that's great like have at it if it breaks you can fix it you can you can I'll let you I'll help you get in and Jenkins you can try it if you want like my DevOps teams help like let us show you and like build a CI see if my employer now again that's not a strategy that maybe works but I think the end of that strategy is the most critical answer to your question which is like just try it like if you have an innovation team or you have a team that's leading the charge for GitLab in general like once you try it it becomes very obvious how different they are this thing that sounds like a marketing pitch of like well it's hard to feature the future like you'll realize right away if you just build one project with it like it's a very different way of looking at the world and one that I think more lines with the way folks develop software today in 2019 again happy to be proven wrong on that happy to be like challenged on that like we'll put I'll also put links below to our what we call our verify direction page so we call CI verify GitLab for anybody watching this as one of the stages of the DevOps lifecycle there's a direction page that has like kind of all my thoughts about where we need to go with CI because of course as a product manager I don't see us as done and through any of us all and I'd love to hear feedback on where I'm on but that's that's what I think like just try it is like the most the best advice I can give anyone because a it's open source so you could literally just try it GitLab.com has free runners so you can literally just try it it's actually the first CI job I ever built with other free GitLab.com using and and yeah so I think I think that's one and then the way I've seen enterprises transition again is in a number of different ways I don't think there's any large enterprise that's said okay we're today we're ripping and replacing and Jenkins is turning off and GitLab is turning on there's folks that have done okay all new projects are coming on to GitLab or we have a cloud native initiative and that is going to be in GitLab right and so like it's natural as we're trying to like because a lot of it again is managing change more than managing the tools like I mean that's not shocking anyone and so like inject into this change management this is the new way of of deploying software or building a deploying software too and put that under the umbrella of to be buzzword compliant digital transformation whatever you're going to call it but like the idea that like we need to change the way we operate to adapt to the modern world one of the pieces of that is a small tooling change but one that I think will have an impact awesome well I appreciate you taking a slack question hey but I really do it and it helps you know answer um questions that we get a lot from people that are looking at GitLab so um appreciate it thanks for jumping on real quick we'll like like Brennan said we will put um some of the links that he mentioned in the youtube description below and comment reach out we want to hear your feedback give your feedback you know fact check them if if you want to so appreciate it thank you Brennan thank you we'll talk to you soon