 My name is Ravi and that's Michael Pereira, so we're from Northwestern Mutual. Northwestern Mutual is a financial services company, headquartered in Milwaukee, Wisconsin. We have locations in New York City, remote offices in Phoenix and Minneapolis as well. Fortune 111. We're working on some amazing technologies in cloud and DevOps and we have some very challenging problems that we're solving, trying to bring digital transformation to a 160-year-old company. So a lot of good work-life balance and it's a great place to work. So our agenda for today is we're going to go into what are the challenges that typical SEM system faces right and what are our requirements for an enterprise ideal enterprise SEM system and Michael will then go into why we chose GitLab and why how GitLab fit our requirements and what are our challenges in making GitLab an enterprise tool. We'll start with challenges. So if you talk about evolution of SEM technologies, SEM is a foundation of all of DevOps, embracing DevOps in an organization. It provides a single source of truth because all your code is there. It provides a platform for CACD and doing DevOps in an organization. A good source control basically helps your company develop and application securely and in a faster way. So if you think about SEM as a technology in itself, right? SEM technology itself has evolved over multiple generations. If you think about it, first generation is when you were changing one file at a time. So one person was updating a file and the file got locked. Some examples there are RCS, SCCS. SCCS is the technology that was invented in 1972. So that was 50 years ago. The second generation was then multi-file. Essentially, CBS, SVN, some of these are fairly popular tools still. TFS is also among those. So that's the second generation. You could update multiple files at the same time. Third generation is basically like Git. You're working with change sets. It's distributed. So that's third generation. So what ends up happening is if you're in a company that has been doing technology for a very long time, right? So NM, Nordstrom Mutual has been doing technology since 1960s. So it's likely that you will end up with multiple SEM systems, right? Because some of these technologies were newer at the time and not anymore now. So what are the problems? So you end up with basically a fragmented source control system. So what is the problem with that? The biggest problem is imagine that diagram that you see there and the fact that you can replace the SEM there with the GitHub. Do you see a GitHub there? With multiple GITs or multiple SEM systems. You can have CVS, SVN, and other things as well. One of the main problems that happens is your code is fragmented, which means some applications live in one place. Some other applications live in another place. As a result, your developer permissions are fragmented, which means some developers have access to some applications or the developers have access to other. What happens as a result is lack of developer collaboration, which means if a developer creates a library that could be commonly reused across all of your software, where do you put that? There's questions like that. And high maintenance, obviously, if you have multiple applications you're having to maintain them, you have to update them. If there's security issues that you're releasing, you have to roll them out to multiple systems at the same time, patching. A lot of those problems happen at the same time. And multiple users, so it's a single individual, will be forced to get access in multiple systems. As a result, you're multiplying your license costs. So those are the problems. As a result, companies need a single enterprise SEM system. Why? Because consistent developer experience is important. It is essential across the enterprise. If you think about it, this is a system like an email, like a calendar, like a chat tool. SEM is exactly like that. And there is no reason why we can't have a single tool for the entire company. And you get standard collaboration features along with that, ability to roll out all the security features into one place in one sales group to the whole company. An enterprise SEM system, obviously, you consolidate costs, and you're saving on licenses and reduces costs. Also, you can manage all these permissions centrally. So having decided that we needed an enterprise SEM system, we, at our company, we started looking at what are the tools out in the market, and what are the requirements, right? Why do, what are, what is a tool that fits all of our requirements? And we started looking at our requirements. So one of the main important requirements was, was that it would, it has to be a modern tool, a distributed version control system, like Git, right, integrated into companies recruitment process. Obviously, you need to have things like LDAP. And when a person leaves the company, you don't want that person to have continued access to the code. That's very important. Things like standard collaboration features, you need to have pull requests, merge requests, standard UI, a good way to organize the repos, a good way to do permissions, all of that. Those are standard features. And I think we can expect those. Open source, I think that's a very important one, right? If you, if you are, if you have an open source tool, you don't have to be, you don't have to wait on the vendor to make those changes. If you have a bug fix or any feature that you want to add, you can go in and make a merge request yourself. Built-in CI platform, that's very important as well, because if you think about the diagram that I showed earlier, there were a lot of fragmented systems and consider having multiple CI systems and multiple SCM. You have Jenkins, you have Travis CI, you have Git Circle CI, and you have integrations all over the place. So that's, that's complicated. So it would be nice for developers to have one tool in which they can code, build, and deploy. So a CI platform which is built-in, it's actually very essential for any company. Obviously, you need to have security features, secure code storage, you need to have regular backups in the event of a disaster, comprehensive API, right? So developers love API. So they're, they like to gather a lot of metrics and collect lots of stuff happens there. So your, your API needs to be very comprehensive. Webhooks, in order to integrate to a lot of systems, external systems, like chat tools, MatterMost, Slack and stuff like that. Obviously it needs to be stable and highly available. You need to have the architecture needs to be highly available so you can spin it up in any multi-region way. And then cloud-native architecture, right? So modern, modern technology, modern CI CD, you need to be able to spin up your entire infrastructure using CloudFormation or Terraform or any of those infrastructure as code modules. So those are our requirements. And Michael will go into more details on why we chose GitLab and how GitLab fits the bill here. Thank you. So first, the best statement of support for GitLab was really that the way it came for the company, it's not like a backroom deal from VP with John trying to force us to use it. It came out from the developers. Someone thought it was a cool tool to try out, showed it to its team. It was cool enough to show to a few more teams. My little in two years, it came to be over a third of the source code what was on the GitLab. So really it's a really fresh way to introduce tools because I'm sure that if you work in a big enterprise and you try to introduce a new tool and try to force people to use it, it's a very cumbersome process. And so having a good set of users that want to use it is really freeing. Next, once we got to start to use it, it was the fact that GitLab had all those enterprise features, single sign-on, the logs, all the stuff that only audits on bigger companies care about, allowed us to keep using the tool despite all the security reviews that it would get to subject as it got a lot more attention. Once the entire department started to use it, the security team came on knocking, asking if it supported all those security mandates. And as well as the... So GitLab is very easy to start on your own from a single box. And then as we grew our user base, we were able to take out piece by piece all those components to make it a full HAA system that can support now thousands of users. So really being able to do all those changes little by little without having to break everything and declare maintenance windows was really freeing on the side of the maintenance. Third, all the features, just the existing set of features were really impressive compared to the concurrent. And for a lot of those features, as developers, it was really nice to be able to leverage set of APIs allowing us to extend those features in ways that GitLab was not thinking about. And so it was just the current features. And when we saw the roadmap of the future, it gave us a lot of confidence that we were choosing a tool that had a great vision long term compared to the rest of Git's base tools. The CS system removed a lot of friction, a lot of time, a lot of complaints from developers where it's so hard to, once we create our story, to get it to work with our NCI system. Having Ntlab CI embedded and easy to use was very freeing because it allowed all those developers to just get started on their own. They had to come to a central team asking for permission for a setup and to get rolling. On the features, as such as the web UI, allowed not only developers, but the rest of the people that they work with, designers, PMs, managers, being able to all work and collaborate on the same code and be able to try out stuff in the web. And it all being able to see those builds going into the CI system was really freeing because it frees time from the developers if a PM comes and wants to try out a feature like changing the color of the background. They can do so in GitLab, try out themselves and check those. So it's more time for the dev team to keep working on the code and help make more visible all that work that's going on. So once we decided to go with Ntlab, it was time to migrate everyone. And I won't lie, it's a lot of effort. You just need to keep communicating a lot to let people know it's coming. You have to leverage those users or those people that decided to use Ntlab before we told them that it was coming so that they could get the word of math going. It's a big change because we integrate SCM with a lot of stuff. JIRA, CI builds, lots of link server automations that we couldn't think about. All that was created by teams. So we need a lot of lead time before you can do it. Migration itself was really made much easier by the mass import. So it's a tool that's available in Ntlab. You just give it a list of repos, and it moves them for you with the full story or the merge request issues. So the hard work was getting those lists of which repos are going where. But once we got them, it was easy to execute those transfers for the app teams so that we saved them some time. We were trying to be a partner in that movement. We had to deal with a lot of inactive post stories. And for those, we always looked at the webhooks. If there is no webhook set up with a repo, it means there is no automation. It's less likely to be some automation that relies on those repos stories to work. We found out that some of those repos stories were quite critical. When we took them down, stuff started breaking. There is no easy way to find those before you do it. And something that saved us a lot of time is that we moved all the struggles of people not applying to take ownership of repos to a single M space so that they could easily find them. And finally, for the CI side, where a lot of people are still using Jenkins, we couldn't really give them a mandate to move to GitLab at the same time as they moved the ACM. It was just too much pressure on those teams. So for now, we still support both systems. And GitLab makes it easy to create those links between GitLab and Jenkins. Just a small graph to show how it went. We had a steady pace when we started with teams. We took advantage of the summer. Everyone was out on vacation. We removed all the struggles early. Instead of waiting at the end, we removed them when there was less activity to get a good start and really show a lot more progress to also force the APIs to put more attention. Like, we were getting close to the timeline. No one was to be the last team to move off of GitLab on CFS to GitLab. That's it for us. Any questions? Questions, guys? Any questions? There's one question over there. One question. So when it comes to adoption and getting all of the different platforms on board, how do you overcome the challenge of non-compliance or particular services being very adamant about not adopting new systems? So at some point, you need to get leadership approval. Every leader at the CTO level needs to get one level below the CTO needs to approve that this is the direction the company is going forward with. And that approval needs to be trickled down to the teams themselves. So that expectation, there is something called a tech mandate in our company that happens. Every technology team needs to do a certain amount of things every year as a part of that tech mandate. So we were able to get that into the tech mandate. So nobody has any excuse to get out of that. Sorry, and a follow up to that. How do you, I guess, convince people to be on board, too, in terms of being active adopters instead of fighting the process in each set of steps that we have when it's different from what they're used to? I feel like that's a challenge. That's true when you're talking about fragmented SCMs and people who are used to different generations of not just like SCMs, but different generations in technology in general. Is there a particular trick or mindset that you adopt, or is it a lot of just positively coaxing people? You have to be there showing, speaking on this change. You cannot just stay on the screen to do it. So for us, we did a lot of training to really get that message out that it was coming on, whether they like it or not. So at some point, you have to leverage your power users. People who are actually savvy, they like this tool and they want, they will be your advocate if the tool is good. And the tool speaks for itself because a lot of features and people who are using Jenkins using GitLab CI is actually much easier if you just create a simple YAML file as opposed to writing a large Ruby file, right? So there's features there, too, that convince the users to move forward. Hi. Could you talk a little bit more about the tools that you were using prior to adopting GitLab and then maybe describe what the source of frustration there was maybe within the organization that allowed GitLab to come in and be adopted organically so quickly? So we had several tools. We had, I showed SVN. We definitely had TFS, Microsoft TFS. We had GitHub, we had github.com. And we had GitLab. All these tools, right? And some critical applications were in different tools. And we still have IBM, Mainframe, Changeman also. We still have that. It's a problem. Much of our business logic is all over the place. The main problem was a person, if I want to make a change in another application, I need to get access to that. I need to go through a process, very lengthy process, because some of the business critical applications, you don't get access that easily. So going through that was a challenge. And that was, the frustration was evident in the teams. So that was one of the biggest challenges. And GitLab, when we started looking at GitLab and started moving off of github.com, started shrinking these other tools slowly and steadily. And GitLab became, attained a critical mass, right? Once you get there, then it's an easier sell. I think there's something that helped was that we kept GitLab very open. So it was very easy for anyone to get access to GitLab versus those other tools where you had to go through several hoops to get through it. So keeping GitLab open and keeping all the codes visible to everyone really helped people figure out, like, oh, that's the next gen system because it's so easy to use and to access. More questions?