 Thank you for having me. My name is Justin Sensenay. I work at the National Institute of Standards and Technology. We've been using GitLab for about two years and I wanted to give you a perspective on what the project management has looked like for us. We've started using GitLab Core and we're going to start to pilot the GitLab Enterprise Edition. So what I'd like you to kind of walk away with from this is what in our experience we've been able to do with GitLab Core. What we weren't able to easily do but we kind of found ways to sneak those in and then what you really really can't do for project management with GitLab Core. So what I'm going to show you is how we use issues, issue lists, Kanban boards, and milestones. We'll show you some workarounds we found that sort of work for epics, burn down charts, and dependent issues and then we'll show you examples where we'd really like to for example assign issues to multiple users and weights on issues. So first let me tell you a little bit about what the National Institute of Standards and Technology is. It's a center that's part of the US Department of Commerce and it's non-regulatory. What I mean by that is we're not dictating you know this is what you need to make your peanut butter out of. These are the way you need to write your software application. We're simply defining what are the standards of secure applications and we can help you certify to those standards. So for example IT security publication 800-53 that you are probably very familiar with that specifies the standard NIST peanut butter. No 800-53 that specifies the good security controls for a typical software application that's storing data in the cloud but NIST also makes standard peanut butter. What that is is that is peanut butter that is sent to various peanut butter manufacturers around the US so that they can actually calibrate their instruments. They can trust number of calories for example that they think their peanut butter has actually contains that number of calories. That's the kind of thing that NIST does. What NIST also has is it actually had the first 1950s stored program computer. So the first computer where you can actually put stored commands into it and then run those commands was established at NIST. They've got about we've got about 5600 employees at our Gaithersburg location about a thousand employees at our Boulder location and this is how we're using GitLab. We started it in 2017 with about 50 users. We've now grown up to 1255 within NIST and we've got about 2681 projects within NIST. What these are often are these are a combination of new software projects that you know summer students or other people are coming in trying to write some code or long-term projects that have a lot of history like time.nist.gov which stands which specifies what the exact time is and actually gets broadcast to pretty much everyone's Android and Apple phone. Those are the kinds of projects that exist in GitLab and on many cases they were originally subversion projects. So we actually find project management to be a good way to transition those people who are more comfortable with subversion as a code repository system to come to Git and specifically GitLab. So from a subversion developer's perspective we often say you know I understand that you really liked the linear commit history that you got with subversion and I'm sorry that that doesn't really exist in Git in a good way. But what you can do is you can create an issue and you can tie commits to a particular issue. And so for a lot of people that becomes the way that they go from subversion to Git is we tell them you know this is kind of a good way to start to learn about Git branching and we can you can tie your individual commits that you have to an issue within GitLab. So when they do that and when they get used to doing that we start to see things like this inside of our GitLab issues. Every time that they mention a commit that they mention an issue in a particular commit it shows up within that GitLab issue which I think works really well. And then once we start to get them to the advanced level we can say hey you're actually you can start to create branches and as those branches are created they tie them to issues as well. So as we've introduced GitLab issues to our subversion developers this is the kind of growth we experienced in in GitLab issues specifically. So as people you know in a pretty linear rate we're coming into GitLab and learning about Git they started to actually issue we've actually seen issues have really taken off. So these are some of the things that we really like GitLab issues for. A particular user of our GitLab issues will create a checklist of things that they need to do in order to get a particular piece of code working. As they're working on it they can actually use the GUI to check off those pieces which is pretty nice. And they can also start to provide some kind of documentation around their issue. So if a problem comes up they can come back to it and they have documentation in there. So as this documentation piece has really taken off we've experienced the similar kind of growth. So again with just getting people into GitLab you know that's been a pretty straight line but we've started to experience a lot more people specifically going into the documentation piece of issues. So here's what we really like about issues and what we kind of introduce our new Git users to. The fact that you have documentation time tracking due dates and labels. With documentation we highlight the fact that you can actually encode you know put documents into your GitLab issues and those carry along you know as you're as you're tracking different commits. What's really interesting about that is we also use ServiceNow. So me and Zach are in the IT shop at NIST and we use ServiceNow for a lot of our tickets that we have to deal with. And we found GitLab is actually where we often want to put the documentation for our ServiceNow tickets simply because it's a better way to track some of those. We can also do time tracking on how long we're working on issues and then we can assign due dates to those. And the part that I really think carries over into some more advanced project management features is that you can create these labels at both the group, the subgroup and the project level for your GitLab projects. So when I have a particular project that I'm working on and I want to look in this case I'm in the Div188 group, the Collaboration Services subgroup. And I'm actually able to see all of the different issues that are in this particular subgroup. So I'm able to see these are where it's a sales force hash 49. I'm actually able to see those are Salesforce projects that we're working on. And so what's really interesting about this is when we started the project we really had about four issues per GitLab user. But that's actually been increasing as people have started to adopt this project management approach. Now we're growing to about seven issues per GitLab user. So I'd mentioned that labels are really what are carrying us over into some of these more advanced project management features. And really seeing some of the things we can't do with the GitLab core that we'd like to be able to do with the Enterprise Edition. So with GitLab issues what I can do is I can make an issue a, for example, that's a Salesforce label that I've attached to a particular issue. And that label can exist either at the group, the subgroup or the project level. I highly recommend that if you use GitLab issues right now that you make your labels occur at the top most of your project. Because then what you're going to be able to do is you're going to be able to use that label throughout both the group, the subgroup and the project. So when I do that, if I then click the board button right here. Now I can start to see all of the different labels. And as long as these labels exist at the group level, I can put them into particular columns. Now this Kanban board is basically a combination of all these different columns where each issue has been categorized into one of those columns. So as I have issues that I'm dealing with as I'm fixing them, I can drag them from to do to doing to closed. And I can start to deal with these issues. I can also see, for example, who they have been assigned to within NIST. So in this case, I've tried to tell people, and this is another thing that if you are getting started with this, I highly recommend, on your own server, tell your users to set their display name to something useful. So the word says at JSS-7 at the very end. If someone tries to search for me as at JSS-7, and that were my display name, they would not be able to find me. But if I change it to a human readable name, then they can use Justin, they can use Sensiny, they can use USTIN, they can use any combination of that, and they can start to find me. But with JSS-7, they wouldn't be able to easily find me. So I highly recommend you have your users do that. So in this case, for example, do you see where it says move sw.assurance.nist.gov? I'm able to just drag that from the column where it says doing right there to closed. And what that actually does is that if I were to go into that GitLab issue, as I did that, that actually put a tract in the GitLab issue exactly what happened. It would say label removed by the particular user that was signed in and the time that I did it, which is really nice. So those are Kanban boards, which are the way that we often, and we often get our managers to look at issues at NIST. But there's another way that people often like to look at issues. And these are milestones. This is a way that people can track larger projects. They can basically assign issues to a particular milestone. And then as those issues are completed, the milestone percentage gets towards 100%. So if I look at this slide, I can see these are within our Active Directory team, these are issues that people are completing. And as they're closing the issues, that percentage that you see where it says 85%, 28%, 33%, these are the percentage done of these particular issues. The other way that I can look at these, which I think is really nice is I can see kind of at a top down level where all of these issues are. So if I drill down into this milestone, in this case, I clicked that particular milestones button, I can see where each of the issues are. I can see the ongoing issues and the completed issues. And I can also see them within that issue board as well. So in this case, I was looking at the milestone. In this case, I'm looking at the Kanban board. Now, these are the features that I really like about the core addition. But there are other features that you don't, you specifically do not get with GitLab Core. Those are epics, burn down charts, and issue dependencies. Epics are when you have multiple issues often across multiple teams and you'd like to collect them into a larger project that you're working on. Burn down charts are when you have a list of issues like that milestone that I showed you, and you'd like to see a chart of how they're getting completed and whether, if you set a deadline date, whether or not you're on track. And then issue dependencies are, I have one issue that can't really be worked on until another issue gets completed. So what I'm going to show you is the secret code to how you can do some of these with GitLab Core right now. What we in particular do is we use that group and subgroup capability that I showed you, where we try and make everyone at NIST as much as possible do a really hierarchical view of what their organization looks like. So for example, if there's a particular division that has a lot of teams and then they have a lot of projects within those teams, we tell them create a, at the group level, create your division. At the subgroup level, create your different teams. And then you get to the project level. And that way when you drill up all the way to the group level, you can see all of the issues that are, that that particular division is dealing with. So that's what we really recommend for doing something like EPEX. For burn down charts, what we recommend is we kind of, we use milestones to basically create a manual estimate. We create an issue that is basically the burn down chart. And then as people are going through, we can set a deadline date for that particular issue. And then we can mention both that issue and the issue that the user is actually working on in those different commit messages. And we can tell them, you know, let's say for example, we're releasing version three of a particular software. Just include the version three soft, the version three issue within your commit messages. And then finally, issue dependencies. One way that we've done that is we've put the particular issue in the, when you put the issue that you're working on in the comments section of another issue, you can also add these group level labels called blocked. And then we basically track the blocked issues as the dependencies. So let's look at what we'd like EPEX to look like. In this case, we kind of use Kanban boards to sort of emulate them. We can see we have that blocked level, you know, on the far left side. And then we have doing and completed. And when we, and we can also do something like burn down charts with our milestones that I was talking about before. But what I'd really like to show you is what gitlab.org can do. So this is what a burn down chart should look like. And while we'd like to get to that, we're not at that today. But that is what we think will happen is we'll be sort of piloting the premium edition, which includes some of these features to test them out. And then with dependent issues, I just wanted to show you what you can do. You can actually, in this case, what I did is I'm working in a particular issue in this, in this case, the Division 188 group, the Collaboration Services Subgroup, the Google Analytics Project. I have an issue already, which was issue number one for this project. What I tag it inside of my description, I can see what that particular gitlab issue might be. So before I go further, does anyone have any questions about these three different features that, while we don't have access to today, we've kind of created a sort of proxy for of epics, burn down charts, and issue dependencies? Yes, that's okay. So would the group, subgroup, ideal work if different members of the same team couldn't access the same projects? So if I need to be able to access a project that my team member can't. It's a really good point. In that case, I don't think it would. What I usually recommend is, you know, if someone's a member of a division, that you add them at the division level because then their permissions basically propagate downwards. If I have a project that's a little bit more closed, you know, I only want particular members of a team to access it, then I usually create it as its own, you know, its own group. And then I put that project in there. That's a very good question. Yes. I just want to make sure for the everyone who's participating that the notion of epics and burn downs and issue dependencies are supported, but they're supported in the higher addition, paid addition, enterprise additions. And I just want to make sure that's clear so people don't walk out of here thinking that those functions do not exist. And that's that's why I wanted to show what burn down charts look like on gitlab.org because that is something we definitely see ourselves using. That's a very good point. Yes. Yes, so we we've actually implemented is a single single sign on so that if users are signed into their computer they can get in. But we also support having people enter their username and password. That's fine. But very good question. Yes. From a project management standpoint, are you guys looking at risks or requirements for certain projects? Are you just looking at issues? There are different groups that are looking at risks and requirements. I'm not as familiar with exactly how they're doing that though. But we I do often see so people are creating user stories for example as gitlab issues. So I imagine they're also creating requirements as issues as well. Risks I have actually also seen them creating they're basically using gitlab issues for all of those. Frangiate between you know risk requirements or an issue? We do do that at the label level. So we basically assign a label of what it what it is in particular. What I really like about the way these issues work or I can actually search by so when I put anything into that search term I can search by at label and then any label but I can also search the full text of an issue. If anywhere within an issue a particular piece of text comes out it will show up within this board. So for example I can have people they can search by say vulnerability and even if it's within the text of that issue those vulnerabilities will come up. So that's that's how I do that. Could be sloppy and miss them though no? I mean well so that's why I recommend creating labels at the group level simply because then it's you know sort of there's usually someone at that group level that's seeing all of those. If someone decides to create a label at the project or the subgroup level from the group level perspective it doesn't really show up. I was thinking about it more from the point of view of the issue creator so that the issue creator needs to be able to remember to label their thing correctly which is a problem. Yeah so that's really a good you know the project manager and the issue creator you know need to get together to decide kind of how they'd like to label and that's why I say at the group if you keep the labels at the group level it's um that's pretty easy to do. If you if someone accidentally creates it at a lower level it's actually also easy to promote those labels. So there's a button in GitLab you can push that's promote to group label promote to subgroup label as well. So I wanted to show you this is kind of what it's turned into. We now have all these different groups at NIST and this is kind of how they're collaborating. The size of the bubble is basically how many projects they have in GitLab and the strength of the arrow is basically how many people are collaborating from one project to another within within those labs. So ITL information technology laboratory CTL communications technology laboratory. So this is just again kind of my advice for what you can do. Again like div 188 board that's that Kanban board that exists at the group level. The collaboration services board is at the subgroup level. And then just a reminder this is kind of what our experience has been and sort of why we're moving from GitLab core to testing out some of those paid versions. In particular we've really extensively used issues issue lists Kanban boards and milestones. And we found slight workarounds for epics burned down charts and dependent issues. But we do you know what we're really looking for is assigning issues to multiple users and waiting issues. And that was kind of our that's sort of how we made the decision of once we got there we realized you know really should test out some of the paid features. So I did want to mention this is my email address and as a government employee I can't endorse commercial products. So I'm really here just to tell you you know this is how we used GitLab and we liked GitLab but I'm not instructing you to use GitLab. So with with Git pure Git and these I would say features that GitLab layers on top does these features check in the issues into Git as a some kind of item and then that gets updated somehow or how is it stored on the back end of the repository. It is definitely one of my questions to the GitLab developers. I can at least answer for the documentation part like the wiki of a GitLab project that actually does get stored as its own Git repository which is really interesting to see on the back end. So I don't know if the GitLab people may know a little bit more about that. Yeah the issues are not stored in the Git repository. They're stored in the Redis database and they're sort of meta objects on top of the Git repository right. Okay so the reason I'm asking is that we have a two networks like a internal network and an external network. The internal network we have a GitLab and outside we have the AWS. If we have issues created in GitLab and I pipe them over into the AWS side I don't know if I would see them because they are not like an item or a thing in a repo. More so is if I have a GitLab outside can I pipe those issues from the inside out to the other GitLab. So I have two instances one inside one outside and I'm asking about the synchronization between the two. So we have a couple of options to do that. So with regards to the AWS I'm not sure if that's going to be easy because the issues would have to be exported out into like a flat file of some sort and then imported into the AWS environment but if you're using both GitLab instances on both sides there is the geo functionality that we do have available where the the repository can get mirrored as well as stuff that goes with the project gets mirrored with it. Then there is another set of functionality that if if they're completely disconnected networks let's say it's a some sort of an air gap network where you cannot like you have to sneaker net it in some way. We just did this for an intelligence community customer where we've kind of solved that where it goes from a low side network to a high side network by putting the stuff so it extracts everything out into a flat file-ish format which then gets picked up automatically in the high side and then gets that's reintegrated into GitLab so people see the same data across both networks. Okay is that to answer yeah. The one one follow-up question is with that sneaker net design is it just then exporting it and re-importing it or can I fully automate both sides of that? Yeah so the import and export processes can be automated right but it again it's it's not because of the sneaker net part of it it's a timing question so you kind of have to schedule it accordingly is say okay at 7 a.m. it's going to export everything out and then there's some way that it's going to travel on the sneaker net path or through an S3 bucket or some method that you decide is appropriate for your security posture to get to the other side and then at say 10 a.m. it's going to look for that if it finds it great if it doesn't find it it will rerun the job you know 15 minutes later or every every so often and pick it up because we do have scheduling capability within GitLab to be able to do that sort of stuff. Thank you. Is it a good use case for the GitLab rake command? Yes there is this a good example of the GitLab rake command and the answer is yes specifically we can I mean there are many options like and one of the options is to do the rake command to do the sort of migration if you will of data across instances yes any other questions so Justin with respect to the things that GitLab can't do today have you submitted issues to GitLab to request that functionality? Well again these are these are things GitLab can do they are just things that can be done in the paid version so if I with the enterprise edition I can assign issues to multiple users and I can also put weights on issues and if you go to gitlab.org you can see you actually can do those things but with my internal GitLab core that I've installed I can't do those things and then Epic's burned down charts dependent issues those are things that you know they exist explicitly in on gitlab.org they just don't exist on my installed core edition and we've kind of we found workarounds for those but once we get to the ones at the very bottom that's when we said we really should you know for so basically the way we're doing it is for that there's about 1200 or so users that we have we're leaving them the core edition and then we're saying hey when you want these we also have a paid edition you can go to so that's that's how we're doing that Questions? Like what tool set did you have prior to and what was your incentive to migrate? Our main incentive to migrate was actually the fact that we didn't have a good CICD pipeline integrated with subversion and so we actually went to we tried GitLab in combination with Jenkins but then we found it just made more sense to use GitLab with its own CICD pipeline but that was our that was our main motivation a very good question Any others? Justin, thank you very much Thank you