 I'm going to walk you through the GitLab Jira integration. We're starting off inside of GitLab. We have a mock organization created. This is healthcare provider incorporated. What we've done is we have several subgroups that have been set up. We can look at these as lines of business, value streams, and then underneath these we have some product groups. This may not be exactly what you do or how you've seen other GitLab instances, but this is also our organization structure using GitLab. So if we look at surgical technologies or store the therapies group, these are two subgroups that fall underneath healthcare provider incorporated. Normally this would be our parent, top level ancestor, which it is in this case, but these are underneath a couple of our demo groups that we have set up for tech marketing. It's just good to note that these subgroups and these groups here as we'll use this as namespaces in the integration with Jira. Going over to Jira, the first thing that we need to do is go down to settings, go down to apps, and then we need to search and find the GitLab app. We'll go to the marketplace, type in GitLab, and with the results it should be the first one that is populated. From there we'll get the app, get it now, should just take a couple seconds, and then we see it successfully added, and then we'll go to manage app. Once we get to manage app, it'll give us a couple of choices here. We'll click get started, and it's going to be a very simple app right now. All we need to do is add a namespace and then link that namespace to Jira. This is not overly complex. This is in version 1.0, released in September of 2019. Hopefully we have a couple more versions in the future around this app for the GitLab Jira integration. Now we need to grab that namespace, and I briefly talked about subgroups because that's important for our namespace. What we're going to do is come up here and we can just copy and paste the URL. We'll add that in namespace, but we need to make sure that we're going to remove the HTTPS GitLab.com. We'll remove that, and we'll be able to now add tech marketing, demo slash GitLab, agile demo, healthcare provider. That's the path that I have for healthcare provider. More times than none, it would just be perhaps just the top level group, and you can add that. I'm going to add this stream here. What this is going to do, it's going to now allow us to have any group or subgroup within healthcare provider and corporate can have that Jira GitLab integration. If we wanted to be more specific to a specific subgroup, let's say restorative therapies group, they have the surgical technologies group. I have a few of these projects or these teams here that are using GitLab for agile project management, and they have a few using for Jira. What we could also do is be very specific in adding that namespace. If I take that off, then now we see we have a longer path here, and it's specific to surgical technologies. If I added that, what that means is that only these projects underneath surgical technologies, those are the only ones that will have that Jira GitLab integration set up. In the case that you saw, I added the namespace for healthcare provider at this parent group level, every single group, every single project now has that capability. If I go back into engineering, let's say this is the team that wants to set up that Jira integration, and I just add a simple file to this directory, just make it a YAML file. I already have a couple in there, so I'll give it two I's, so it doesn't give me a warning until I already have that file. Let's just give it an auto devops template, something that comes along with GitLab, and then down here in the commit message, this is how we are going to link to our issue or user story inside of Jira. Let's go back to our project page. I have healthcare provider incorporated here, we're going to dive into that. Let's go ahead and give this a name, we'll say GitLab integration with Jira, we'll make it a story, you can add whatever information there. And then now I have this GitLab integration with Jira, it's on my backlog showing on my Kanban board, we'll leave it here. The thing we need to take over though is this HPI-17, that's what we're going to lead with here in the commit message. So I'll leave it with HPI-17, I can add a comment that will help with the transition. So what this is going to let us do is it's going to take this transition here in progress and then once it's committed, it's going to move this from backlog to in progress. So these are just the three default transitions that I have set up here, maybe your workflow is different, just make sure that it is exactly how you have it built it out here. So I have the pounds under the hashtag in progress and that's what I set up inside of my commit message. I'm going to take that same issue ID from Jira, I'm going to add that to my target branch and let's just say it's GitLab, that's my target branch and then we can see here that I'm going to start a new merge request with these changes, merge request known as a pull request inside of Jira and we'll be able to see that within the issue, we'll be able to see our commit, our target branch and our merge request. If I commit these changes and now it opens up the merge request, so the merge request is not yet submitted, but what we can take a look at is if I go over here, refresh this issue, we should now see that it is moved to in progress. I see that there's a branch in a commit connected to this issue, if I click on branch, it gives me that branch, the repository that it's in or the team's repository, so back in engineering, I can go into that repository or I can look at the specific branch, it's going to take me back to the commits inside of GitLab. The same goes for the branch, same goes for the commit. If I want to go inside that commit, it's going to take me into that commit. So the one before this was it took me into that branch that I created. If I go into that merge request now and I'm just going to say, ready with Jira, change that title, whip, just assign it to myself, and then merge opens, I can delete that source branch and I can also squash the commits when the merge request is accepted. What that's going to do is it's going to, and this is your choice right now inside that Jira issue, it's going to remove the branch and the commits from that issue once this merge request is merged into master. So let's submit that and it's now going to have that merge request completed. We'll see that this is an issue in Jira. So this as well would open up inside of Jira, taking me directly to that issue where user story. Once this merge request is completed and merged to master, it will close that issue inside of Jira. We see that the pipeline has kicked off using GitLab CI CD. So we have a YAML file that has the build stages all structured in here. It's going to run through those and once this is passed, then I'll be able to resolve that work in progress status based on if I like the changes, if the changes are meeting my expectations, meeting my definition of done, I'll merge that into master and then it will close that issue in Jira. If we go back here, refresh it, we'll see the branch commit there and then we'll now see that it has a pull request, aka merge request in GitLab tied to it. It shows as open once that merge request is merged into master and complete. That would show as closed. And we'll be able to see the branch commit as well. We'll go away if I chose to squash and have that branch deleted. And it's also giving me some activity here as well. Same thing with pull request. If I want to go in to see that exact merge request inside of GitLab, here it is. We were just inside there. Now what I want to do is because we're not going to wait for the pipeline on this one is let's go into merge request and I had a previous merge request that ran and it passed and we see that the pipeline passed. If I want to take a look at the application review it to make sure the changes are good. I can resolve this work in progress status. That's now going to give me the ability to merge this merge request into master. It's going to delete that source branch. Let's take a look at the board real quick and we'll see here's HPI 16. This is the merge request that previously ran that we're looking at right now. It's in progress and if I do this quick enough once I merge that we should see that this moves over. Maybe I need to refresh it. Refresh it and now we see that the GitLab integration with JIRA demo 2 is now moved over. The one that we just created is still in progress. What it's doing, it's kicking off this pipeline inside of GitLab. It's running that final pipeline into master and if I go over the board I click into this right here. You'll see that this is actually showing two commits still. It's not showing that branch anymore because that source branch was deleted. It's showing that the pull request is open at the moment but as soon as that pipeline is completed and the change is pushed into master then this will show as closed. This has just been a quick overview. There's not a lot to setting up the GitLab JIRA integration using the app in the marketplace. Previously we had a GitLab JIRA integration that took a couple more steps. Those links to those videos are in the description below but this is now a more simple approach. If you have any questions or comments please feel free to add them in the comment section below. Thank you for joining today.