Your First Deployment Shouldn't Be So Hard! with Eric Matthes

Speaker 1: Thank you and thank you for being here. I've been looking forward to sharing this project with people for a while now. Um Well we'll cover a little about me, uh what is this project? I'm going to try to do a live demo. If I'm claiming that I've made deployment simple, I should be able to try a live demo. explain how it works, how it's tested, cover some use cases, tell you what 1. 0 criteria for this project should look like. And I'm going to offer some discussion questions at the end. And if I finish in time, I'm happy to take questions and I'm happy to spend as much time as anybody wants to in the hallway talking about deployments. If you're interested in contributing, I'll share something about that as well. About me. I first learned programming in the late 70s, early 80s, because my dad was a programmer at DEC

Speaker 1: outside of Boston. I feel grateful to have learned about programming in the basic era and have watched the languages and ecosystem evolve. I have a BS in physics, and I think if you study physics, you have to tell people that. But I've been a hobbyist programmer for most of my life. Uh I wanted to be a particle physicist, but I went into teaching and found that the challenges of teaching were as hard as as satisfying as the the challenges of hard science So I spent 25 years teaching fifth through twelfth grade math and science, and I taught um intro programming classes whenever I could. That's what led to writing a Python Crash course. I believe in the democratizing power of web apps. I have believed that for a long time, and I still believe that. So what does that mean?

Speaker 1: People have ideas, all right? And if somebody knows how to build a web app, they can turn their idea into a working prototype. So if your idea can be implemented through code and you know how to make web apps, you can build a working prototype. And then you can share it with the world. And that that shares power. So where do these things live? Ideas live in people's minds. All right. They build a working prototype. That prototype lives on their local system. This is people learning Django. If they want to share it with the world, they need that deployed project. And that's the challenge. That's the cliff. That's the hard part. So, what are the origins of this project, Django Simple Deploy? Chapter 20 of Python Crash Course covers deployment to Heroku.

Speaker 1: It's one of the things that makes people satisfied about the book. They go from knowing nothing about programming to building and deploying a working, simple but non-trivial web app using Django. And so I've always kept my fingers crossed that Heroku would not abruptly change their process and break this chapter of my book. Everybody who has written a book or a tutorial or video course that covers deployment has done that same act of crossing your fingers. So in fall of 2020, I wrote a custom Heroku build pack because my book is really satisfying. It teaches people how to think as a programmer. Most of the book teaches thinking and doesn't teach write this code. There's five or six pages of chapter 20 that just say write this code. Make this file. Here's what it does, you probably won't understand it.

Speaker 1: And that doesn't feel good. So I wrote a custom Heroku build pack that automated all of that configuration for people by inspecting their project. But it didn't feel good because it felt like I was doing Heroku 's work for them. That script ran on their servers and I have no control of that. I still have my fingers crossed that that that doesn't change. So um fall 2021 had the idea that like, okay, could I do something in Django's world that does that same inspection and configuration? And so I came up with a management command, simple deploy, that does exactly that and it lives in Django's world, and it feels right because it's a deployment solution that lives in Django's world. It overlaps with the platform's world, but it lives in our world.

Speaker 1: So I'd like people to think back a moment for a number of quick questions. Do you remember your first deployment? Like how many people remember their first deployment? I'm not going to ask for like raising hands for all of these, but think back to those first deployments. How long did it take you to see your project deployed? How many tries did it take? And we hear the laughter. Have you ever left a project undeployed because it was too much work? All right. So that laughter is an idea that did not get to be shared with the world. Have you ever been frustrated by a typo or a small mistake during initial deployment? Or been frustrated by a platform's unclear or outdated deployment docs? All right, so here's what people are saying. Another day, another failed Django deployment.

Speaker 1: Tried to deploy my project on the internet, getting this error. What am I doing wrong? And why is deploying Django damn near impossible? Three question marks 71 comments, no awards. Um so what is Django Simple Deploy? What is what are we doing about it? It's a stable API for making the initial deployments across multiple platforms. And so this is what the command looks like. Manage. py simple deploy dash dash platform. That's the only required argument. And then you specify which platform you are targeting. Fly. io. If you are Deploying to platformsh, the command looks identical except for that argument for the platform. And it currently the project currently supports these three platforms, FlyO, Platform SH, and Heroku.

Speaker 1: So what are the prerequisites? You have to have a simple. I use that that word simple is pretty interesting to explore. It's non-trivial. It does need to touch a database. And have some static files and whatnot. Project that works locally. You have to use a requirements. txt, poetry, or pipem, something to manage your requirements. You need to be using Git to track your project. And you have to have the targets per target platform CLI installed and an active account on that platform. I think those are fair and reasonable requirements. So what does simple deploy do? It inspects your project, it configures your project for deployment to that target platform, and it can automate this entire deployment process. And that's what I'm trying to try to demonstrate. So what does that look like for Fly. io? First pip install Django simple

Speaker 1: deploy, add simple deploy to installed apps, and then run this command which you just saw with the additional flag of uh automate all. And that's it. So I'm going to try to show you this happening with a simple project that works locally on my system, no platform-specific configuration, and see if we can deploy it in three steps. This is where we do cross fingers. Alright, so I have this running in Runserver, and it's a blog project that does have user accounts and work with a database. So we'll quit the run server. And do what I just told you, pip install Django simple deploy.

Speaker 1: All right. And add simple deploy to installed apps All right. And now we should be ready to um deploy it. Manage. py, simple deploy , tell it what platform we're targeting. We're going to do Heroku. And we're going to use that automate all flag. All right, it's gonna confirm that we wanted to automate everything. Um it's gonna start doing the work. All right, so this is two to three minutes.

Speaker 1: Um it's a long-ish live demo, but I think it's important to do this. Um there's a couple points I want to make while we watch this stuff scroll by. Um This is the goal. When people are doing their first deployment, they want to see this stuff scrolling by. An interesting question is how long does it take them to get to a point where they see that stuff scrolling by? I had hoped to do this live demo with Fly. io because a lot of us are moving away from Heroku for valid reasons currently. I'm not an expert on deployment, but I'm becoming an expert on initial deployments. I've done hundreds of these initial pushes, and I've found that if you push to the same platform over and over again and then destroy the app immediately

Speaker 1: Some of them are resilient and some of the platforms start to like, I don't know, flag you internally and I start to see errors. And so I did a bunch of tests with um Fly I. O. this morning and it didn't work. And so yeah, so yes. The clapping is very validating because that's what I felt every time this works. To finish that that thought, I keep coming up with use cases for this. So it was not the most comfortable failing to deploy to Fly I. O. and it fails right before this talk. And I was like, wow, I don't have to choose Fly I. O. for the for the demo. So we could undo the configuration that was just done and repush to platform SH, repush to Flyio. And do that easily.

Speaker 1: So to Heroku 's credit , Heroku has been the fastest and most reliable of these hundreds of deployments. Um so I I didn't even get time to tell the story that I was going to tell um while doing that. Um so I will tell you that briefly on a blank screen. Um My first deployment was 2009, and so it's back when I was teaching. And my school was trying to do innovative work, and education standards are good, uh, but they're not consistent. Um And so my team, my s my staff wanted to be able to write our own education standards. But I knew enough technical stuff that we shouldn't be working in Word docs. We should have some structure for our uh the work we were creating.

Speaker 1: And so I made a Django project that was a tool for building educational uh standards. And so everybody would have the same um the same hierarchy, the same structure for their education standards. And it's cool. I got like it's working locally. Like I have my idea, I have my working prototype. And in 2009, I was like, Dingo deployment. How do you do it? Does anybody want to guess how I ended up deploying that project? On my laptop, using what? Okay. So I will admit this. Um I think I'm doing okay for time, so I'm curious to see how A show of hands. How many of us have ever used Runserver in some form of production, semi-production? Yeah. Alright, so

Speaker 1: to my credit, I did that in 2009. Nobody should have to do this in 2022. Alright, so I did uh I learned to uh detach a process and close the laptop lid and it still runs. Um But nobody should ever have to do that. So how does it work? How does simple deploy work? I'm going to use deployment to fly. io as an example, but it looks the same for each of the different platforms. There's a file called simpledeploy. py. It first validates the command. You know, is the platform you're requesting one that we support? Inspects your local systems so we know what kinds of commands we can use and how to run them, inspects your project. uh and first looks for if there's any reason that we should think we won't be able to deploy successfully.

Speaker 1: We'll just bail. One of the principles of the project is to configure your project for deployment, but not do anything that interferes with your project running successfully locally. And then it calls deployflyo. py so it calls a platform specific file. So what does that file do? For Fly O, it sets Flyio secrets, which is their version of environment variables, writes a Docker file, fly. toml, modifies your settings. That modification is a block at the end of your settings file that's conditional if you're running on the platform overwrite these settings. And it's done intentionally so that people when they go back and look at their settings file Those those modifications are not interspersed in their settings file. They can see exactly how the settings need to be adjusted for their deployment.

Speaker 1: And then it adds any requirements that aren't needed locally but are needed for the deployment. If you're using automate all, it creates new app for you, commits your changes, runs fly deploy, and runs fly open. For Heroku, it runs at git push heroku main, and then Heroku Open. The last step, and I think this is pretty important, it summarizes the most important information. If you're using configuration only mode, then it tells you the remaining steps that you have for deployment, gives you your deployed URL, tells you how to push further changes. Simple deploy should never support a command like push again, push new changes. It's meant to be your initial configuration work, and then you learn more about how to work with your chosen platform.

Speaker 1: One of the features that's coming up for the project is to give people inroads into their chosen platforms documentation All right, so summary using automate all is three steps, pip install, add it to your installed apps, and then run the command. There's a configuration-only usage that I want to point out. This is the recommended usage for this tool. Pip install just like we did for automated work, add it to installed apps. And then I do recommend people create the app on their own. and then run the manage the simple deploy command without the automate all flag. So what this step does is just configures your project. And so after you run this command, you're configured for deployment to your chosen platform. I recommend people run git status and they get to review the changes.

Speaker 1: And so this is that. The whole thing, it's not about hiding configuration for deployment. It's about automating things that are boilerplate and then letting people see that that was done correctly. And this is the point where they can reject it. Reject all these changes, but if they like it, they can add it, commit it, uh, and then they just run the the deploy and open commands uh themselves. So there's a few things to notice about this. We haven't done anything the user hasn't already done. They ran pip install Django, and so they already know how to pip install a package. They added their own app to installed apps, so adding simple deploy to installed apps isn't learning a new step. And they already ran managed app high run server, probably make migrations migrate. So running a management command is not a new thing.

Speaker 1: We never visited the platform's docs. All right. I don't want to keep people away from the platform docs, but I want to keep them from having to dig through and deal with the issues that were mentioned earlier. We never had to create a new file, no proc file uh on our own. Never had to modify an existing file, there's no real chance for typos. All right, we can see and review the changes that were made, and we ended up with a successful deployment. Who doesn't like that? All right, so getting into like um building and maintaining this supporting unit tests. Um how do you test a standalone management command? This was my first experience writing, I I've written custom management commands before. but they're always part of an existing Django project. This is a project that doesn't even have its own settings file.

Speaker 1: It acts on projects with different dependency management systems like PipMv Poetry. uh in different hierarchies like did the person start their did they run start project with a dot at the end or did they run start project without the dot? Heroku makes it hard to support both of those. Some platforms are more adaptable to um accommodating those different hierarchies. So our current approach is to I I have a sample project with one structure, sample project with the other structure, and variations of these projects using requirements at text, poetry, pipem. uh copies the selected project to a temporary directory, builds a virtual environment, installs dependencies, calls symbol deploy, and then examines that modified state of the project. And so my approach for testing is to basically do the same steps that I'm telling people to do and then make sure it's making the changes to that sample project that

Speaker 1: we want to see. I'd love feedback. If people know better about testing than I do, I'd love feedback about that. Integration tests. If you notice, this is a shell script. So it's test deploy process. sh. Because it has all the challenges of unit testing plus external network calls, including actual deployments to a personal account on the selected platform, which can incur costs. So it's an interesting project, a little intimidating to start. Um and has led to amusing invoices where my invoice says blog, blog, blog, blog. One cent, two cents, three cents, zero cents. Uh use cases. People who are new to Django and new to deployment, this is the obvious use case for this project.

Speaker 1: Um people who are experienced with deployment but don't want to deal with boilerplate. All right. So if you have a simple project and you wanted to push it, you don't need to do all that yourself. People who are experimenting with new platforms. When we saw this past year, people moving away from Heroku, again, it's not just because they're doing right there free tier, it's because they've had service issues that are making people lose trust. We watched experienced Python people, if you're on any of these Twitter threads, we've watched experienced Python people try render, try Railway, try Fly, try Platform SH. And It's not easy for a variety of reasons. And so a tool like this, what I find is if you if you create things that support beginners well, oftentimes they end up being useful to experienced people as well.

Speaker 1: Authors, creators, teachers, trainers. Simple deploy ends up being a buffer between you and an ever-evolving platform. So you're always going to cross your fingers a little bit when you create some kind of learning resource. But let's say um all right fly changed some of their processes. I think I think that's some of the the stuff I ran into this morning. If you were creating material that use a mature version of Simple Deploy for teaching people about deployment, you don't longer have to worry about that platform tweaking its process. As long as somebody is willing to maintain this project and adjust that update that script once your initial simple deploy work still works. And it makes including deployment much easier if that's not the focus of what you're trying to teach.

Speaker 1: Platform host, it's been super interesting. A mature version of simple deploy becomes a best practice reference for basic deployments to each platform. And encourages the feedback cycle between platforms and Django experts that's already happening. I think many of us, if we don't think too hard about this, we kind of expect platforms to like have a really good Django deployment story. They should know it Um they should know all the stuff Peter just told us. Um but they don't because because they're supporting many languages and multiple frameworks within each language. Um And so conversations between platforms and Django people is a really good thing. Platforms are not as incentivized to support beginners as many of us think they are. Uh one of the platform founders recently said we're all motivated to be second best at supporting beginners.

Speaker 1: Um and I appreciate the the candor the the honesty of that statement. They're right. Whoever is best at supporting beginners gets all the baggage that comes with supporting beginners. and brings in some abuse efforts as well. But we can support beginners as much as we want. And I think that's an important distinction as you kind of figure out where the boundaries are between our community and the the platforms themselves. So what are the criteria for a Django Simple Deploy 1. 0? It's 0. 5. 4 right now is things like if you already have a Fly app deployed, it won't work for you because it looks for a post It looks for a fly Postgres instance, and if it finds one, it just bails because we don't want to interfere with your current setup. I have asked

Speaker 1: In the fly community forum, how when I see a fly Postgres app, how do I know if it's linked to an existing app Um and I haven't gotten an answer yet. So things like that are was taking some time to get to 1. 0. So 1. 0 is support a stable, reliable configuration and deployment process for each of the supported platforms. Offer a stable API. So again, if you are using this in any context, you should know that the the Django Simple Deploy API is not changing. Include thorough, clear documentation and messages. I mentioned this earlier. I'm going to kind of wrap this up and make time for a couple questions if people have them, I think. I'd like to offer a straightforward way to deploy the polls project. This is the current API. That's the only required

Speaker 1: argument. You can specify a project name region. There's automate all that you saw. You can skip logging if you have a reason to do that. It checks that you have a clean git status. You can ignore that. There's some that support testing. All right, this is kind of the end. Conversation starters. What do you think deployment should look like to people who are new to Django? How quickly should experienced developers be able to deploy to a new platform? How much can we simplify the initial deployment story? What platforms are most appropriate for this kind of automated configuration? Is it reasonable to expect every hosting platform to always know the best Django deployment story? What work is appropriate for a community package?

Speaker 1: What work belongs to the hosting platform? And most important, coming back to the beginning, what happens to people whose first deployment attempt fails? And flip side of that, what happens to people whose first deployment attempt is successful? If you're interested in contributing, please weigh in on those questions. Uh feedback about the API is super helpful for getting to 1. 0. Anything about testing is helpful. You could write or critique. A script for a new platform or an existing one. There's a contributing page. Um I have this is a nod to Simons presentation yesterday. Uh the project is well documented in issues, 97 issues, 14 comments of me talking to myself about the project, um, commenting about it. But also notes about like

Speaker 1: Kurt is one of the founders of Fly. io , and he wrote this somewhere. And so there's references to all that information that you kind of have to gather in order to understand deployments across. multiple platforms. And these many of you know Will and uh Jeff from the community. And so that shared insight is going into what does the best deployment look like for the basic case for each platform. Uh I'll be staying for sprints. Please say hello. Thank you.

Speaker 2: I'm gonna take the first question actually. Uh I was wondering, does your project work with like poetry or any other kind of uh requirements? Uh

Speaker 1: fair question. Uh Heroku deployments originally worked with Poetry and Pipem. I have not tested them recently. I don't have any reason to think that they've stopped working. For 1. 0, it will work for all those variations for all the platforms.

Speaker 2: Great.

Speaker 3: Thank you. This looks like a game changer for a lot of people. After you succeeded with your first deployment and you're kind of in a normal workflow, at least in the teams I'm on, a a merge to main or production branch is the equivalent of saying we're ready to deploy. So can you configure an auto-deploy when a certain branch is touched, like the installation points to a branch and is responsive. to it?

Speaker 1: I'm not sure. Uh I have not thought about that kind of use case. Um I think there's an answer to that. I yeah that's a longer conversation. That I welcome.

Speaker 4: Your live demo used uh SQL Lite and you mentioned Postgres on Fly. Which database do you support or does it change depending on the platform? Which database do you use or does it depend on the platform?

Speaker 1: Yeah, great question. I have tried to use SQLite. If I'm saying that right, never say it out loud. Um on a couple platforms, but a lot of these platforms have ephemeral file systems. Um and it's they some of them say you can, and I haven't been able to make that work. Um I don't I don't have a uh favorite at this point. I like Postgres, but I really like SQLite and I've I like the conversation that moves towards uh SQLite is much more capable than people have oftentimes talked about. So that's one of those things where I I can't know every platform well and I'm quite open to the conversation about what that simple best case for each platform should look like.

Speaker 2: All right, we're at time. Thank you, Eric.