 So, my name is John Belone. I'm head of software infrastructure at SS&C. What does that mean? That's database infrastructure. That's things like developer productivity, DevOps. That's things like reliability engineering, site reliability engineering. And we do a little bit of internal systems tooling development, so, app dev. Tell you real quick about SS&C just so you have an idea of the space we're in. You can kind of get an idea. Heavily in kind of financial services business. So, think hedge funds, banks. We do things like healthcare. We're also in the head funds. We're also in kind of pharmacy. We have clients that kind of stretch through kind of the world. So, it says 18,000 clients. A lot of our revenues come from people who, one of the things I like to tell everyone is that if you go to the CVS and you go to get a prescription, from the time that you actually swipe your, you know, you put your numbers in and then sign something, that actually hits our back end. And we basically go through and do claims processing for, to make sure that there are no drug interactions for the drugs that you're receiving from CVS. Things like that. And finally, you know, there's a lot of, as you can imagine with a public company, a lot of things like, we talked about compliance. So, we do a lot of things like security and auditing. So, a big part of where we're looking to take the product is in that realm. Specifically, sock controlled type environments. So, I actually edited my slides a few minutes before we did this because we covered like, what is DevOps? Like defined DevOps. So, I'm not going to give you a bunch of like diagrams about DevOpses, but I'm going to talk about what we focused on when we decided to choose GitLab as kind of a product that we wanted to bring into the company. So, the first thing is collaboration. So, as you can imagine, you know, you have hundreds, thousands of engineers. You need a way for them to collaborate to do software development, life cycle and tooling, right? And when you look at kind of the competitors in the space, really the tool that stands out because there's just so many different avenues, not just code review, but wikis and CI CD and a bunch of other continually adding features. It's GitLab integrates with a lot of the chat and tooling that we support internally for technology collaboration. So, it also supports integrates with tools that we could build internally that we could write ourselves, right? So, using web hooks and API and things like that, it's very extendable. I say reliability. Really it's about our ability to provide a service internally to our engineers and customers, right? So, I'm a global company. I have offices all throughout the world. I need to be able to provide a baseline level of service to engineers if they're in India, if they're in Bangkok, engineers if they're in anywhere in the United States. Stable. It's got to be stable. So, one of the things, you know, that we ran into with, if you kind of the first time you step into like the Git hosting space, most people use Git web, right? They kind of stand it up and it just works, but there's no real high availability and, you know, you'll get one person that pushes a bunch of large files and the whole system will go down. Well, that's what I mean by stability, right? We need the ability to scale to noisy neighbors that are, that we onboard as part of a large organization. So, SISNC has a lot of engineers, but we also have a lot of companies that we're bringing onboard. And that means that sometimes you don't have the best hygiene when you're using Git repositories, right? You might have large objects or you might have things that just don't work quite well in a shared environment. And GitLab gives us the ability to break things out, to use other technologies like the Git large file system, offload large objects off the Git server, things like that. And finally, automation. And really, this is kind of, we'll talk about in a few seconds, but as an infrastructure team, we heard a few minutes earlier, we want to dog food what we're actually using, right? And in particular, we want to automate the ability for us to be able to use some of the tools that don't directly interact with GitLab that they don't integrate, but automate it through the use of the APIs. And you'll see in a few minutes exactly what I'm talking about. So, talked a few seconds ago of why GitLab, well, obviously code review, right? That's kind of the first thing that everyone dives into. I need the ability to put eyes onto poor merge requests and have issues associated with those merge requests and close them out through the life cycle of a problem or a bug inside of a piece of software. But some of the things that we started to look into in addition to that is what other things internally can we displace from the perspective of having many tools to do with one tool that does this? And we started looking at things like security. We started looking at things like feature flags and leveraging the CICD pipelines of GitLab, which was actually one of the biggest sellers for us because our CICD story prior to GitLab was really, you know, some people use Team City, some people use Jenkins, some people use a number of other products. We wanted the ability to give them an integrated experience on all the platforms that we support internally to build software on. I talked a little bit about security, but in particular, access and change control. So we'll see in a second what I'm talking about, but the ability to use repository level controls to not only control who has access to view, who has access to merge pull requests, but also who has access to even change or merge parts of a pull request for particular files inside of a repository. And I'll talk about that in a minute, but effectively where I'm getting at is if you have a large repository that has several different code owners, you have the ability to say that these three individuals are responsible for this domain, these three individuals are responsible for this domain and technical writers are responsible for the docs directory. And when you get a merge request through a workflow, those people will be identified as the correct approvers of those pull requests. And that's huge because it allows us to automate our workflow without really having to do too much configuration outside of a simple file. And of course, infrastructure. So high availability, we talked about that, needs to be reliable. But we also talked about geographically dispersing GitLab, and Geo was one of the bigger selling points for us. We currently have three actual large deployments of it. So we have two that are in the United States and then one that's in India. Awesome. So let's talk real quick about access and change control. I talked about using code owners to define the ability for individuals to be able to merge changes to a particular file. That's huge. And in a second, you'll see we've leveraged GitLab to actually automate some of our configuration management tooling. In particular, we're talking about Chef. And this gives us the ability for individuals to say, okay, you own these particular policies for these particular servers. And you're the now the sole person who can act or the sole group of people that can actually merge those requests to eventually update those servers and upgrade them through a change control process. So we have the ability to now query back and checked. I mean, it's not easy, but we have the ability to query back at a particular point in time and check who was able to make, not only who made that change, but who was able to make that change at a particular point in time, which is really important when we're going through an audit. And actually, if you kind of follow a lot of the DevOps, the four eyes rule, right? You want at least two people to look at a pull request. And that's that's we enforce a minimum on most of our repositories for infrastructure. At least two people need to be able to verify a poor merge request. We talked a little about CI CD. So pipelines are huge. This is how we've been able to actually build a an automation around things that don't directly integrate with GitLab. But obviously, you can use this for out of the box for Kubernetes. And that's something we're looking for in the future. Like I said, change control allows individuals that have access not only to approve those merge requests, they have access to actually do a deployment. And you can define inside of your GitLab YAML, the pipeline YAML, the ability for automatic things to move automatically. So if you have a test environment or a UAT environment that you don't necessarily care about, you're fine with it going straight to the UAT environment, it'll do that as soon as a merge request is accepted. But if you have several different production environments, you obviously want someone to manually look at that, maybe run a manual QA test or an automated QA test if you have that. So unfortunately, I have screenshots because I wasn't sure if I'd be able to get my VPN. But inside of a merge request, this is what you would see when you are working with our Chef repository. Someone, an individual has an update, they request to merge an update. And then there are certain individuals based on the files that they've changed in this merge request that actually have an approval right to that. And you'll see this here. Merge request approved by that particular person's icon, right? But you can view currently at that time, who was eligible to actually approve that, right? And that's obviously now in GitLab as an issue as long as that repository exists in GitLab, right? You have history about the change that was actually made, the series of Git commits inside of that kind of branch. And specifically, you know, you have further down, I didn't show it, but you have your comments, everything you would normally see in a merge request. So if you're discussing things, and while kind of the testing and everything's going on, you still have that kind of collaboration and discussion about changes, which is key to any type of change control tool, especially when you have some individuals that aren't intimately familiar with exactly what changes are happening. And then further down here, this is where it starts to get a little interesting. We use the GitLab pipeline features to actually do automatic deploys to our Chef environments, but then it holds up deploys to environments that we'd like to promote changes to, i.e. anything that's not test, right, production. So this is actually what's interesting, GitLab modifying our Chef repos to actually deploy GitLab Geo in Mumbai. So when you actually dive into the CICD or, you know, the operations tab, you'll see that there's an area here that kind of shows what exactly is being done as part of the GitLab pipeline. So in this case, you know, we have a few settings. These are the production or non-test phases, and they're required to be manual, which means that someone needs to actually go there and click a little button that says, you know, advance this to the next step. And you saw a few moments in the previous presentation, you saw the directed kind of graph. That's part of this stage. So you'd see basically individuals, sorry, lines of that directed graph would be just yet another environment in kind of the pipeline part lines. This is a list of all the environments that we deploy to, and as you can see, each of the components of GitLab Geo are actually spread out separately. So that means there's different servers. So we've kind of went through what it would take to deploy a highly available GitLab Geo instance. And you could see just, you know, kind of the history of what actually happened, what changes went in, the SHA that Git commit that it actually happened on, and more importantly, which deployment actually affected what actually pushed the change. And who did it actually, who actually clicked the button. So when you kind of dive further into this, you know, when you look at a macro level, you'll see that, you know, we have 43,000 now changes that have happened in six months or so that we've been using this tool. And it tells you how long something actually took, and you can rerun a pipeline. If it were a particular pipeline that was, you know, idempotent, you could run it again and get the same result. In this case, it actually should be. You should be able to run it again and get the same result. We just don't ever really find a need for that because usually when we find an issue, we find it in the test environment and then we'll just push a subsequent update that fixes that particular problem for this use case. So what's kind of next in what we're working on? Well, we talked a little, on the first couple slides, you saw about security. So, you know, security is the DevSecOps, but really what we want to do is have the ability to manage the concerns for software development, security scanning, things like that as part of our workflow, but also have our security operations and engineering team come along as participants instead of being at the end of kind of the process that you're getting code to production. We don't want to have red tape. We'd rather have them come along and be participants in the collaboration. And that's our key to using any of these kind of tools. We want to extend the pipeline usage beyond our infrastructure projects. There are a few projects now that use Windows and Linux CI runners that just basically build the CI process, but they're not using the pipeline, the whole deployment to production and realizing kind of the benefits of the whole workflow. Specifically, you know, the AutoDevOps that gives us the ability to connect a repository directly to a Kubernetes cluster and do things like application deployments, monitoring, excuse me, live monitoring and metrics and check errors and things like that that would happen during deployment. And I talked earlier about SOC controls. We really like the ability to pull our audit information from a trusted source rather than have to basically store it ourselves in a database and then, you know, produce those results when we go through an audit every couple of quarters. So what's nice is if we have the ability to basically say, oh, great, there's an audit for this particular business. Okay, click a button. Here's all the change control information for the last six months. That's huge because not only does that save money because we don't have engineers now spending weeks and weeks and, you know, maybe a month pulling this information, but it also gives the auditors trust the fact that we're actually, you know, using the tools that we say we're using. It's pretty quick. That's all I have. I figured there'd be some questions. I can talk more about the specifics. Fortunately, I would love to show a demo, but wasn't able to. No questions. Expect to use GitLab kind of having, oh, you had mentioned you expect to use GitLab kind of having some experience of working with people with bad code hygiene. Yeah. Do you have any experience of, you know, what that looks like in a GitLab server? Yeah, sure. So, yeah, so let me, let me kind of step back. One of the teams that we were working with had basically used, they were a Java development shop and they basically took all of their ant and maybe I think it was ant dependencies and checked them into the repo. So all of your JAR files just, and if you can imagine that over the course of five years, you have a 30 gigabyte or more repository. So, unfortunately, you know, it's not GitLab, it's just how Git works. In order to leverage that appropriately, you need to rewrite the history of the Git repo and basically tell the repository to offload those objects into something, either a different place, LFS, or you can store them in like an object store, something like S3, anything like that. So there's a lot of different ways you could offload those objects, but unfortunately, it requires rewriting the history of the repository, which isn't actually that bad. As long as you don't rely on, you don't rely on anything that points to individual commits. So sometimes people have like change control things or they'll have like integrations with other products that point to specific things. So we did run into a few issues where there was a security tool that basically pointed to large change sets, but it was one of those things where we self-reported to the tool, so it wasn't an integration. So we were able to effectively go through and review some of the change sets that were reported and point them back to other commits. But sometimes it's easier just to draw a line and be like, okay, we made this change, let's move to another tool. And from here forward, you know, just assume that things aren't going to work.