 Victor Wu, I'm a product manager here at GitLab and today I wanted to show you how you can set up GitLab groups and projects to run multiple Agile teams with microservices. Now what I mean by microservices today is I'm going to use it in a very generic sense so that it's basically any code repository where you have multiple of them. So multiple microservices, multiple code repositories coming together to form one or more multiple, one or more applications for your customers. So using microservices in that sense and we're going to focus on how you can set up GitLab groups and projects to support that in a particular typical Agile team. So what you see on the screen right now is an example application or a company and I've called that Trustful Finance and it's a financial services company and it offers three particular products. It gives you a checking and savings bank account, it gives you a credit card and you can take out loans against Trustful Finance. So basically as a customer of Trustful Finance you can access these three products or services in three different ways. You can access it via a website via an iPhone app and via an Android app. And so as you would expect when you log into the website or through one of your phone apps you would be able to access your account or you would be able to do some of these transactions and features and services. So it probably wouldn't surprise you that there's a backend to do some type of logic and then there's another maybe another service. So this is where the microservices comes into play where maybe there's a separate microservice to handle user management type of information, user accounts. So in a real-world application this layer you might have five, six maybe even tens or maybe hundreds of microservices on this layer depending on the size and scale of that particular company you are offering and each of these services themselves might be have a persistence layer, a database layer. But for the purpose of today's demo or just this video just imagine that there's two microservices and then there's three additional user-facing, customer-facing channels into the system. And so right away you can already imagine that each of these boxes represents one code repository in GitLab and that's exactly the model we're going to go with. And so I'm going to take this particular tab here and I'm going to slide it in actually so that you can actually see this diagram as we go through the demo here. So what we're going to do today is go through three particular scenarios of how you can set up your agile teams. And so I'm going to click over here to this demo and I'm going to share this demo in the link in the YouTube video description. But what I've set up is a group called Trustful Finance demo and I've set up three subgroups representing three different scenarios. So I'll go through each in turn. And so the first one I'm going to go through is what I call buy system, set up your team's buy system. So this is maybe a more traditional route of how you can divide up the work in your particular organization. And so what you have here so I'm going to sort by name so it's a little bit easier to see is that suppose you have one particular team to handle your website, another team to handle your iPhone app, your Android app, another team dedicated to your finance logic and user accounts. So in this sort of scenario, it's not product driven or even really feature driven. It's component driven system driven. So you might have a finance person or a business manager saying I need to have this I need this feature. And I'm going to ask this team to and this team to you know, set up the logic, set up the persistence and so on and so forth. So it's not a really product driven organization, maybe an operations driven organization, but the engineering teams, the development teams are classified within each particular piece. And so how we've set it up is that we've gotten to get lab and within this group, we've created a project for each of these subsystems. And this project, the website project, the service user accounts project and so forth, each system would have both issues and merge requests. What's important here is that each of these systems represents a code repository or is a code repository, but it also has issues capability. So what you would do is that for example, if you were the team responsible for the finance logic piece, you would go into here and then you would create merge requests that would update your code repository. And you might even have issues to manage that work. And you could even do that in an agile way. But then you can have sprints and milestones or what we call milestones in your lab, which represents sprints. And you could do that and that would be fine. So that's sort of a traditional old school way of breaking down the work and organizing your teams. And I would even venture to say that's not very, it's not a very product driven approach. It's not a very, you know, a best practice. A better way to do things is to divvy up your system by product area. So this is a best practice. This is how you would divide up your teams and your repositories in a way so that it's actually driving your business value. So we're going to go on the ground up and explain how this works. And what's interesting is I've separated the byproduct subgroup here into two additional subgroups. So imagine these three hybrid byproduct and by system are three, you know, different scenarios. I'm just grouping it here for the purpose of the demo, but this is a totally different, you know, GitLab instance or a group or what have you. But there's one subgroup here that I specifically called code. And within that code subgroup, I've created five projects and each project represents one code repository. And the reason I did that is that you can imagine each of these as a as a microservice, right? You know, these would be, you know, services or backend services or microservices, whatever you call them. And these are, you know, your, your front end customer facing application. So you can actually think of these as microservices as well as, you know, your five microservices here in this picture. But what's important is that each of these projects would have their own set of merge requests because each is a code repository or in GitLab can contain at most one code repository. So all your merge requests for the website piece of code would be one code repository. Now, say, for example, your website was required three code repositories, then you would break this project into three projects or maybe your, your mobile app had some shared code or you're using Xamarin or some, you know, some cross platform, you know, technology and you need additional repositories. And so you could do that. You just, so what's, what's key is one repository, one project, you know, which is equivalent to one repository in GitLab, one project per code, per code repo that you need from a Git perspective. And so once you've set that up, that's your basis for merge requests and code commits, then you can actually go off and build your teams separately. So that's why I have a separate grouping called teams. And I've created separate projects. I've created a credit card project, a loans project, a checking and savings project and a user accounts project. And what this represents is that these are, these are entire full stack product teams. So the credit card product team would have maybe one product manager, one designer, maybe, you know, a couple of full stack engineers, or maybe, you know, dedicated backend engineers, dedicated database designers, but these are cross functional teams all serving the credit card product or set of features. And this is actually delivering, driving business value for the credit card business. And this could be a line of business. This could be, you know, contributing to, to your revenue and your costs. And so this could be a cost center in itself in your business. So this is super hyper aligned with your business. And that is the best practice today, where we want to have teams delivering business value and full stack teams. So what's interesting is that the credit card team has all these capable engineers and designers and product managers and business owners, and they would be contributing code potentially to all of these repositories, right? So the credit card team, if there's a new credit card feature that required you to maybe set up a new user account and do some finance logic, and then they wanted to roll out the feature to all channels, the website and both mobile channels, they, they would need to do that one feature and make changes to all five code repositories. And that's okay. And that's encouraged. And five, you could have potentially five merge requests associated with one particular issue in the credit card team. And so these would be four different teams running for parallel sets of sprints. And you can roll them up if you want, but you know, it's a little bit beyond the scope of this video. But in particular, I'll show you how, for example, this particular team, I've created a bunch of issues. So the checking and savings team has a bunch of issues that they want to work on. And they have their own sprints. And so what we call milestones. So we have a list of sprints. So I've just created one. And so this particular sprint starts yesterday, today's Jan 29 for me and started yesterday, it's going to last for two weeks. And I've created that sprint. And I've even created an agile board to represent that. So you can see here, I'm going to drag this out a little bit and make it a little bit easier to see. But you can see an agile board here, where you have your, you know, your typical ready in development code review, QA, UAT, and even release to production and checking for like, say a business owner. And so you have all these issues that are scoped through this particular milestone. So if you click on a particular issue, it's scoped to this particular sprint. And if you click on this edit board, you can see it's all the credit card teams features scope to that particular sprint. So you can see how you would run this particular, let me shrink this again, you would run this particular, the checking savings teams sprints all by itself, it would touch all these repositories. And then the user accounts team would have its own sprints and so on and so forth. So what's critical there is that there's a separation between code repositories and work, right? So code repositories is really important because it's, we believe at GILAB, the best practices everybody can contribute. So you don't want teams necessarily owning quote unquote a particular piece of code. They should be maintainers, but you should be welcoming other contributors. And so in this best practice, every piece of code in your organization should be welcoming contributions from everybody in your organization. And even maybe it's open source and everybody in the world, but there should be maintainers. And so maybe the credit card, maybe there's a number of you know, engineers that are maintainers for this particular piece of logic, and they would do code review for that. But beyond that, this is shared code. And this shouldn't be in this model, at least a necessary team that owns a particular piece. And so this is a very business driven product oriented way to organize your microservices and agile teams. And the last way I wanted to show you is in hybrid approach. And what I mean by hybrid is that you have your code again, it's the same thing with the five different code repositories. But your teams are spread out such as with website and services and mobile. And why this is relevant is this is probably your organization, right? So what I just talked about by product is sort of a best practice what you want to do if you're maybe a brand new startup or maybe a small company. But say you're like this example is you're in a finance space and and so you've probably been around for a while. And most maybe finance offerings, or maybe the older, you know, financial services companies, they didn't have mobile apps in the past. And they just had a website offering. And, you know, the same team would work on the website and the back end services. So maybe they had this code repo, maybe, you know, over time, they broke out their logic and their applications into microservices, which is great. And they broke it out. But their team is not going to change, right? And then they maybe they hired new teams to do just mobile because mobile is a very specific skill set, you know, iOS programming, Android programming, it's a very specific skill set. And so they didn't have, you know, the folks to do it and they hired specific folks, or maybe it's a the hired contractors consult consultants to do that specifically. So this actually might be more realistic in your particular case or in the industry where there's a team that has always managed and created the the website piece and the back end services. And then there's a dedicated team just to create the iPhone app, the Android app, and they don't even do any of the back end logic. They just consume the APIs that this other team is working on. So this particular team would work on one, two, and three piece, these three pieces. And then this particular team would work on, you know, merger quest in these two pieces. And maybe again, it's a quote unquote full stack team, full stack, or maybe not full stack, but cross platform, cross mobile platform team, because they're using, you know, a cross platform technology, or maybe they have a dedicated Android engineer and a dedicated iOS engineer, but when the ship features, it has to be imperative. So they belong on the same team. But what's interesting is again, this decoupling, so this team could still check in code for these, you know, separate repositories. So maybe it's a small piece of code, a very small attribute needed to add to an API to one of these services, and they could do so. And so again, it's that model where you're not holding onto the code, and that code is up to, contributions are welcome, but the team dynamic is such that it's mostly they work on the mobile pieces here. So that's the separation, and this probably makes a little bit more sense. So that wraps up the video. If you have any more questions, please please log in and issue inside GitLab and any future requests, and be sure to check out GitLab and they learn more about microservices. Thank you.