 Thank you very much. Hello everyone. I hope you're all staying warm and this silent discuss setting is very interesting. So as you probably already know, like my talk is going to be about driving cultural change to improve software development and CI CD. My name is Roland Heuser. I work for SRI International. I'm a software engineer and just to, so my, the field that I work in is microservices, DevOps, and I work with the SRI Ventures team to transfer technology from our researchers to our ventures and our clients. If you haven't heard about SRI International before, we are a research company in Menlo Park. We've been there for over 70 years. Our main clients are the US government and a lot of commercial clients. We've been around for over 70 years. So this was basically me when I started at SRI three years ago. So like you're ready to go. You want to see all the problems. You want to design solutions for them. You want to implement code. And you may have found yourself in a similar situation where you want to get going. You want to, yeah, you want to like start collaborating and figure things out. So processes and as you start looking left and right, you see more and more people and you see mud going all around you and you may or may not start feeling a little bit stuck in the dirt. So what happened? So in 2017 when I started SRI and some of these things are still true today, but we have a lot of different groups and teams. So we have five divisions and inside each division we have, yeah, five to ten like groups and they all operate very independently. Some of them don't even use our corporate IT services. So like they have their own IT services. They used like different repository systems based on their current needs and depending on if they work on government contracts or if they work on commercial contracts they had different policy and compliance requirements. Many of these tools were in self-service so you either had to reach our corporate help desk or of that particular group their help desk to help you. And one of the challenges for my team that I joined with was we were tasked to work with all of them because we were trying to introduce them to microservices like how to implement them. And so we're like, well, now we have to learn how to interface with 20 different systems and it became a big burden for us. So we felt like this biker or cyclist just like and we see this wall in front of you and we're like, well, I just see problems. Like how can I continue? Like we need a better way to work together. So we knew something had to change but we were a very small team so we didn't have enough backing from management or we didn't have anything that would allow us to make the entire organization change. So spoiler alert, we made it somehow and I'm going to talk about how we did this. So from the status code to now about two and a half thousand projects for we have in our GitLab instance we have a little over 500 people so we have five projects per person. How did we get there? So when I started in 2017, as I said, we needed to find a way for us to work with the other teams. Unfortunately we didn't have a lot of compliance or policies imposed on us so we went ahead and just spun up our little rogue instance of GitLab CE. We started hosting all our projects on it and started pointing, started and told people, well, just go look at our instances as our code and we started collaborating with them in this way. A lot of people got really excited about it and they're like, well, we want to put our projects on there too. So we started adding them by a case by case basis but fairly quickly this case by case turned into a lot of projects. As we grew we realized based on feedback that we needed more capabilities. So we started adding features like more CICD, privileged runners. You may or may not have heard about problems with privileged runners. For SRI, since we have a lot of government work, we want to make sure that if two projects run on a shared runner that they can't modify the host. Docker build, for example, cannot run in a non-privileged system. So we needed to figure out a way how can we do this without running into compliance issues where we accidentally modify our host. One solution for this would be an alternative build system like Canico but back in 2017 it wasn't that well established yet. We later realized that we needed backups. So towards the second half of 2017 we started backing up our system and towards the end of 2017 corporate IT and our Center for Software Engineering that provides a lot of services that we consume internally, approached us and said, so who is running this GitLab CE? We don't know who in the Neater Corporate IT or our IT services are providing it and our team were like, well, we kind of do. And they asked us all these questions, well, so how compliant is it? Can we put ITAR projects on it? And I'm not a citizen so pretty quickly we realized that we needed to change this. Fortunately they didn't tell us to stop. They recognized that there is a huge benefit in using GitLab. So they did a threat assessment. They worked on creating multi-factor authentication using the Git CLI which I haven't seen another tool providing this kind of capability. And by the end of 2017 we had a GitLab EE instance spun up. In 2018 this was our kind of migration year where we migrated almost all our systems. We also discontinued all of the redundant systems that we had. So that was a big year of like getting rid of licenses that we no longer have to pay. And in 2019 we basically just worked on increasing the usage of our current GitLab instance and even upgrading it. So this is how in just a few minutes how we made this entire migration process. So what helped us transitioning from the status quo to where we are now? I identified six factors that I think we did right that helped us for this migration. And the first one would be leading by example. So we started finding a system that fits the needs that we had and we started using it showing other people how we can be successful. Then the second factor is templates. So we don't just like lead and show off crazy tricks, we also show them how we did it and so that others can learn from how we achieved it. So the others can learn from us how they can achieve what we did. Another important piece is education. So together with the center of software engineering we started setting up like a help desk email specifically for GitLab. We started adding channels to matter most so that they can collaborate or ask questions. We provided hackathons and demos where we used GitLab so more people got exposed to it and saw how it can be used. Our fourth factor is evangelism. So at the beginning when we started using GitLab we didn't expect it would cause such a drastic change but like just the people seeing us using it and getting excited about it kind of snowballed and helped getting GitLab like get corporate IT and everyone else excited about it. So I think evangelism is a very powerful tool that we had. And then oops, I went one step too far. Feedback I think our center for software engineering and all the people that were involved setting up the GitLab instance did a great job at listening to the feedback that people brought to the table. So when people had issues with GitLab runners if they needed help integrating in existing infrastructures and how can we use it with Kubernetes, how can we use it with our artifact delivery system like our people they are very responsive and they set up documentation and they helped everyone to be successful. And then the last piece is compliance. So while our first instance of GitLab was not compliant our current instance makes it very easy to bring compliance with all the restrictions and requirements that we have. We put a lot of energy in automating our compliance process where before you had to send emails to people and they had to add you to a project or even set up the project and they had to ask your manager or other people to get approval so it was a very slow process that could take days. Now with our current compliance process how it works is we can set up the project, add a configuration file and that will be picked up by an automated system that then actually verifies who can have access or not. I'm going to talk about this on this next slide a little bit more because as I just started mentioning compliance can get a little dirty and sometimes it kind of hits you in the face with a lot of dirt. As a government contractor we have to follow like CUI and ITAR restrictions and as a commercial contractor we also have to follow their contract requirements. In one of the things we did is we decided that hosting on premise was the right choice for us so that we have more control. Then what I mentioned earlier is for Git we added a plugin that we can do multi-factor authentication especially for external collaborators on our system. Then the groups for example top-level groups on GitLab are managed by our IT services but self-service is very important so all subgroups are managed our self-service and projects are self-service by default. So whenever I need a project I can just create it and as I mentioned I can add a meta file that says which contracts this project is associated with and then our bot will read this file and decide if that project is one that is access restricted or if it is access unrestricted and if it is restricted how we manage or how we ensure our compliances is that nobody can inside GitLab can add or remove users at that point then we just use an LDAP process where we just use them through our where we add and remove users through LDAP and admin will do those changes. So what is the result? The result of this process is that we have self-service infrastructure. I think this is a very important piece that that we initially didn't have and that we were able to achieve with GitLab so that people can self-provision things like they have to ask permission for everything it takes a lot of energy and time. We greatly facilitated our compliance process. We made it after the fact that I can create the project and then I go through the compliance process and it's also more transparent. I know how these how our compliance process works because I know how the company decides on what information these decisions are being made. We reduced a lot of cost because there is less waiting. There is a lot less communication for us to get repositories set up and configured. The maintainability has greatly improved. Our Center for Software Engineering always tells me that the frequent updates on every 20 second are a blessing and a curse. They always get the latest and greatest features that everyone wants to use and they regularly update the system. We improved collaboration. The takeaway that I hope you take from this talk is that start small with a small instance. Make sure that it works for your environments. Try out all the different settings that you have. Try to delete by example. If you try out everything that you use at your company, you can see what breaks and what doesn't. Make sure you automate your compliance processes or make sure that they have as little friction as possible. We invested a lot of energy in setting up documentation, especially where we deviate from standard documentation that GitLab has. This is what we do differently. You should pay attention to. If you want to know how a merge request works, go look at the standard documentation. If you want to know how pipelines or the YAML configuration works, go to GitLab. I actually went way faster through this presentation than I planned to. I think this would leave some time for questions. You're going around with the microphone. We do have time for questions. Anyone have any? Here we go. I'm particularly interested in more details on the automation you've done, particularly around the ITAR compliance. If you want to have an ITAR or some other sensitive DISTROD project, what kind of things do you do in your compliance process to help that out? That's a good question. I'm trying to think how I can best answer your question. What we do is we have ... I'm going to circle around your question for a second. When we create a new project, we have this meta file that says which contract it is associated to. That will be picked up by our automated system, which then will notify one of our admins that this is a project that has been labeled as ITAR restricted. Then we have a group that will go through the export control if we want non-citizens to work on that particular project or verify who can have access. What then will happen is that they will reach back to the person who created that project and ask who else they want to add to it. Those people will then respond and they will check the restrictions on that project and add them to the LDAP group. I think your question is more around how they ensure the ITAR compliance. Our meta file includes a list of all the people that we add, all the people that we want to have access to. It's basically a YAML file that we customize that the bot will pick up. I think that basically solves that problem. Does that somehow answer your question? Okay. Okay. Just one moment. Congratulations again on the radical transformation. I have two questions. Thanks. Any challenges that you've seen with import? Did you import from native Git or is it from another provider? We had a mix of multiple. We had a lot of different on-premise versions from all the GitLab competitors that you know. We had SVN repositories and we had Mercurial repositories that we had to migrate. We went through all of those. Any specific challenges you would like to give us feedback? I think the biggest challenge we had is that a lot of teams love their autonomy. Why should they migrate to a corporate IT provided service if we can just do it ourselves? Why now do we have to add this meta information to each repository, which is just one file, but there is still a challenge around if you feel like they lost control over their baby. I can understand that, but at the same time, GitLab brings so much more benefits that it's such a small drawback. Great. Thank you. Hey there. So I'm curious, how did you guys go through that migration process of migrating from SVN to GitLab? How did you guys handle that period where you may be working in both environments and dealing with dependencies that may exist in both ecosystems? Yeah, I think in most of the SVN repositories, we were fortunate enough that we could use the migration script that retains the changelog and just migrate those repositories. We still have some huge SVN repositories remaining that we can't migrate at once because they're gigantic. So we have to chop them into pieces, but in general, we were able to just migrate them in one step.