Conf42 Platform Engineering 2025 - Online

- premiere 5PM GMT

Platform Engineering Meets SCM: Unified Policies, Access, and Automation Across Git Systems

Video size:

Abstract

Managing GitHub, GitLab, and Gerrit for 50K+ engineers isn’t just infrastructure—it’s platform engineering. Learn how we unified access, security, and automation across SCMs to deliver scalable, developer-first experiences in a multi-Git world.

Summary

Transcript

This transcript was autogenerated. To make changes, submit a PR.
Platform engineering meets thought code management systems. Today's topic is going to be focused on unified policies, access and automation across GIT based platforms. Who am I? I am, it's called me around here. I have an MBA and an MS Degrees. I'm a senior staff IT engineer manager at Qualcomm. I lead a global team, spread across various compo continents. I manage GI systems or the GI platforms like GitHub, GitLab, Garrett. The user base is around 50,000 plus engineers. If we talk about bot accounts or service accounts, I'm not surprised if it reaches around a hundred thousand accounts. The focus of my team is primarily about developer first initiatives. We provide secure, scalable solutions. End of the day we want accelerated software delivery on what we are doing at Qualcomm. At large, organizations like Qualcomm we have various systems. Whether it is SCM systems or other systems, we have a, we have, I'm not surprised if there are around thousands plus, right? The policies accesses are all fragmented. How can we unify them without unifying them? What is the impact? As we know, the impact would be developer friction, time consuming activities. End of the day, the velocity will be huge. So let's dig into deeper how we can fix the problem. SCM is considered as platform. It's not a tool if some organization is considering GitLab or GitHub or Garrett or any SCM system as a tool, I sincerely believe that they have a problem at hand. SCM is the backbone for developers, right? What developers, what do they do? They develop code, the write code. Where do they write code and where do they push? It is all around SCM. So the utmost importance should be given should be given to that system. It, if you're considering it as infra, no. If it is just an application, no, it, because it is a platform. It is integrated with lot of other systems, so we need to treat it as a platform and build in governance should be considered. Now let's talk about develop initiative or the experience. In the past, user management was a struggle. What do you, what do I mean by that? Developer starts developing his code once he gets a license from one of their CM systems, right? Say GitHub, right? You need a license, right? So if there is a manual process tied with it, if the user management is not seamless, if it is not selfer, then we have a problem at hand, right? So activation should be seamless and then comes a deactivation because the business side of things, Hey, your activation is seamless. Everyone is getting a license nowadays, and it is incurring opex for us, right? So there should be a deactivation process, which is also seamless. Then comes a reactivation. What do you mean by that? Hey, now you deactivated my account, but I'm back into the project. I need to activate my license. Show me an automated way to reactivate. So all these things tied together brings in the user management. The most important thing is you should think about all the cases and automate the system and make it self serve so that the productivity of the developer or the engineer will be increased significantly. Then comes the required systems to provide. A place to develop because we are talking about GI systems, which I'll consider a repository to begin with, Hey, I have the license. What repository should I interact with? If that sort of information is not provided a automatically. And what sort of hacks do I need? Hey I need the read read permissions to read the code. Now I need the push permissions to push the code so that, people can consume my code. All these things should be automated so that the onboarding process is as seamless as possible. So you need to be when you are managing the platform, developer first experience should be back of your mind so that everything will. Seamless. So now I have the repository. I have the SI can push the code. What af after that? What are there ci cd pipelines integrated? Is there a template which I can leverage? How is gittel objects are managed? All these should be either documented or clearly communicated to the developer community so that they won't scramble behind the scenes. We initiate, we have an initiative where there are some public repositories designed so that the pages or the Read me articles are published for the end users to consume them. In that way, we are, we always have the developer first experience of the initiative in our perspective and deliver it in a seamless fashion. Then comes what? How the code reviews are happening. As a developer, I need someone to develop to review my code that's given, right? With AI nowadays, is there a platform which we can build for automated code reviews? GitHub has GitHub copilot. GitLab has dual, but there is a license associated with it. Then it goes back to the license management, how seamless the activation is. Are there any other internal AI systems that you guys developed, which can be integrated for automated code reviews? Eventually, when an automated code review happens it, it helps the whole developer community. As a developer, I push the code, it is automatically code reviewed. I can address the code review comments, and once it is ready to go, I can take that change to the lead for the review. Everything is automated. The time to market has improved a lot, right? Our end goal should be that. Now let's talk about unified accesses and policies. Yes. We need the unified accesses and the policies, right? How do you achieve that? So the service providers or the platform owners should be cross-checking on how, what is the scheme provisioning going on? Can I integrate the skin provisioning across all the systems is self is SSO enabled so that if I log into one system, I can easily interact with other system as well with a click off button, right? Think in those lines. Then comes a classification as I'm working on project A the, what sort of classification are we talking about? Is it proprietary? How complicate how complicated this project is when compared to project B? What sort of sensitivity I need to deal with? Can I clone the repository locally and start developing, or they, should I be interacting with a different system to interact this piece of software? All these should be considered and the information should be given in a seamless way for addressing the developer needs. Then comes the external collab, right? Yeah. I'm working on project A and project B. All, everything is internal, so I'm good. Now, let me I'm working on project C where I need to interact with external users. That means Google for Qualcomm probably, right? So watch collaboration controls I need to be enabling, right? How is the service provider providing that? All these should be vetted properly, is guest collaborated In GitHub world, there is a pro concept of guest collaboration, right? Should I be integrating that so that the, and the external user won't be accessing the repositories, which they're not supposed to, right? These things should be considered, and the policies are designed so that the compliance is achieved. And any anomalies can be controlled or detected in a proactive way than a reactive way. Automation is the backbone, right? They said we can streamline the processes by automating end to end. I know it's a term where, hey, I will automate everything. But what do you really mean by that? Right now, our focus primarily is analyzing the logs. We have a event based listener and we created some runbooks for each event. What sort of action we can take this? The platform is designed so that, end-to-end everything is automated. Let me give you an example, right? A create action for a user is created on an SCM system. The event listener, listening to that event, that means in that means the user just got created. What sort of action I can take for him? Can I send all the required documentation for the user? Because he's trying. He just got created. Yes. That's an actionable runbook that we can create and send it across while, in another example, I just created a fork for a repository, which may not be needed because of X, Y, Z reasons. So the event based listener, listen to that event. Communicating that proactively to the end user saying, Hey, you created a fork, but you may not need this fork in this area. Why don't you consider the fork in this area? I'll give you one more example, which could be interesting because nowadays with cybersecurity coming into picture this could be critical. So this. In GitHub or a repository in GitHub is configured to have a low listing. That means certain section of ips can only access this particular repository. The even listener, even basic listener, listening to that events and somehow it came to know that, oh, someone actually changed that allow list by removing some of these ips. So the event base listener caught that and sent a reminder or sent a notification to the security team or Goor, as well as service providers so that they understand that and take an actionable, a could be an action taking an action, right? That action could be asking a question, Hey, why did you make this change? Why are you removing this IP yellow listing? Or if there is integrating another ip, that's another event for a security team checking for, why this IP is added. Now all these things are critical. So automation is the backbone. Now comes the enterprise governance. I'll most likely talking about MSP primarily MSB is minimum security baseline, right? What sort of minimum security you need to create. For your application, that is the key. What sort of I'll give you an example. So for every org created in GitHub, I do not want any public repositories under it. That is a policy that is a minimum security baseline, which you could consider. That means only the internal repositories and. Private repositories can be created. That is a policy change, which you can enforce why this matters. Some cases you don't want to expose your code to non-authentic users. Public repositories have a tendency that it can be accessible by everyone, including guest. Including the guest, right? Could be a problem. So consider that, right? What sort of minimum security baselines you need as a platform owner or a service provider. You need to work with your security team to understand what this MSB means and what sort of policy should be enforced. Code secret scanning, right? Nowadays, scanning is becoming the shift left initiative where when a developer pushes the change. Immediately these scanning tools should get triggered if there is a need for CICD platform design that, but some of the CM systems already have a mechanism out of the box solution where it it scans the code, which code QL or gas, which is GitHub, advanced Security. All these are designed so that, once the change is pushed, all these scanning will happen immediately so that it can be fixed right at the beginning. The problem in the past was if it is not fixed at the beginning stage itself, then these buggy code somehow gets released and integrated into the product. It's too late then fixing that. Product and coming back to the coming back to the developer community to fix that bug. It's very costly. So addressing all of that with the shift left initiatives, particularly on the advanced CM Systems, is critical audit dashboards. This is centralizing, the audit dashboard is critical because there could be multiple teams in your enterprise are interested in auditing. Their needs. Security team needs one thing, DevOps community needs another thing, developer community needs some other thing. Product management needs some other thing, right? All these should be integrated so that the dashboards are created for the right use cases and all of them are centralized, so we don't, it's not going to be a sprawl across the board. Balancing dev experience and dev developer experience and security. Developer friction is the highlight here, right? As we know hey, I'm doing all of these to make sure our environment is secured. I'm doing all of this to make sure the product will be launched at the right time. I'm integrating this because of that reason. This reason, everything is there is a reason, but developer all, most of the developers care about. Can I develop my software and push it in? So you have to balance what you're doing. I'll take you another, I'll take another example as we are discussing about AI based code reviews, right? From the developer community, they believe that this code is written this way. It doesn't need a refactor, but the AI based code review is coming under the picture and with the policies which we designed, it is checking for a lot of things and it is giving left and right. So many code review comments. There will be a developer friction, right? So adapt the policies accordingly. By embedding the configs in our ci cd pipeline accordingly for a project or a repo based, don't make it like a generalized policy so that every developer will follow the policy, right? There will be a friction if you go, if you design your systems like that. So always consider the developer input or the leads input and design your policies accordingly, if needed. At the repo level or the org level or at the enterprise level. That is most important thing because we, happy developer, happy engineering community end of the day, deliver the best product. We implemented all of this in Qualcomm. We have seen best results I would say. Access sprawl reduced by 46% which is tied with the user management and the access controls as we discussed. There is no more confusion on where to go to get a license or where to go to access a repo. Everything is streamlined in that way. User onboarding has significant earlier it took hours and hours, probably days in some cases where one user, one operations guy is out of office. No one has known how to do the user onboarding process. All of these evolved to a streamline approach Nowadays every user should be onboarded in less than 30 minutes. Instance response times has lowered by 73%. That means, we are resolving the incidents faster, way faster because this automation processes with the chat bots, with the AI based chat bots we know the KB articles. We are inputting the KB articles to the AI systems. And the operations, the support team knows how to fix the incidents. So the response rates has, has evolved. Finally what are we looking ahead? We're looking at ai ai, right? How can we improve in every angle possible for platform engineering through ai? How can we predict we how can we predict the user activities upcoming next activities, what sort of security cons analytics we can come up with what sort of user load be it all these are predictive. We are predicting by analyzing the logs through the Log analyzer tools, which we built. Coming up to the conclusion saying, oh a BC day x, y, z days from this geolocation, the number of hits will be significantly high. We are predicting that these nowadays with the AI techniques, which we adapted which we designed some tools around it, and we are taking, we are we are looking at how we can improve it further. The, we are improving, we are trying, we are finding ways to improve the developer productivity with the compliance harmony. Thank you everyone, your time.
...

Vasdev Gullapalli

Senior Staff DevOps Engineer/Manager @ Qualcomm Inc

Vasdev Gullapalli's LinkedIn account



Join the community!

Learn for free, join the best tech learning community

Newsletter
$ 0 /mo

Event notifications, weekly newsletter

Access to all content