 Are you eager to get started with DevOps for your organization or agency, but you wish that someone could tell you some practical advice about the dos, the don'ts before you even get started? Raven Menwell, with the National Museum of African American History and Culture, part of the Smithsonian, will talk to us today about DevOps 101, getting to minimal viable DevOps-ness. Hello, my name is Raven Menwell, and I am from the National Museum of African American History and Culture, and welcome to my talk on getting to minimal viable DevOps-ness here at GitLab's Commit Conference. And so here is our agenda. We're going to talk a little bit about myself, where I'm from, some questions to ponder and beginning this journey and getting started. Lessons learned, some DevOps patterns and minimal viable DevOps-ness, which is the name of my talk. And when I was thinking about getting started and getting to an end state for DevOps, minimum viable product is what you would call if you are doing an application. So you go from the requirements, and then you get to that minimum product where you have reached, where a stakeholder can say yes or no, you have achieved it. And that's what I was thinking of when I was considering, when you start your journey, how do you know that you've gotten to the point where you are at some place where you can measure where you've been? And so that is what minimal viable DevOps-ness is. And at the end of this particular journey that I'm speaking with you, you will understand what that means. So a little bit about myself and where I work. The Smithsonian Institution was established with funds from James Smithson, a British scientist, who left his estate to the United States to found at Washington under the name of the Smithsonian Institution and establishment for the increase in diffusion of knowledge, the U.S. Senate passed the Act Organizing the Smithsonian, and it was signed into law by President Polk in August 1846. The Smithsonian is made up of 19 museums, 21 libraries and the National Zoo and a number of national education and research centers, one being the Observatory, Outropical Research Center and the Education Center. So that is us. And if you've not been here to the Smithsonian to see us other than the castle, I would suggest that you do come and visit. And while you were there, you can come to where I work, the National Museum of African American History and Culture, which is the only National Museum devoted exclusively to the documentation of African American history, life history and culture. We were opened to our doors on September 24th, 2016 and was established by the Act of Congress in 2003. It took 13 years for that museum to open, and now we have more than 40,000 artifacts and over 100,000 members. And while you're there visiting the rest of the Smithsonian, I would totally, your visit there would not be complete unless you've been to our museum and I just say that because, yes, I work at the best museum ever. Sorry to my peers that are at the other museums and galleries, but this is a really awesome place for you to visit to get a taste of Black American history. And here is me sworn in. On January, 2017, I am the Senior Application Developer and Dev Ops Engineer for the museum. I work in the Digital Media Group. I am the principal programmer responsible for the planning, design and implementation of some of the web-based interactive developed by the museum. I'm also the DevOps team lead. I define the standards and some of the, well, most of the workflows and recommend the appropriate tools that are going to be used by our development teams. I'm also there to help our leadership with the adoption or the adoption of any of our digital products. And I also administer the cloud-based resources that we use in our workflow. I also ensure that our units, our practices, security practices, specifically are according to what we have set up and what our Enterprise IT have set up. So when you're getting started, the first thing you need to know is your pain points. And if you don't know your pain points, then you don't know where to fix them. And DevOps, you have to define what it means to you. It's designed to facilitate and ease that pain of getting started. But you have to understand, does it add value? What does it do for you? What can you do with it? With it, because it's not a panacea for all. It can help with performance, but you have to think about certain things about DevOps and when you're implementing it in your workspace. Does it is there somebody, some group that will that's not working as efficiently as possible? Are there some dependencies, whether it be your workflows, your processes, your groups that are being impacted and the performance is not as high as you want them to be? Are there tools maybe out there in the cosmos that you feel that will facilitate your way of getting done? These questions, if you ponder them, they'll help you with your journey into the world and realm of DevOps. Our unit at the beginning, in the beginning, before we got started, we were on a very strong footing. We had a very strong, we have a very strong, very focused, small, well-practiced teams. We are very cohesive in what we do and we are very well practiced in our agile workflow. We have a prioritized list of features and bugs in our backlog. We use a source code version control system. We have transparency into our issue tracker. We do those scrum, sprints, retroactive, all of those agile things. We're very good at that. And that is what gave us a very strong beginning in our particular journey. So how did we get started? Like, what made us begin? How did we know where to begin? First, we decided to look at things that could address our performance. So that's what we decided we would do, to address performance and see what things we could fix to get us to a place that we could judge and have metrics to see whether they're not, they were fixed. Because you can't judge if you fix something, if you don't know that it's broken and whether or not, when you get there, it's not broken anymore. So we decided to look at our application workflow because we did have several challenges there, and one was dependencies. We were dependent on several teams to get our environments up and running. And that made it so that when we had our onboarding process, it took us two to three weeks to get started from this the time when they were approved to the time that we were actually able to do integration testing. Up until that point, we lived in a very unsustainable environment where we, as developers, were developing on our local dev environment, but we could push them to the repo, but we couldn't get them past the repo because we didn't have a development environment to actually push them to. So our issue was our onboarding. The problem was our dependency, and the results of those dependencies meant that it took us two to three weeks before we could get started. So now that we knew what our issues were, we could actually address it. So documentation and incremental implementation of some fixes were how we started our journey very, very slowly. We took advantage of our cloud-based resources, which we weren't really leveraging before. And because we were able to do that, we were able to just wipe away the dependency, especially when we got started. But of course, like everything, you have to document. If you don't document, then you do a disservice for yourself because you have no archival information to work off of, and you also don't have a way to look back to see what things need to be tweaked. So documentation and incremental implementation are very key in getting in your journey. One thing that, so you're always learning lessons, and one of the lessons learned was that commitment and commitment to change is scary. It's not something that everybody, even though everybody was on board, all the people that were needed said, yes, we wanted to do this, but the focus was on the temporary wins, the easy wins, and even I fell into that trap, that snare. I promised my management that, yes, we could go ahead and meet these deliverables, meet these timelines, have these tools, and they would really enhance our performance, which they did, the automation that we actually implemented. But in the end, we had to stop. We had to pause because I found out that the way we worked, even as a cohesive team, it was too brittle, it was too fragile, because as I added more tools, added more things to our processes, it made the team slower, and then it started impacting performance in a way that did not anticipate it to impact our team. And that was because I put too much emphasis on the tools and workflow than I did on the people and the process. So where we are right now, current state is that we've stopped. We've actually hit pause and we decided that first what we need to do is look at our whole processes and find a way to fix the processes to get us so that we're not as brittle in the way we work. And that is where our end state is. We're headed towards our end state. And one thing that I'm doing is I'm looking at design patterns. One of the design patterns that I'm looking at and what a design pattern is is I've co-opted this phrase from Brad Frost, who has published the atomic design. It's interactive interface design. And what it's meant to do as it states here in the slides, it's a methodology to create interface design systems in a more deliberate and hierarchical manner. And the whole point of it is to look at a business problem and to see how you can solve that business problem by creating user interfaces that are modular and that can be adapted to the different devices. So it's more about how to adapt and how to be flexible in the business environment and your needs and for our My Museum for the African American History and Culture. Since we are not a product development team, we don't develop products for our, for any customer base. We do develop interactives and we do have digital products to meet our visitors. And so what we need is a pattern that will help us to be adaptable and flexible to the needs of our visitors, but also to the needs of the stakeholders who are our curators and our educators. They want to get across a story. And to get the story across, we need to build a digital product. But how do we get that product out there using dev ops, using the agile methodology in a way that's consistent across, no matter what the digital product is, since our digital products, except for with the exception of our main website, which was one of our starting points. That's where we started with our critical app and one of the interactive apps. And we tried to find something that would meet the needs for both of those applications. So the process to keep us from being brittle is to come up with a design pattern. So I've developed a design pattern that is adaptable, that is flexible, that will get our teams up and running using industry best practices, using the buzzwords of tools and technologies, but in a way that's mindful to our needs. And that's what you need to think about. You need to be able to take the dev ops methodology, the pseudo-religion, and make it so that it actually works for your organization, and not that your organization is trying to be adaptable and flexible to some rigid system. And so what we've come up with, our dev ops design patterns, and notice I don't use dev sec ops, because the use dev sec ops indicates that security needs to be pulled out and highlighted as if it's not part of already part of the process. And that is not the case. Security is embedded in everything. So in the dev ops design pattern that we are looking at, that we are documenting for our organization has two main levels, our product delivery and our product development. Those are the key foundations for the pattern. Above the pattern sits these major components, and these components are embedded and included in everything. You'll see that in this image, security, governance and compliance, stakeholder communication, accessibility design, tooling and automation, testing in metrics, administration and operations, and service delivery are all equally, they're all equal and they're all going to be embedded. There are all things that you have to consider when you're looking at this pattern. So why the pattern? What is this pattern supposed to do? What the pattern is supposed to do, it is supposed to give us a lens to look at our digital products. When we have an onboarding of a digital product, what we're going to do is look at each of these segments and determine how much or how little of this segment plays a role, which security is going to always be a major segment because it is. Regardless of whether it sits in our internal host providers, what we're internally in our, I'm losing the word right now, in our data centers or if it sits with a cloud provider because the cloud provider does expect that their tenants are going to have some level of responsibility for security. So you'll never hear me myself say DevSecOps because I think that security along with governance, along with tooling are just, they're all as important and they all need to be embedded. So the design pattern has these knowledge domains and then it has these major components that the knowledge domains actually interlock with. So the minimal viable DevOpness for NAMOC, and I shouldn't say that and I just said that. I didn't need to say that, which is the end goal is that in our onboarding process, we will evaluate each project via this lens of DevOp's design pattern so that we can structure an appropriate DevOp strategy and an efficient way of working to achieve these incremental and continuous efficiencies. And by doing this and by including all of those particular knowledge domains in the pattern, we should be able to document because we will come up with a plan and we will document the plan. And if we follow that plan, we should be able to meet the minimal viable DevOpness for every digital project in a very consistent but continuous incremental manner. And that is all I've got for you for today. Thank you very much for joining me at our Git Lab Commit. And if you have any questions, feel free to put them in the chat and if I am online and I'm here, I will answer them for you. Thank you.