 I'm really excited for this next talk. Uptchive is a nonprofit organization that provides students with free online tutoring and support counseling. Uptchive's unique approach to supporting students resonates in so many ways with GitLab. It's all remote, it's community-driven, and it's focused on creating a world where everyone has the tools they need to contribute. Trey and Dave from Uptchive are here to share how they use GitLab. From epics to feature flags, you'll see how Uptchive is utilizing the power of GitLab's modern DevOps platform to drive great outcomes for their students and volunteers, make their team more effective, and grow their community. Enjoy. Welcome to Using GitLab to Empower Low-Income Youth. I'm Dave Sudia. My co-presenter is Trey Stevens. And we're going to be talking about how our nonprofit Uptchive has adopted GitLab this year to really accelerate our ability to deliver our product that provides tutoring to low-income high-schoolers. Yeah, so first, we're going to dig in a bit. So what Uptchive is and who we are. And as Dave said, Uptchive is a nonprofit. And we offer free 24-7 one-on-one live tutoring for low-income high school students in the US. We currently offer tutoring in various subjects in math and science, like algebra, calculus, physics, biology, et cetera. And we also offer college counseling help as well. Uptchive can be found both on the web in mobile lab and open source. So anybody is free to come out and help. But most importantly at Uptchive, and this is really at the core of who we are, is that we want to close the opportunity gap. We believe that everybody should have an equal opportunity to education. And it shouldn't matter your color, where your background is, or the neighborhood that you're from. Our vision is to democratize access to academic support so that all students have an equal opportunity to finish high school, attend college, and achieve upward mobility. And I think it's really important to highlight that we're not a library. We're building an application here. And we're inviting the community to build that with us. Yeah, and that's one of the reasons that GitLab has been so powerful for us, is that if we're just an open source project, I think we could be more places more easily and just have our issues on our repo. But being really an open source organization where we have lots of repositories, where we act with lots of stakeholders is one of the reasons that we need so many of the features from GitLab. So let's talk a little bit about how UPCHIEVE works. So students can sign up for the platform as long as they go to an eligible school or have an eligible zip code. And from there, they're able to request for a tutoring session right away. Volunteer tutors sign up for our platform and go through an approval and onboarding process. In our approval process, a volunteer tutor will go through a background and a reference check. Wow, and the onboarding process of a volunteer tutor will take the necessary training to learn how to use the platform and how to have sessions with students. They will select hours in a given day in which they're available to actually help students. And they also complete a quiz to get certified in the subject. So once that approval and onboarding process is complete, the volunteer tutor is ready to help students. And once a student requests helping a particular subject, we send out a bunch of text notifications to all volunteer tutors who are certified in that subject and are available at that moment. We eventually connect the student and volunteer to a virtual classroom. And there they can collaborate on the whiteboard and chat so that the students can receive the help that they need. And now that we talked a bit about UPCHIEVE and how it works, we're gonna talk a little bit about who we are. And I'll hand it over to Dave to introduce himself. Yeah, so yeah, I'm Dave and I'm the CTO. I've been here since the beginning of January of this year. I'm realizing I may now no longer be recognizable from my headshot. But yeah, my journey to UPCHIEVE is I have ADD and I have bipolar disorder. And I did pretty poorly in school and I ended up leaving school early. California has a test you can take to get out after your sophomore year. So my diploma is from the state of California, not from a school. And I kind of bummed around doing random stuff for a while. And when I finally decided to go back to college, I decided to be a special education teacher and kind of give back to my experience. So I was a special ed teacher for seven years before I ended up pivoting into tech. And coming here has been a great opportunity to really marry those like the talent and passion I feel like I have for technology, but with my original sort of purpose of helping uplift people who are facing any kind of adversity. And so yeah, that's how I ended up here. Yeah, and my name is Trey Stevens and I'm a software engineer at UPCHIEVE. I joined UPCHIEVE in January, 2020. And before UPCHIEVE, I was just a college dropout working overnight stocking shelves at Home Depot, trying to be a music producer, kind of throwing parties all over the place and just trying to figure things out. And I remember deciding that I wanted to do better for myself. So I picked up some programming books, started to learn how to code. And a couple of years later, I saw a software engineering position posted from UPCHIEVE and I was just super connected to UPCHIEVE for multiple reasons too. One being that we're actually helping kids. I know a lot of people that went down different paths, like nobody cared about them, teachers didn't care, the school didn't care and granted some of them didn't care about school either at that point in life. But sometimes you need a cheerleader to be in your corner to help you do something. And I think UPCHIEVE would have been the cheerleader for a lot of those people. And I also like to just help people learn stuff. I used to help organize a meetup where we taught people how to code. And it was super rewarding to be a mentor and help people grow and move on to get jobs. So that's enough about who we are. We'll talk about some of the challenges that we had as an organization and why we made the pivot to using GitLab. So a big challenge for us is that we had way too many tools. Everything that you see on the list here was in separate places and it started to cause a lot of friction. We had a lot of uncertainty on where to find something, where should we make updates? And if we make updates, where else do these updates need to be reflected? So for example, our product management and issue management were split across two platforms, GitHub and Monday. Sometimes even Slack, but we're just gonna ignore Slack for now. GitHub and Monday, Monday was used by staff members, but GitHub was used for our open source community and we tracked our product progress and direction there as well. Staff would pick up tickets on Monday, spec it out and not have these changes or internal discussions reflected on GitHub. And over time, this started to create a long list of GitHub issues that were either no longer part of product direction, no longer needed to be fixed or completely had different requirements. But these issues would then get picked up by our community members and to cause friction because now we have members working on stuff that is no longer valid. So we needed a better way to marry the product management and issue management. We had two separate CI tools running, CircleCI and GitHub Actions. We also had our documentation existing in multiple places and became hard for somebody to get the answers they needed independently. And finally, we simply did not have enough tools because we didn't have tools like security scanning and feature flags. Yeah, and we had tons of stakeholders and perspectives. We have staff and even within staff, we have the engineering staff, we have our product manager, we have design, we have the programs and marketing people and they all needed to have some kind of insight and ability interact with the system we were using for product management and for development. And we have our open source tech contributors who come in and help us work on the applications. And we had volunteers who were coming in on the programs and business sides and we needed to be able to easily and quickly onboard them and get them places. And we're gonna kind of talk through the, now how we ended up solving a lot of those challenges by moving to GitLab. And the first piece of that is around product management and issues. And I think this is probably the biggest effect and change that we've had because I don't know of another product management tool that is as comprehensive and can be public, right? And so that's a big thing for us because we are a transparent organization. We're an open source organization and a lot of tools in this space, you can make your boards, whatever, but you've got to log in to see anything. And so to have something that can handle ethics at an organization level because we have lots of, we have a front end and a backend and a mobile app and infrastructure as code and any given Epic might have issues across a number of repositories. And we also sort of use the group and repository structure in GitLab pretty flexibly in having like a staff requests repo that pretty much only exists to have issues in it. And that is the place where like our internal staff can go and say, I need a database change or, hey, can you update this page for me? The sort of smaller things. And they don't have to interact with like the full complexity of the rest of GitLab but it's there and they can access it or public stakeholders can access it. And it's really smooth that way. I think the only major complaint I've had in the last seven months was pretty commonly I'd be like, man, the only thing I hate is that I can't put my epics in order unless I like commit to a dates on a roadmap and I don't want to do that. And then 14.0 dropped and now we have Epic boards and I can put them in order and I'm very happy about that. But yeah, so being able to handle things at that organizational level because we're an organization and not just a project has been really impactful. Yeah, and a great thing about GitLab is that we're actually able to work with multiple agile workflows. So our staff uses milestones as sprints but our community contributors do not operate in sprints. They operate in a combine move it across the board style and GitLab allows us to support both without really doing much extra work. Yeah, and that's true internally as well. Our designer has also just, we split her time with the marketing team and she works in a much sort of simpler process than us in terms of getting component designs and designs up and stuff. So for phases on our board than she does and as you can see here, we split into our community development board or design board, our staff development board and what's really brilliant about all this is just how flexible it is and that it's a canonical list of issues. We don't have to have separate boards or separate projects to have boards but it's completely separate projects to have like Kanban and Scrum based sort of views and workflows. It all comes back from the central data set that's just labeled and then we can work off the labels so that every team can view and work with those issues as is appropriate to them. Yeah, and as we talked about earlier, our documentation was in multiple places but now we're able to have documentation that not only sits at the project level but at the org level as well and the new what you see is what you get editor introduced in 14.0 is amazing for the non-tech members of our team to like go in there and actually make edits to the Wiki documents when needed. Yeah, I can work in Markdown but Shelby the philanthropy coordinator does not have to, right? It's really nice. Yeah, another place that we've really been accelerated is in CI and the main thing for me of GitLab CI is the flexibility. So coming on one of the first things I did was in January as I containerized our app we were moving to a new deployment method and I'm looking at the kind of the state of our CI then and going, okay, we've got two different service providers. Oh, that's because we're on the free tier for both of them and we need to really tightly manage those resources and we're using this for that work and this one for that work and we're in GitLab's non-profit open source program so we have the benefits of their top tier for free which is just an incredible thing for GitLab an incredible program for them to have because it has unlocked so much for us to come over and just be able to essentially use the auto DevOps pipeline to just get a CI pipeline going without a whole lot of effort. We did a little bit of customization around like our test job and we's Mongo and not Postgres so we kind of swapped that out in the test job and otherwise it just worked and we were able to run everything on shared runners for a long time. My total tech budget for the year is smaller than most SaaS vendors just cost for a year so anything that allows me to at least even buy time to find funding for things is great. So being able to run on those shared runners we were able to just basically move right over and be more productive than we were but over time we've been able to customize our job so we ended up splitting the test job out in front and back end we ended up customizing the container build step for to fit our purposes a little better but we still use a lot of the auto DevOps pipeline jobs like security scanning and stuff. We also found over time that there were jobs that we had that on the shared runners were taking way too long or they were using more memory than the shared runners offered and I'm not complaining about that because again free but using those shared runners gave us time for me to find budget to stand up a couple of like digital ocean servers to act as runners of our own pretty cheaply and now we can use the tagging system to say all right the container build that can take 10s of minutes on the shared runners but takes six minutes on our runner that one's always gonna run on ours. The back end tests are always gonna run on ours because they're a little memory heavy but the front end tests and the link job those can still run on the shared ones and so we can really maximize our resources in a way that I haven't been able to do on any other platforms before and then similarly like we have a mobile app we have to do iOS builds in CI and I was DevOps engineer for several years and that's very expensive to do most other places and here I was able to pick up a couple of used Mac minis and make my own little iOS build farm because the GitLab runner can just kind of run everywhere that you need it to run which is really fantastic. So there's a couple of the pieces operationally that what we've discussed so far are things that we consolidated on to GitLab but there are things that are features here that we just didn't have before that we would have had to go find a new vendor I would have had to contact them and say what's your nonprofit policy can you offer me any discounts? You know and if not let me go talk to my executive director and find budget and by being here in this sort of centralized DevOps platform they're here and we could just start using them without having to go find them. Yeah and one of them is feature flags. Feature flags have changed the way we think about pushing features to production at upchief. We've gone from creating large branches of feature work to pushing out small batches of feature work to production. So this has helped us reduce the mental load of working around large features and reduce a ton of wait time for dependency. So for instance, we can push completed front end work to production without having the backend fully implemented yet, which is great. Another thing to note is that managing feature flags is equally as important as using them. And we manage feature flags by using labels on tickets with which feature flags we currently have on and which were ready to be removed. This makes it very easy to see the status of your feature flags on a board. And this can be taken much further by creating more specific flags depending on the types of feature flags you're using mainly creating more specific labels around there to identify those type of feature flags. But currently at upchief, we mainly use feature flags to hide incomplete or time sensitive features from users, but we'd love to use it for much more. Yeah, and there's an issue right now where we have a spa, we have a single page app written in view and the Unleash client, which is the feature flag that GitLab uses is insecure around hiding like user IDs and stuff. If you are talking directly through the browser client build or package. So, you know, for a while Unleash, they have a proxy that you can use, but they're kind of hiding it, not hiding it, but it was behind their enterprise offering. And then they open sourced it a while ago and I'm going, okay, I'd love to use this now because I want to be able to add more capability, but it's not part of the GitLab offering at the moment. And so I kind of went, and this is what I love about working with other transparent organizations like GitLab, is I was able to go through the issues for GitLab and actually find that there's a conversation around adding the proxy for Unleash into GitLab's offering so that we can use the browser client with more security. And I, you know, for me as a relatively small fry, being able to, you know, find that, not just be wondering if one day this is gonna happen and, you know, I comment and I can even see the status of that issue, which is right now, it's waiting for demand. And so I was able to post a comment and say, hey, I demand this and show that, you know, it brings me deeper in to the ecosystem here knowing that I can see what the roadmap is and where things are going. Yeah, there are a couple of other things that we've gained, the security scanning capabilities that are built into the AutoDevOps pipeline, is something that, you know, I would have had to go and find a vendor for, instead they're there, they just get dropped into the dashboard. I was actually able to leverage this into finding, you know, someone from the broader tech community who's a security analyst, who, you know, I look at those reports and I'm kind of like, there's a lot of noise here and I don't know what's actually important, but because they exist without me having to have done much more work, I was able to go find someone who was willing to come in and look through our issues and the reports and say, yeah, here are the things you should really care about, here's what you should be working on and leverage the community in that way because everything is public and open and we can share it. Another thing on this topic that I think is really cool is private issues. We are, you know, one of the parts of being in this nonprofit open source program that GitLab has is all your repos have to be public. And that's great, that's why we're here. But if you have security vulnerability, especially for an application like this that's live and running and has, you know, PII in it, I don't just want to put that out on a public board. And so being able to have sort of, I don't remember if private's the right word for it, but like ethics and issues that only, you know, organization members can see was something that I didn't even, you know, think would exist and has really enabled us to engage with the security community much more effectively to try to secure our app. And the last one is just container package registry. Again, lots of vendors for that, but I'd have to go find them. It's built in, CI integrates with it really easily. It just goes right up and, you know, was made our, made our transition to containers and into deploying the containers instead of binaries just so much nicer. Yeah. So last thing is our community. And go ahead, Joy. Finally, our community. GitLab has been an excellent place for our community contributors. We've gone, we've grown from two regular contributors to seven within six months. And since we started using GitLab, it has really become an all in one solution for us and has reduced a ton of friction with our contributors on where to find things, see what the staff is working on and gather requirements from other staff members in our team, if they needed to. GitLab has the Slack integration that also has helped us a bunch. We were able to stay up to date with what our contributors are working on. And for our weekly tech team meetings that we have with the community, we've adopted this agenda model that GitLab uses for the remote meetings. And lastly, we love all contributors, whether you are a beginner or expert, or if you like to just work on documentation or contribute to feature work, we welcome all. So please feel free to go to the link and join us. And thank you for watching.