 When you're in a very large enterprise or a regulated industry, transformation can be hard. In this session, Scott Adams from Rolls-Royce explains how his team, which works on nuclear reactors, was still able to take incremental steps toward their DevOps transformation. Let's see how. Hello. I'm here to talk you through a small but vital step in our DevOps journey. If you can't tell already, I'm here from the UK, Scott Adams, and I'm working for Rolls-Royce on the UK SMR program. So, the UK SMR program is a Rolls-Royce consortium-led program, and we're designing a small modular reactor for electricity generation on proven technology. So, why am I here? So, I'm currently leading the performance methods in the program, which is the thermo-hydraulics aspects of the whole nuclear reactor. And when you kind of break it down into its parts, it's data, it's commercially off the shelf software, it's in-house codes and models, and all aspects of this can utilize modern software techniques. So, we took the plunge and I'm here to talk you through our small step into the realms of DevOps. So, essentially, we're a really small analytical team in performance. We develop, test, deploy, and utilize all of our methods, and it's all to do with providing data not only through design, so we're still in the design phase of this nuclear reactor, but once we're there, we want to justify it as well. So, we want to do a whole bunch of analysis to make sure that it's as safe as possible. And in reality, we've got five nuclear engineers requiring one analytical method with very little software-based experience. So, at a glance, our project and our method utilizes common nuclear codes. So, we've kind of broken all of our models down into aspects. So, on the right there, you'll see steam generators and pressurizers and the RPV. So, we've got a model for each of those bits, and each of the models are wrapped in Python so that we can put what data we need into them. And at runtime, all of those models are kind of stitched together so that we get a whole plant model. So, all of this was kind of originally developed on a really siloed internet isolated ageing network that had the version of Python that it was kind of built on it. So, we used Python 2.4 originally, and we later moved to the ground-breaking 2.6. And because we had kind of little software experience, we went with the requirements capture technique that we know, which kind of pushed us down the waterfall type approach that I'm sure many of you can relate to. So, that ends up with us going from kind of a start to a first release in about eight months. So, because of this approach, we had kind of limited customer engagement. So, we took all of our requirements right at the beginning and then hardly spoke to them for about six months afterwards. And since then, we've kind of been doing periodic reviews and updates of our method. And it's mainly to kind of keep up the design changes. So, there's various teams dotted around that are making quite major changes in some cases to the design, and we need to change our models to be able to capture that. And due to the last few years and the fact that we're kind of still in design, it means that we've actually historically had quite a high turnover in engineers and our relatively small team, which hasn't helped with our optic process either. So, why was it that we kind of really needed to change? And I mean, this list could be 100 times longer, but I kind of went through the fact that we didn't really capture all of our customer requirements because of the waterfall technique, you end up getting a snapshot of your customer requirements right at the beginning. So, we got all of our requirements up front, and then that just didn't change for the rest of time. And to be frank as well, I don't think our development cycle was really up to scratch for the amount of engineers that we had. So, we were trying to kind of push the boundaries. So, this method and approach, it's really novel in the nuclear industry, and it's quite a big task to keep as well. And with five engineers, that's quite a challenge. We had a lot longer development cycles than we wanted. And because we're the same team, I mean, our developers are the same people that use our method. If your development cycle just gets pushed, you just end up placing stress on the same engineers to produce the analysis that you need at the end. We had zero configuration control. So, well, unless you claim Shimadini when we were originally on our Linux platform, but we've migrated over to Standalone and Windows engineering PCs. And since then, we may have had the tools, but we definitely didn't have the mindset to properly configuration control it. Ideas was a big problem. So, nearly all of our development was text-based. So, we had Python, all of our models were based on the old punch cards. So, they were all text-based inputs. So, our developments are all done using NetPad Plus Plus, or even worse, text editors. So, that kind of made peer reviews and technical checking long-winded, because you didn't necessarily know what had changed. The design was getting increasingly more complicated, and we were struggling to kind of keep up as is. And we were starting to consider kind of other interactions with other areas. But I think one of the main reasons that we needed to change was it was just a really paper-heavy kind of process. So, we had a five-step QA process for the plan, design, develop, test, and deploy. And at stage three, you'd already broken your solution up into parts. And for each of those parts, you needed a memo to describe what your design was. And then when you were testing it, you needed a separate test plan to ensure that it worked Standalone, and that needed an author, and they needed an approver to make sure that the test you were performing were right, and it was someone to ensure that it done your tests. And then more often than not, the system owner wanted oversight. So, for just that small part, you needed four people to look at it. And we were already in a five-person team. So, if you did it properly, more than 50% of your team was getting involved in every minor update. And then to make things worse, when we deployed, we pulled all of these together into a colossal document with integration testing evidence. Which just was more time spent writing and less time actually testing. So, I'm going to put a little snippet of advice in my talk. And I think one major one is don't go waiting for your catalyst to implement the solution. We waited for ours, and we waited too long, but don't wait for yours. So, our catalyst was COVID-19. So, overnight, we went from working on our engineering PCs quite happily to having basically zero capability whatsoever. Development came to a standstill, and so did our assets. We had some standard laptops that we could use, but they kept crashing essentially every time you open up a word. So, I wouldn't be able to run the codes that we needed to. So, the key requirements for our kind of action plan that I put forward was we needed to be able to enable remote working. We needed to work with what we had. We had no additional budget for this, and we needed a quick turnaround as quick as possible. So, essentially, my solution was that I was going to use the IT provisions that we had in the office. And thankfully, we had 10 of these little mini PCs lying around for some data churning activities. I was going to repurpose them using Ubuntu. I was going to make one of them the head host node and use Docker to host a whole bunch of servers that we'd need. So, I ended up using MySQL for our data, GitLab for our lifecycle management, and PopIt so that I could push some infrastructure to the client nodes. Why these tools? So, I'm kind of a little bit nerdy, but I run a few servers at home. I've got Plex up and running, so my boys can watch as much frozen as they want on their tablets. So, I use Docker for that. I also do a little bit of coding at home, and I'd use PyCharm. It's quite a nice interface, and given our solution was predominantly Python, it seemed like the best way to go. I'd use MySQL a little bit before in the past. So, it seemed like a sensible tool to use. The ones that I wasn't too sure of was our lifecycle management tool. Because of the community edition version of GitLab and the fact that we could host it by ourselves, it seemed like the obvious choice. And PopIt seemed quite nice, given it uses YAML, and I'd previously used that before. And we wanted to go cloud-computing as well, so this kind of a stepping stone in that direction as well. So, I would suggest that anyone wanting to implement changes do your biggest changes first. I mean, with DevOps, there's normally a big mindset shift that needs to happen, and just unlock the potential quick. Get your quick wins, it'll be a big help. So, I wanted to show our current DevOps school. I mean, it looks relatively low, but I'm really proud of it. It kind of shows that what I've implemented is starting to click and starting to work. So, people are happy putting issues on the board and supplying comments for peer reviews, merge requests of in-use, which means people are branching. It's great. So, where are we going to go next? I think we just need to push further and further down this DevOps trend. So, I want to utilize CI-CD for all of our testing requirements, get those automated. Build our method into a container so we can get a Docker image that we can deploy. Eventually, go cloud-based, join everybody else using Python 3. What I would say is, you know what's best. There's kind of no one-fits-all solution to DevOps. So, just give yourselves a little bit of time to explore and try and unlock the potential for you. And if you're not entirely happy just giving someone free reign to go and explore, link it to in-flight tasks. So, our setup has been incredible. So, it's been much better than I have envisaged. We've got remote working capabilities, which is amazing, but it's increased our capability to more than we had in the office. We've got a framework to build on. Our peer reviews are so much simpler now. And we're configuration-controlled, fine-line. We're starting to automate these really repetitive tasks, which is really good to see. So, I'm really pleased with where we are at the minute. And kind of as a closing remark, what I would say is just go trust yourself. Regardless of your position, if you feel any path DevOps will give you a benefit, then make those changes. If it really is a benefit, the justification will be simple. So, I really hope some of this story has resonated with some people and thank you for listening.