 Peter Teague showed us how to build a strong foundation for an inner-source program in his talk. Now we'll continue to build our knowledge and understanding of inner-source. Gary will share insights into T-Mobile's continuous delivery platforms, including how they are built and the benefits they bring to the T-Mobile teams. Then he will share what inner-sourcing looks like for T-Mobile, including a deep dive into their CI CD templates. There are three main reasons why I love this talk. GitLab CI is one of our most lovable and powerful features, and I'm so excited that Gary chose to highlight CI CD in this talk. GitLab's enterprise-grade DevOps platform is a fundamental element of the continuous delivery platforms at T-Mobile, and you'll learn about that next. And everything we hear about in this talk is designed to increase collaboration and efficiency, two of GitLab's core values. I hope you love this talk as much as I do. Enjoy. Hello, everyone. My name is Gary, working as a senior software engineer at T-Mobile. Today I'm going to talk about inner-source templates built together, grow together. Thanks to T-Mobile and GitLab for this wonderful opportunity to me to talk this topic today. I'm really very excited to talk about how CI CD templates are using in our inner-sourcing development model in T-Mobile along with the CDP platform. CDP platform is a continuous delivery platform at T-Mobile. So this is my agenda for today's talk. The first one is introduction about me and my organization. The next one is a continuous delivery platform calling as CDP. Here the question might be raised, why do we need to know what is CDP and what is the principles, and why did we move here while talking about the inner-source templates? So continuous delivery platform is that first place where we removed all of the silos and we implemented inner-sourcing model on this platform. So it's important for all of us to understand what is CDP? How is CDP is operating? So the way is easy to correlate that inner-sourcing model, how it's implemented on CDP platform by using community templates, CI CD templates. So next one is inner-sourcing at T-Mobile. Here we are going to talk about what is inner-sourcing, how T-Mobile is leveraging the inner-sourcing model. So next one is community CI CD templates, upstream templates. Here we are going to talk about what is the purpose of these templates, how it benefits to our T-Mobile dev community and how it's reusable for the pipelines. Talk about me as a software, senior software engineer with 15 years of DevOps experience. I'm committed to the application of DevOps practices to derive the cultural changes within large scale organization like T-Mobile. Currently I am residing in Seattle, allows to spend time with my kids and music playing guitar and photography and traveling to the new places. Talk about my organization is just a T-Mobile interface technology solutions. You are calling this ETS. Over the past five years, ETS has been undergoing a massive technological and cultural transformation to adapt to an evolving landscapes. Go to this end-overs is the adoption of a centralized developer platform for all developer communities. And goal to empower T-Mobile developer to build a better software, faster, safer and healthier way. To be effective, we needed to instill a sense of collective ownership, self-service transparency and a commitment to a continuous improvement amongst our developer community. Okay, here we are going to talk about what is CDP and what is the overview of CDP and principles. So CDP is a centralized developer platform using a grid cloud. It's a consolation of all the pipelines into one CDP pipelines, which is the CDP pipeline for entire T-Mobile developer community. The way we are empowering T-Mobile developers to build the software in faster, safer and reliable way. So talk about the grid cloud. Everyone knows a grid cloud is one of the industrial based DevOps platform. It's a simple application for collaboration, visibility and the development. It's allowing from project management and source code management to CACD, continuous integration, continuous delivery, monitoring and security purpose. How we are empowering T-Mobile developers by using CDP. We are providing a N number of upstream templates and developers can easily onboard with a self-service model at the less than five minutes to CDP platform by authenticated through Okta services using their NTID. Okta is one of the trusted platform to secure every identity from customers to your workforce with single sign-on, multi-factor authentication and also having the lifecycle management. Empowering means it's empowering developers to speed up their development without any obstacles, without any struggles over there. The frictionless migration is one of the most important key. Frictionless migration from other pipeline is under 30 minutes by include the upstream template to set up our CACD jobs pipelines. It's enabling a reuse and collaboration by offering a common scripts to all pipeline tenants. CDP platform in the industry standards to empower developers meet their needs and want and build support, the accelerated or option required. Creating transparency is a key factor for the NSOS model. Creating transparency and remove the bottlenecks is a goal to this platform as everyone have visibility of where the code is residing, where the code is placed at any given point of time with self-service capabilities. So this is the other principles as a real-time analysis architecture for safety. It's very hard to do anything as implemented the God trails implementations. It's a SOC compliance application and it's a continuous improvement and commitment by keep improve our platform. It's a collective ownership means one team is owning this platform is owning by the developer dev community. Here we are going to talk about what's the benefits of CDP? Before going for the benefits, let's talk about why did we move to CDP? This will answer, it will answer that what's the benefits of CDP as well as. So why did we move to CDP? Previously, we relied on multiple pipeline strategies which is unique and maintaining by each team. However, this approach resulted in this jointed paths and ambiguous directions regarding standards of DevOps and the CICD best practices. The absence of a unified approach created silos and hampered collaborations amongst the teams and the lack of standards that resulted in fragmented integration efforts. Also, there is a lack of transparency which is a key factor for that moving to the NSOS model. There is a lack of transparency and dependency between the payloads across multiple environments in these complex ecosystems, complex interdependent ecosystems. These are the main challenges we faced without having a standard, a sustainable one platform to implement that DevOps best practices also implement the NSOS model. The catalyst for the change came in the form of one outage on our core source control management server calling as ACM servers using for our CICD's purpose. It's lost in several days, we're restricted in our ability to deliver our software and it's making a huge impact on the organizational level. It was high. It's making a lot of productivity, loss of productivity and money. Also, it's making a impact to the individual levels also with that day and night, a couple of engineers work together to resume the service and it's making a stress note as well as. So that time, the situation was very clear. Our current approach was not sustainable, means it's not sustainable to bring it if any outages or any impacts happened on that server. That time as a team, we decided, we made a decision to have a complete one platform as a sustainable platform and do a complete overhaul of our legacy platform and migrate to one platform, which is our good club countries delivery platform or CDP platform to provide our developer community with a single and unified delivery platform. This was a step forward delivering our goal software and the reliable, fast and healthier way. So let's move on to that benefits. It's a one stop for all of our CACD development across our teamable dev community. This is the only platform going forward and currently team is using for their CACD development needs. It's giving, it's powered by the GitLab as mentioned, is one of the leading best standard tool in the industry. It's next one is a unified pipelines for deployments. It's allowing developers to deploy that payload to environments by using a standard defined pipeline. It's a developer-driven platform. What's the means of developer-driven platform and shared ownership? It's not a one platform and one team is maintaining it. It's a platform for entire teamable organization for the CACD needs, maintaining as a collective ownership, everyone is a developer community. So the way is keep continuously improve and keep continuously development to make a better place to deliver your software, make your developments, CACD development needs. So that's why there is no separation of dev to CACD activities. Dev also informing CACD activities also as a part of the NSOS model. So how does it measure for that one? Sound wave percentage of development of CDP being done outside of this, our community CDP team. Means developer community is continuously contributing to our CDP platform by making changes, providing the suggestions and code changes. That's overall the sound wave percentage. The next key factor is metrics. Metrics is a key factor to measure the success of the key KPIs across the portfolio. I just create the benchmarks for the process and track the progress as well as. Okay, here we are going to talk about what is inner sourcing, how it's using in our team mobile, how we are leveraging inner sourcing model here. Inner sourcing is the use of open software, open source software development model, using a best practices and the establishment of open source culture within the organization. The organization may still develop proprietary software, but internally open up the development. That's what it's calling as inner source here. How it's helping, inner source helps team mobile, accelerate development and innovation through the application of the same practices and inclusive culture that make open source software known for its quality and speed of innovation. The way is making open source at that enterprise level and making us a speed of innovation as well as. The open day working as a group will provide tools, environment, advice, as well as the services to promote and support this culture shift. It's a main culture shift from closed as a default development model to open model as a development model. So what are the inner source community manifest to? I am open and inclusive. Yes, here is the main key is I'm open and inclusive. It's open to the entire team mobile family and there is no prerequest or conditions exist for participating in the community. And making changes across this community also. The next one is I help and ask for help. It's another key values for this inner source community. Creative corporations and collaboration is a spirit of people standing and working with other people under a common goal. The inner source development community is devoted and lubricating the process of opening a code basis within the company and fostering all kinds of contribution to the code basis. Across a team, also domain boundaries. Anyone is free to offer the help, but project owners are the key factor or are piters of what is acceptable for inclusion to this project. Means the key opposite is a project owner. The project owner will decide what needs to be allowing into their project by reviewing the changes. The next is I'm transparent. Transparency is the way we are talking about that open source, inner source model here. Transparency is a community projects are open for anybody within the Mejanda family to read, allow to read and modify the code and submit the changes as well as. Discussion and project decision making should by default happen out in the open. Acceptance criteria for contribution should be clearly and for truly documented and applied equally without any regardless of the source of the contributions. The setup and onboarding process for a trading locally on contribution should be clearly needs to be document and documentation is the key factor to maintain the quality of this inner sourcing. Clear documentations and description of what we expect to maintain these inner sourcing models quality in that long term way. I act now, immediately, participating now with a purpose of overcome barriers that stand between us and our goals. Culture and community are the constructs of any human-centered organization. The anti-teamable-due community is responsible for the collective quality of all our software products and developments. To donate this is our open source fundamental, which is created at corporate level. Yes, it's a open source culture within the organizations calling us inner sourcing. How we are liberating that, how team-able leverage is inner sourcing. All developers in the community can read the code. As mentioned earlier, there is no barriers or there is no prerequisites. The developer should have this certain access level or certain group, part of this group to go and read others code or others code across this team mobile or CDP platform. Means there is all the developers in the community can read and use the code. There is no conditions, there is no barrier on that one. Also, there is no barrier on making a contribution, make the contribution to make the changes to make it more effective on the software. How did we achieve this one? Every team-able employee as granted is a reporter level access, reporter role access when they are joining to a team mobile. So reporter access are granted at the team-able, which is the top level subgroup for all the source code. So the way a reporter role access enabling them to go and look around all the codes under the team-able subgroup, which is our platform level, all the subgroups, they can go and read and they can make the contribution as well. It's making more exposure to the different approaches and techniques and solutions. The way developers are having access across all the codes, they have exposure to go and look at all the other codes. They feel how the team is working on it, what are the approaches they are currently using it? Is it useful for me? Go on and take it and use it. The techniques is making more effective on that place. Yes, I'm happy to take it over there and using that one. Solutions also is important. What's outcome has come through this project? What the outcome they are getting, what the benefit they are getting it? The way they are going and take and use the code. So the way team-able leverage inner sourcing is making the open source culture within that enterprise level, means the inner source model. Finally, it's a fundamental culture shift from a default close to a default open mean. Everything is open here with a limited, with that enterprise level limitations. So developers at team-able can go and read the code. Okay, let's talk about what is community CI CD template, which is calling as upstream templates or TMO community templates. This is templates are adding various features to your GitLab CA YAML file using include you directive. Means you can include the templates to run your setup over CI CD jobs or pipelines. It's easy to, it's easy to maintain at the upstream level, one place. So everyone can view, okay, what is the place, what the team is doing, what changes are upcoming or changes are going to make impact the next level. It's easy to reuse fashion. Means in only to write the code, everybody's coming and writing the code, but the code is already exists. The code is already using successfully by a couple of other teams. So there is no need to write again and again the same code. Means it's the same code. So reducing the burden of writing the code. Yes, that's the main key factor of upstream templates. It's a reusable passion. So these templates are achieving various functionalities and various futures, which you could include in your pipeline for to for your CI CD needs. So as I mentioned, CDP community, CDP is collective ownership between teamable dev community. It's not that one team is owning that one or one team is maintaining that one. CI CD templates maintaining by developer community, by developer, TMO developer community. So the way everyone as part of TMO developer community are maintaining our ownership and taking a responsible for continuous improvement and commitment. So the key we measure currently out of 850 mergers as a merge request, 640 merge request are submitted by the community people, not by the CDP platform engineers. So the way is enabling NSOS model, everyone is contributing to make a better place to make a better solutions to T-Mobile. It's a single source of truth. It's a single source of truth means this is the one place, only one place at T-Mobile for all your CI CD needs, CI CD platform to deliver your software in that secure manner. It's a well-defined and diverse practices manners. So how we are ensuring the single source of truth. Code oneness is option provisioning from GitLab where you can maintain that owner of that groups or shared groups. So the way it will ensure the specific people or groups are responsible for particular templates or file. Make it clear here, this code oneness ensuring all the T-Mobile developers, the reporter level access as well as also certain projects are also adding a futures for their pipelines, which is making us, they are the group owners or code owners for that particular files or changes. That the code owners option is giving to maintain the users for the shared groups. It's a reusable fashion. As I mentioned here, upstream community templates for job and functions, you don't need to create until the code, until the same function does not exist at the CDP platform upstream level. So here the community templates are providing multiple futures. I would like to talk about the couple of futures. One is of functions. So what is functions? So the function is group set of commands or group functions are going to help you to achieve certain functionality. I would like to say, take the example of PCF, the Utah Cloud Foundation, which is our major deployment model and deployment platform. So most of our applications are deploying over in PCF environment. So these templates is giving that, giving that functionality and future to allow you to deploy the code into the PCF platform. If you have your groups or environment is ready for your code, you could come and plug in or include that function template in your upstream pipeline file, which is GitLab's AML file. Then you run a pipeline. The pipeline will go and pick up that functionality from the upstream level. It will pick up the changes. It will pick up that functionality. It will allow you to go and deploy the codes on the PCF environment. Make sure for that one, you should have access on the PCF. You should have the groups. You should have that all and place where you have to go and deploy your code at the PCF environment. Then next is the job. As a job also part of the template, the job is provisioning a group of fully packaged solutions. It means you are going to include the function as part of the job template as well as, but it will give the future to make a decision where the code needs to be deployed at the environment level. It's a dev or NP or production level. That rules are enabled at a job level. Example, as a team, I want to make sure if my code is coming through any non-drunk branches, non-drunk source, means it has to be deployed at a dev level only. It has to be deployed on NP level only. So the way the rules are enabled at job template level, hey, this code is coming non-drunk branches, okay? Allowing me to go and deploy on NP level at NP level only. And that rules are enabled in the job. So the way how the developer is coming and using the job template, as I'm the new, I'm the developer on the teamable community, I have my application, a build, and it's ready to go and deploy on that PCF environment. So I will just include the job templates in my CACD pipeline file, which is a GitLab CML file. I will mention include example of a teamable template and PCF job file. So the way, once you commit the changes, that rules will make a decision, okay, the code is coming from non-drunk, I'm going to deploy into the NP location as you define in the job template. That way job templates are using to make a decision where you have to deploy the code based on your source code branch. Next one is that global templates where the global templates are a key factor to make sure we are following TMO standards and we are ensuring the security things are following and there is no violation as well as. So teamable templates are stage or job is calling as TMO, it's a stage name. The jobs are calling as a TMO jobs and as a validations and a couple of other validations. What this TMO job is doing it? What is the TMO stage jobs are doing here? So this is the first place or initial job for any pipelines in T-Mobile. Make sure you are following the standards and it's ensuring to deliver the certificate, TMO certificates to make your runner is working to across other environments. And it's making that make sure to the assets are tagged as a NSOS model, we have to come as a one place for any development model as a validation. Also other factors that matrix collection, key factor of our monitoring the progress and make sure this progress is going through port and measure the throughput certainly. So at the T-Mobile stage level, T-Mobile stage level is the first stage we are collecting the matrix, we are make sure that security, we will make sure that TMO certificates are delivered to connect to the other other environment and that other couple of validations as well as. Okay, we implemented this NSOS model, we implemented upstream, but how we are maintaining, how we are communicating to the all developers, right? The developer is coming, how they will know what are the futures do we have? What are the good things? What are the options we have to go on board and start my DevOps journey on the CDP platform, continuous delivery platform? That's what we are strongly believe that documentation is also another key factor for the DevOps model, for the DevOps standards. So we documented, we documented all the things, what we did, what we delivering, what we developed, where we are maintaining it. So all the CDP templates are, all the CDP, sorry, all the CDP documentations are maintained in the CDP community hub. CDP community has been developed as a MK docs, is a fast and simple static site generator provisioning from GitLab, thus generated towards building project documentations. Documentation source files are written and marked on and configured with a single YAML configuration file. So it's a static website. So you will come to here and you will click on that, our CDP community hub link. You will come to the beautiful page and it will give you all the tabs. It categorize the sections, okay, where I need to start my, where is my starting guide? Where is my onboarding guide? And second tab would say is your standards and best practices, okay? As a developer, please follow these as our expected standards and best practices. And third tab would be your templates, where it's going to tell about, what are the templates are existing in our community, in our CDP, so TMO CDP community. So the way developers no need to go through across all that entire source code, instead of they can easily get the links from this community page, it will show, okay, this is your PC, this is your mapping, this is your NPM, what are the features that we are provisioning, what are the options we are provisioning, you will come to know in that CDP community page itself. And next would be as ever FAQ and Recipes. Recipes is giving the example of any type of jobs or any type of futures. So as a developer, I want the examples to start my journey. So the way I'll feel more comfortable, if I have the example, how to build the core and mapping and how to scanning the security, what are the scanning options or 45 scanning, whatever. So the way I will ensure the code quality, then I will make sure to build and deploy, deploy the NM. So if you have a good recipe, if I have a good example, so it's easy for me to start my journey without any obstacles. So that details are provisioning in our community hub page. So these are the overall of our community, CI CD template, which is NSOS templates, how is helping in our steam mobile by using our continuous delivery platform to implementing the NSOS model. So what we talked about here, the overview of this complete package here is, we talked about the continuous delivery platform, which is our one CI CD platform for our entire teamable dev organization, dev community. Second is what is NSOS model, how we are leveraging at teamable level. So how upstream templates, CI CD templates are using as part of the NSOS model. So thank you all for this opportunity. I hope you gave that information. So what is the NSOS and templates we are using and teamable, it will be helpful for you and everyone. Thank you everyone.