 Great. So thank you for those of you who are able to join and for joining us here. This is the Sales Enablement Training for Thursday, August 16th. I'm Dan Gordon, Technical Product Marketing. I'm going to take you through today CI and CD tools. Kind of looking a little bit of a competitive angle. I'm going to first do a little bit of primer on CI versus CD. Hold on, I'm having some issues here. I assume you guys can hear me okay. Can you guys hear me alright on the feeds? Yes, we can. Okay, thank you. Okay, so I'm not sure why my camera's not working while you guys can't see me at the same time, I'm sure. But let's get rolling. So you should be seeing CI, CD Tools Primer. This is in our handbook. I'm using a temporary link right now. Last fix that it didn't come through. But this will be posted shortly after this in the actual handbook. So I wanted to start with this graphic. This is actually from our CI documentation. But it does a really, really good job of depicting kind of the breakdown. And so I wanted to start there. The Tool Git Lab works across, as you guys know, the entire expanse of DevOps lifecycle. This includes the stuff not highlighted on the left here that doesn't include a pipeline that much. The coding and the working with related code and the committing. But after that point when the commit happens, then as you guys are aware, build picks up, unit tests happen, integration tests. And these are the things that are the CI pipeline. Now, we oftentimes kind of just put those all together and we say there's one big pipeline and it can take our commit all the way. And this is actually what we do, right? It takes the commit all the way into production or the staging and then kick it over to production. And that really can be and often is two pipelines as opposed to one. Or if you logically break it down, there's the CI pipeline, which is involved in focusing on getting quick feedback to the developers doing the integration testing, doing that on the shared repository to make sure that what's being put into master is eventually solid. This involves automatically building and testing all the changes that are committed. The intent is that this happens at a higher frequency because that means that when we find issues, the problems are smaller. They haven't grown out of proportion with more time and more commits or checking. This is important because smaller problems are easier to fix. The idea that just Hummel Coins when he wrote the CD book put all the knowledge into the CD book and talked about for a while is really an action Martin Felder before him was really the notion that in continuous integration, the idea from a time perspective is that a developer should be able to write their code, check it in, go get a coffee, take a break, chat a little bit to a buddy and then come back and see his results or her results so that they can be still in context of the change they made and then move forward from there. Now, of course, as we move more and more testing left, there's always a balance that has to be struck and figured out about how much testing and how much time we wait between getting feedback or getting a developer feedback, but this is still generally the continuous integration pipeline and the notion there is that when they get back and they see a problem, if they see a problem, then they're still in context of what changes they just made and what this does is this enables the developers to have more confidence in the code once they've put it back, which means they have more confidence in writing the code and knowing that they can move forward and overall this result, it's proven that this results in faster development. So that's continuous integration. Now, there's an extension of that, a natural extension which is continuous delivery. CD actually continuous delivery and or continuous deployment. So what are the difference between those? The first of all, either way, CD is really about the release management practice. The API I forgot to mention was really about the development practice. We talked about the developer and the changes they're making and the tests that they're doing to their code before they move forward. Continuous delivery or deployment is really about how that software gets out into the world or out onto servers to serve its purpose. We bring the value that it was written to bring. Now, when we talk about continuous delivery, we're talking about software that is always ready to be released. So that is the goal of continuous delivery. It doesn't mean it is released. It means that it is in a state where it can be released and there's confidence, high confidence that it can be released without issue. That means we understand the dependencies. It's been tested and validated. We know exactly what it is that we're working with as far as versions of all the libraries and everything, and it is ready to go. Now, this can mean ready to be pushed to a staging or a production system, or in the case of folks that are not doing web apps, this can also mean ready to be shipped or distributed. So, for example, Gary Grover, when he did continuous delivery at HP printer division, it was that they had firmware ready on the server for the HP printer hardware folks to pick up and write down to their firmware, down to their hardware at any given time. So there was always something that was ready to go that was working and shippable. And that's continuous delivery. Now, continuous deployment takes that one step further and it takes the change. It means that the changes are actually released to production automatically when a pipeline succeeds. So we go right past ready to ship and we actually ship it. And that then kicks in the ability to provision and configure servers and track all of where things end up and make sure that you have a solid set of automated tests so that we're confident once the changes pass our tests that we have not regressed and that we have not caused problems or security. So this continual testing for releaseability is a good thing because what it does is it lowers the risk of each release. The goal is, of course, to have more in releases. Releases that do not amount to any excitement that we can do at any time without worrying. When the release risk is low, whether you're in a small organization or a large enterprise organization, when the release risk is low, then releases happen more often. And when releases happen more often, the value that our development team and that our product team is putting together gets delivered to customers more frequently. That's good for the company, that's good for the customers, and that's great overall for getting rapid feedback and being able to do the kind of development that the market's basically demanding, which is rapid, quick turnaround on changes and improvements. And so this has all become a necessity in order for a organization that is software-based to survive in the coming world. And all organizations have some aspect of software in them that they rely on for capabilities from. I'm going to shift there into kind of a market overview You guys have seen this graphic, no doubt, several times. We're proud of it. The Forrester CI Waves, I think this was 2017, GitLab's got a pretty good position there in the leader, in the top of the leader. You can see who's with us, CircleCI, Microsoft, CloudEaves, et cetera. Now, there's actually a lot, a lot, a lot of CI systems out there that are not even on this map because CI in its small form has kind of become a table stakes. The notion that you can automate capability by executing scripts or calling out two different tools to have them execute on servers and then pull back the information and make a decision about whether or not it was good or not is something that a lot of tools that weren't focused on CI before that had some form of automation and integration are able to start doing. And, you know, so the key here, as I think is that I want to impress upon you is no vendor today is really going to survive by only doing CI. So, GitLab is making the right move, has made the right move by looking beyond CI. Vendors in the space, all of them really are evolving to CD, continuous delivery, continuous deployment. It's a natural extension of the capabilities of the CI system. The CI system already can automate and already can integrate, so the next step says, okay, well, great, if I need to actually put the results of my build out onto servers, I need to automate and integrate with the tools that can configure those environments. The automation capability is already there, so it's natural progression. Now, that's all good and fine. And what that means is starting to integrate with AWS or back in the day, VMware, still some of that. And then containers, microservices, and Kubernetes kind of came and it wasn't just another infrastructure that you had to just have a plug into that you could yell some commands at and then do some configuration and put some files out on. It actually changed the flow. So, once containers, microservices, and Kubernetes has caught on, that really the notion of how CI CD works is starting to evolve. Build artifacts are through the pipeline, but they now come wrapped in their application environment as opposed to just the artifacts themselves with definitions of the environments elsewhere that then need to be merged and tested together after the fact. Storing container images is happening now instead of build artifacts because now the container images themselves are the artifact that we're coming out of the build with. When we do Docker build and we build that image, what we're doing is we're capturing the application and environment with the application changes and moving those through the pipeline together. Full integration testing because of this becomes easier and can be done at earlier stages like we're able to do more thorough security testing earlier on because we now can actually have running containers with their application environments and test the environments that we'll eventually deploy with. And because of this and this is what we're seeing, CI CD tools can now more easily automate everything about the application deployment with minimal integration work because now instead of having to integrate to VMware to spin up server and then to the network control system to create the networks and then to the Chef server or the puppet server to then actually lay out the environment and make sure that it's compliant and then put the software on there and then do the testing now. It's one tool, it's Kubernetes that can really kind of do it all for you. So the integration point is a lot tighter and the capabilities of more advanced deployment are coming from those systems, the Kubernetes. So now as we see CI and CDU Thunders have moved past CI to CD and now they're moving into and erasing to all adopt Docker and Kubernetes support. And so that's something that you'll notice if you look at the CI, here's an example here. If we look at the competitor scope and this is not all the competitors by any means but some of the top ones that show up and that we're on that graph, the Forrester graph. For continuous integration, if we look at some kind of telltale things like auto scaling, pipeline graphs being able to visualize the pipeline, parallel jobs being able to run multiple things as well, multiple tests, for example. Configuration is code, which is pretty common nowadays so that you can keep your configuration next to your source code and container type of there. Container support being able to work with Docker containers and call out and say, hey, build one and store it in a registry somewhere and pull it back out. So this is all kind of become... Everyone's kind of starting to get those, right? I like Jenkins through integration because Jenkins is all about integrations everywhere. So they have a little bit of a challenge there and they have to fight that story about what it takes to integrate to bring these capabilities. Auto scaling is an area where, surprisingly, not everybody has that capability but for the most part, if we look across the CI spans there's pretty good... and at least a few categories, there's pretty good coverage. Everyone's maturing in that area. Now, if we move on to continuous delivery and deployment, it's a little bit of a different story. So if we look at, for example, the notion of having environments, why would you want environments? You want environments so that you can keep track of where things are deployed to and what's been deployed to them and what the history of those deployments are. Not everybody has that. Circle CI is pretty true to its name. It is about CI. It does have some capabilities inching toward CD and they do talk about continuous deployment but they don't have the notion of environments or because of that environment history. Same with Jenkins, nothing native. And even environment history for TFS, BSTS from Microsoft is not there by default. And so if you look across kind of the types of things that lend themselves to continuous delivery and deployment, no configuration staging us. This is our review apps. Deploy boards. Being able to see kind of an overall view of your environment and what's been deployed to where your deployments. Native deployment is not there for a lot. Secure variables. Surprisingly, not everybody has. Directly out of the box. And deployment traceability and protected environments. Now protected environments is one that really lends itself to those deployments in the production. And we don't have that directly either. So we have environments, but at this point, this notion here is that we may want to put a block on the ability to deploy to production, for example. So just because a developer or somebody has the ability to write to a branch doesn't mean that they should have the capability to actually deploy. And yes, I think David, that is something that we are working on and is supposed to be here soon. So overall, if you look at it, this is kind of the playing field now. And CI and CD together is really, they're oftentimes groups together. There are a few vendors out there that are really just focused on the CD part, like Spinnaker. More about the creation of the, and delivery, the lay down of the environments. But, and not so much of the build process. But most vendors that were CI have moved forward and are eyeing CD, even though a lot of them have a ways to go on what they need to put in there. Okay, and 20. Okay, so I'm going to look at the questions. Trying to keep an eye on both. Let's see, Sean, Billow, can you explain what type of testing is done and when? Absolutely. So in CI, in the verification stage or earlier stages, the developer pipeline will run things like unit testing. Functional testing. We'll do static code analysis looking for bad coding practices, code quality. That is also when a static application security testing can be done. I think as the story that we know, that we hear is that the security testing right now oftentimes is pretty pricey, charged by line. Something that is not brought all the way left and so it gets saved until later after the changes in the commits have gone through more testing and come further through maybe to the staging environment. And that's unfortunate because that means there's a lot of processing and work that goes on before security problems might be caught in the code, which means that it's the same problem when a developer gets a response that says, hey, this is a problem. It's a change that you made. Can you fix it? If they had to wait for their code to go through the full CI cycle, get deployed to a test server, get maybe even to staging and then get the result back that says there's a security problem with the library you used or some code that you wrote, then they're pretty far removed from the change they've made. And so we want to pull that kind of testing forward as well, but right now a lot of times that happens. It's pretty late in the game. Things like dynamic application, security testing, performance testing, those tend to go later in the cycle because you have to have running application. If we wait until it goes through the QA cycle in typical scenarios and then gets handed off to the release team and they get into staging and they're starting to work with it and that's where they're testing it. Then again, we're pretty far removed before we know there's a problem in the running app. So that's why there's such a value with GitLab's ability to pull all of that forward and do that as early as possible. What else do we have here? Yes, I will post the link to the page in the handbook as soon as the rebuild finishes. Okay, are there any other questions? Competitive info on CloudBees Core. CloudBees Core is largely Jenkins. Interestingly, they've split their attention and they bought code chip a little while ago and so they've been pushing that as their SaaS solution. And just recently, Jenkins X has come about and there's a little bit of information right now continuing to do research on that about what that entails. So that's in the DevOps Tools handbook page or DevOps Tools web page. And Jenkins X is really an attempt to do what GitLab has already done. It's to prescribe a pipeline, integrate out of the box with Kubernetes and kind of give you a drop-your-code and it's running on a server kind of experience. And so far what we've heard is there are still integration challenges and it's not all that smooth and not too much traction, but Kipi and I on that. Let's see. So we see silos between SCM, CI, and Release Engineering. Let's see a voice for challenging that model. Let's see if her name says Native Companies. Yes. So that is definitely the challenge. I think especially as you get into the more release engineering or the release operation side, having both of those folks or all three of those folks in the room looking at different parts of it can definitely be a challenge. I think GitLab has an opportunity in that it has pretty strong capabilities across each of the areas that we're talking about here. Still building out the release engineering part, but solid in SCM and CI. And I think it depends on when you get into the room if these guys are coming from, if they're on a DevOps trail. Oftentimes I think even when they are and they say, hey, this is a DevOps initiative and they want to work together, everyone still kind of has their area of expertise and where they're comfortable and whatnot. And I think the transparency of the app, it being all together so that they can all see all the parts that everyone else is working with blends itself to helping teams to collaborate and to come together to really kind of embrace that culture that DevOps is trying to achieve that's hard when everyone has their own tool, absolutely. So I would almost say that the silos kind of sometimes come about naturally because of the separation of tools and people become specialists and those are comfortable in the areas that they're working in. And so a single tool that they can all interact within and that they're all sharing can help relieve that if they can see that in action and see how oftentimes those silos, the wall between is because of trust. So transparency and access to what's going on can help build that trust. Absolutely, the chaining of tools, absolutely it just supports those silos. Any more last questions? Hey guys, thank you very much for joining. Appreciate your time and we'll see you next Thursday. Oh, actually we want, we'll be traveling, but we will do this again and we'll see you then. Thank you, bye.