Transcript: Deployments

Hello and welcome to another episode of Django chat. In this episode, we're going to talk about

deployment, the things you need to do to change your Django application and options for putting

your site online. As ever, I'm joined by Carlton Gibson. Hi, Carlton. Hello, Will. How are you?

I am good. So let's this is one of the top questions that I get as a Django educator.

And it really is confusing the first time or several times you go through it. So there's

a long list of things that are different on local django versus deployment django as a django fellow

perhaps you could talk about why django makes some of the choices they use such as sqlite and all

the rest to make local development easier well sqlite uh or sqlite like you know sql was a

separate programming language back today so surely it's called sql rather than sql so we'll call it

sqlite i you know i don't know anyway sqlite why because it's in comes embedded in um python and

you can just get up and running and you don't have to set up a different server and and so when you

do start project and start app and you can run server you're up and running with sqlite or sqlite

i just said sqlite who knows what it's called you're up with yeah yeah you're up with sqlite

um without any extra work and and you know when you're first starting the last thing you need is

oh install postgres um yeah it's it's hard it's quite hard to set up postgres or another one on

server, especially if you're not using Docker. And yeah, where a SQLite is file based. So it's

just that little file right there. And boop, away you go. So let's go through there's a list of

things. And then we'll go through maybe and talk about the choices Django has made. But first,

we should mention, there is a deployment checklist in the fantastic docs, which we'll link to,

and you can run run a command, manage.py, check dash dash deploy, which will in an automated way,

say, hey, you forgot some of these must-haves

because there's a bunch of nice-to-haves

depending on your project,

but there's a bunch of must-haves

of which switching over from SQLite

is in most cases one of them.

Yeah, to run that deployment check is, well, handy.

Yeah, but I say that because I wasn't aware

of that page in the docs for a long time.

Yeah, so the two things,

the checklist, which is a page in the docs,

and then the check command with the deploy flag,

which is like automated.

So normally when you migrate, the checks get run to make sure you haven't misconfigured an admin

or misconfigured a model, but these extra deployment-only checks,

you have to actually enable the flag and run the command.

Yes, you need the flag.

So let's go through the list.

So number one is probably debug.

So in the settings.py file, by default, debug is turned to true,

which gives all sorts of nice debugging and other error collection,

But you do not want to have that on for production.

You want to change that to false because that means that anyone out there in the great wide web can see things you don't want them to see about your project and it will be insecure.

So that is probably number one.

If you had to pick only one thing is switch debug to false.

Yeah, and the error page that Django throws up shows your whole environment.

Yeah, it's everything.

It's everything.

So you can't have that visible.

But I mean, how you configure that, there's multiple ways to automatically toggle debug.

I mean, you can do it with different settings files.

You can do it with environment variables.

I'm curious, do you have a personal preference for how to do it?

Because it's actually a little bit tricky configuring it so it automatically knows,

oh, I'm in local, you know, change debug.

And when I'm in production, change it to something else.

Oh, I'm almost scared to say what my personal preference is.

Oh, yeah, you're a bit of a, what's the kind word?

stalinist no okay so so i well i'll say so so most many people are probably aware of the two

scoops of django book which came out a couple years ago which advocated multiple settings files

so you'd have a base settings file and then a local settings file and deployment settings file

which would override and so you would sort of chain them together and run a different set of

settings files depending upon which environment you are in that's the standard pattern people are

aware of and to be honest that's what i use on quite a number of my projects yeah and it it works

there's nothing wrong with that i have been using docker a lot recently and with docker you can use

environment variables which is 12 factor auth type of deal and so there you can also override but

basically you can have a single settings file and then you can override your environment variables

yeah and if i was starting fresh today that's probably the way i would i would do it yeah i

think it's simple it's simpler if you're if you've never done it before use environment variables

don't do the settings pattern but the settings pattern is fine too but it is quite confusing i

mean i've just finished the the chapter on this in my book jango for professionals and i've talked

to quite a few experts about i mean i could do a whole episode on just environment variables within

docker so it's um and it's not just in docker it's in your local development environment it's

it's how do you set environment variables sensibly and um think crazy things like you know because of

the way the the the heart the unix programming environment is settings environment variables

arrive in your process as strings even though they might be integers you might want them as

integers so you need some kind of help to cast them to the right type or you need to be aware

that they're going to come in as strings environment variables are kind of complicated

and they are i think a first level um multiple setting files can actually be easy so you've got

your base ones which are the same in every environment and then you've got your local ones

where you've got you know your i know your local debate database set and then you've got your

production settings which have your production database settings plus this debug equals false

yeah well and with with the docker-based environment variable setup you have your

your default which is basically your local and then you so you have a single settings file you

have a single environment variable file like a dot env and then you have a dot prod dot env which

just overwrites those so it's actually what it's two files instead of three the way you would have

with settings but it's the same idea you want to automate it so so one way people handle environment

variables is to put them in an m file of some kind so this is a file that has key pairs between

an environment variable name an environment variable value and somehow you get that into

your environment when launching the process yeah and there are all sorts of tricks about that but

if you're going to have multiple environments you're going to end up with one of these m files

for each of those and well how is this any different for multiple settings files it's

you know there's no there's no free there's no free lunch here right no and and you can also

just hard code your environment variables into your docker compose file with docker though

i think generally speaking a better practice is to create a dot m file because then you can

get ignore that file so it's not in your source control so you're yeah so the whole point about

this is which is the whole point secret right the whole the whole thing is otherwise you put

things like your secret key or your database password and or whatever into your into your

source control and you don't want to do that um and so yeah but so this so what we just discussed

is a very a shorter variation of the conversations i've been having with other experts so

you need some way to toggle between local and production um it is complicated you can do the

settings file approach you can do the environment variable approach pick one try not to spend too

much time on it as would be my advice but um it is tricky and that leads us to the second probably

the second thing you would want to change or at least make truly secret when you're going to

production which is your secret key so this is what 50 i think it's 50 character string that's

something like that that's automatically generated um when you do start project command you've

probably checked it into source control you can actually i'll do a link to it you can use the

internal django to do on the command line to generate a new random secret key which you might

want to do um and then link to that through an environment variable but that's something that

you like it says in the settings files but you really want your secret key to be secret because

of some it's used for all the hashing of all this all the other secret stuff within dango no but

everything like um if you've got a sign-in link then it will be it will be hashed used with the

dango secrets and that will be used the secret key to generate the hash the session identifiers the

you know everything like absolutely everything so what do you so what do you how do you keep

your secret since you're setting files okay so yeah exactly this so for a production environment

um you have one which is outside of source control and normally i would keep that in an

in a dot m file and then if i have a soup in a supervisor or in whatever process manager i'm

using load that into the environment when calling the the django process yeah and that works with

ansible as well and you know ideally you can store these things in some sort of vault yeah like a

password manager somewhere somewhere safe well the password manager for small teams but then when

you're deploying it um all the major cloud providers will provide a um a secret keeper

place where you can put a secret in and you can only fetch it back out with the right key and

it'll give you the it'll give you that value but it's not readable by anybody ever um so um

hashicorp have got one called vault and then um microsoft azure's got one and google have got

one and amazon have got one as well i can never remember the names of all the services but they're

a nice place where you can put those and they're online they're shareable with with a team and then

you can have your process access those on demand right because this is another key aspect if you're

in a team setting you might want everyone to have access to the code base but you don't want everyone

to have access to your um stripe api key for example or your production database password

reproduction yeah certainly yeah some horror stories i could tell about that so um if also

one thing to mention there is a fantastic third-party package django environ which um i

haven't found a use case for it within docker but in standard non-docker environments it packages

up a bunch of other tools and it's a really great way to do 12 factor auth with environment variables

so we'll link to that um number three i would say so debug secret key allowed hosts do you want to

yeah so what allowed hosts are okay so um you you don't want your django app for my pretty

website.com to respond to um requests for someone else's evil website.com so you allowed hosts is a

list of exactly allowed hosts you you might respond to my pretty website.com as well as

my friends pretty website.com you might respond to those two but nothing else and so you put those

into allowed hosts and then django will reject any settings any requests for hosts which don't

aren't matching that's not you know that's not there are ways of spoofing the host header and

other such things but that's a nice base level check it says no i'm not going to respond to

requests for the wrong website right and the the default if you look in your settings.py file

it is just um empty oh it looks empty but really it's set to um local host and one two seven zero

zero eight thousand if so true was that if debug is true if debug is true correct yeah right right

so um uh you will have to set a loud host whatever your deployment whether it's heroku all the rest

you'll have to put that in there so yes and you will get an error so but this is this is the error

you get is from the checks you remember earlier on we talked about the check framework where you

manage dot by check that's automatically run and that allowed host check is run every time and if

the if debug is false then it will check that you set allowed host correctly yeah and that's

independent of the extra checks which the deploy deploy flag deploy flag django has these batteries

thoughtful people smarter than me have thought gone through this before yeah and like for instance

like setting the right header values and things on cookies and stuff that you you know you and i

and everybody else we don't know but somebody has thought about it and they put the time in and

they've made sure that you've configured it right and they tell you if you don't and that's yeah

it's quite nice so let's see what would be number four i would say static file

stuff so this would be images css javascript uh there's actually uh jacob kaplan moss will link

to this gave a fantastic talk at pycon on um it's called assets in django without losing your hair

and basically you need to uh in django what our assets are called static for legacy reasons and

then there's often media which refers to user uploaded content so you know so a static asset

would be an image but you could also if it was coming from users you would put it into a media

and his talk kind of goes into this but the reason why there's a distinction is because you don't

trust your users you shouldn't so you want to put that information not on your server and then when

you reach a certain size you probably want to take all those assets and not have them on your

server either even the ones you've created and put them in a cdn um like s3 or cloudfront something

like that um but one thing that i took away from that talk is you can scale pretty far actually

with keeping assets on your local server, actually.

The numbers he gave were much higher than I expected

because I've always, I guess, pretty much really optimized

and gone right to S3 CloudFront.

But maybe your experience is the same,

so you can go pretty far with not doing that.

Yeah, I mean, let's say you have some standard setup,

you know, a single virtual machine running Nginx

with a Django application behind it,

perhaps with Gunicorn in front of it,

Green Unicorn, we call it, but Garnacorn.

If you've configured NGINX to serve your static files directly from the file system,

and especially if you set the right headers, the right response headers,

so that those requests are cached, because they're static, they don't change.

You can set long-lived headers.

Actually, that instance, that really basic one server instance, can serve a lot of traffic.

Don't do it unless you need to.

and then there's the fourth level is webpack and parcel and all these things you know for

her packaging your javascript which if you can avoid avoid yeah i mean certainly yeah it depends

again it's like if you're if you're if you're shipping a small django app yourself then keep

it simple don't get into all of that stuff if you're part of a bigger team yeah you need all

of that you need that front end because that's what the front end team will give you but you

need to bundle it up then you need to put it somewhere where your web server can find it be

that on a cdn or be that on your single web server but you'd be amazed how much you can get a small

instance to serve if you do the right things yes two more points i have anyways on quick list so

one is so the database so we mentioned you need to decide on your production database and generally

speaking you don't want sqlite right now built-in support for postgres sql mysql and oracle though

oracle may not be there for that long so no i think i don't know if it's going no no okay i

we're keeping maria dp is coming along too i think okay well i'll edit out the oracle slang

then the slag then no no let's let's slag off oracle do you so for me i've almost predominantly

worked with um postgres uh i feel like if you don't if you need advice that's probably the

advice you will hear in the django community but if you're asking for advice you also don't really

know what you're doing so it's they're kind of all the same at the beginner level yeah i mean

so when i started it was all mysql it was just that was that was the database and so for four

five years i was running mysql all the time and then postgres came along and particularly with

when django brought in the contrib.postgres the extra fields like the json field the array field

the hdoor stuff you know there's range fields in there now there's case insensitive text fields

there's all kind of extra stuff which postgres um gave you as well as the geo django stuff which

works kind of better on postgres or postgis um postgis i ended up moving over to postgres and

for a number of years now that's been my sort of go-to option um i'm a big fan of full text

search as well that jango has integrated that postgres has had for a while yeah i'm increasingly

coming back towards um sqlite for a lot of use cases if they're read heavy and things like this

i'm just a really closet fan and not a closet fan you'll wear it proudly on the sleeve i'm a big fan

of SQLite but yeah Postgres is perhaps the beginning place to go in the Django community

at this time Adam Johnson I'm really hoping to get on he maintains a package called Django MySQL

which brings a lot of the features from that are similar to Contrib Postgres for MySQL and he'll

come and tell us why you should use that or MariaDB which is the open source equivalent or the free

software

equivalent of mysql because um some microsoft um sun or no sun owned mysql and oracle bought sun

and so with it um mysql is is owned by the oracle brand so maria db is the open is the free software

um right offshoot of that i think what oracle owns java now right or sun or one of them you know so

that's partly why java is so when sun bought i'm sorry when oracle bought sun they got java and

mysql as the yeah for the package good way to kill an open source uh community um well last

last big one i would say is uh the admin um there's multiple ways to what's called harden it

probably the biggest one is you should not run um you should change the url for your admin you can

go into your um top level urls file and do this um just make it anything other than admin because

if you were a malicious actor you could write a script that says hey whatever site slash admin

would be a django site and i will just try to brute force my way into the admin and cause all

sorts of harm yeah and if you run any web server ever and you just look at the access logs for that

you will see regulate like every hour you will see request after request for known urls and most of

Those are WordPress URLs, but also Django URLs appear in those.

And these are people running automated penetration kits, automated scripts, which find a server, attack a server, and find if it's got weaknesses.

So by renaming your admin, you can avoid most of those attacks for Django because it's not that your admin is any more secure.

It's that the automated scripts don't hit it.

Yeah. Well, I remember the first time I set up, I think it was a DigitalOcean server, and I didn't know what I was doing. And within, and whatever, I forget the lockdown steps you're supposed to take, within 90 minutes, basically bots had taken over and I got a notice from DigitalOcean saying like, your servers doing malicious things.

so it happens it's a scary place out there in the uh internet especially if you're rolling your own

server stuff yeah and this is this the key point is that these these attacks aren't somebody

picking you out they are yeah it's not personal yeah it's not fully automated and so it's not

if there is a vulnerability which your site exposes it's not a matter of if it's a matter of

when yeah and so so definitely change the admin url um there's actually um lacey williams and

Jeff Triplett have written an article on hardening your admin, which we will link to.

So that's the basic stuff.

So it sounds like a lot.

In practice, you will write scripts or you'll get used to doing this for your Django sites.

But the top ones are you got to switch to bug, keep your secret key secret, allowed

hosts, you'll need to put in wherever it is in production, static files, you'll need to

think about that, you need to choose a production database, and you should do some basic steps

around the admin.

And in addition to the check, there's also Pony Checkup, I believe, is still the site

that's run by Sasha, yeah, that you can put in the URL for your site and it will run a

bunch of automated tests to see if it's secure.

So that's a good, like, I always do that after I've gone through all these things, just as

like a triple check.

But there's also, within Django, there's a couple commands that maybe, do you want to

cover, Carlton?

So migrate, collect static.

Ah, right. Okay. So for me, right, there's a one, two, three of deployment, which you've got to do

every single time. So the first one is upload your code. You've got to get it onto the server

somehow. Now, you know, back in the day, that's our sink and a can of beer is the joke about

deploying PHP sites. But you can, what can you do? I don't know. You can clone your repository

on the server and you can get pull onto the server, which is not a bad way. As long as you

don't mess around on there and get your your um that your checkout messed up by you know getting

i think most people most companies i think do it this way they put it up on github or wherever and

then pull from there i think that's the standard approach and that's quite cool um you can extract

some kind of zip archive you can you can even set up a um a pipey icon and uh set up tools publish

it to there but that's you know yeah i mean with like heroku you you push the code so you you do

like um sort of git push organ you do git push heroku origin so that so literally you the two

step is you push it to github or bitbucket or wherever and then separately you push it up to

heroku and then it will automatically go through all the steps for each time you push new code to

it yeah and these your app service has a similar thing where you can do a push from your local

commit and yeah i think they can also pull on you know they can watch a github branch as well some

of these services do that when you push to the github branch it automatically pulls on the on

the server that's kind of cool yeah but this is just sorry to interrupt but so a big thing for

beginners is they'll say well i you know i wrote a local blog jingle blog and i put 10 entries in

there and then i put it up on my platform of service and i don't see it what up with that

yes and that's because it makes a ton of sense it's because it it just takes a while to understand

that your local database is not your production database it shouldn't be you kind of get this

drilled into you with practice but that's why you know your local and your production environments

are different but it is it is confusing and it takes a while for people to internalize that and

i don't know if you have anything to add on that but i see people do that again and again and i

certainly went through that process myself saying like oh i just my site looks how i want it to look

why does it look like that in production it's like well okay so the thing you can do here is you can

set your, you can create a settings file so you're not connecting to a local database,

that you're actually connecting to your remote database. So assuming that your local IP address

is allowing you, or you can SSH tunnel into wherever your production database is, you can

set your local install to connect to your production database. If you want to, when you're

creating a small blog like this, this kind of works. So locally, you're developing on the code,

but you're still, when you write a blog post locally, it still goes into your production

database and importantly as well your media files so you know you create a blog post and you upload

an image and that gets saved your local media file not to the one on your web server right

where's it gone and how do i sync these things uh-huh it's one thing you can do as well is if

it's read heavy you can use sqlite and you can just upload you can yeah yeah if it's just a

file into place yeah and when you want to work locally you can just download it and then you

can work on that and then you can upload it to replace it that that's kind of um poor man's

sink to yeah yeah no i yeah um it does work it does work so all right so migrate uh the second

command yeah yeah okay so the first one is upload code right and then the second one is you've got

to migrate your database um and so not if you've got a hosted you know you've run rds and you've

got a hosted postgres instance and um you've you've created some changes you've tested them

locally you've put your code up there now you've got to run migrate and so you need to do that on

your server that's connecting to your production database or again you can connect locally to

production yeah and again you'll say i ran it locally like what's going on in production yeah

you've got to migrate your production database and then the third one is collect static where

you put all the static files from your project somewhere where your web server knows how to find

them yeah and jacob talks about this but yeah the collect static command which is automatically run

on heroku and i assume other platforms takes all the static files from all over your app puts them

into one nice um place for django to refer to um that's another thing that takes take some time to

internalize how static files work within django yeah but there's a great guide and you've just

got to take your time and like all these things yeah the docs are clear once you know what you

like that's what i always find like once i understand something i go read the docs i'm like

oh like they make so much sense like i would have written them this way but when you are learning it

and when you are frustrated you know it's like these half truths and you're like ah so it's not

the doc's fault but that is the reality of django beginner it's like what we talked about in the how

to learn django episode it's like um there's the docs which are kind of like reference material

versus the tutorial you need the walkthrough yeah yeah and then first time this is my this is like

my meta understanding at this point in my career is that tutorials and

documentation are different things and should be and always will be but often you want the tutorial

when you're learning not the docs um yeah no entirely entirely which is what i'm working on

so and others so don't worry about it we'll cover we'll cover the bases actually for image stuff i

wrote a a recent tutorial on how to do image uploading or file uploading within django that

covers some of the basics on static and media files that we'll link to it gives you and often

Often the hardest thing here is if you're configuring on a web server is to configure the right directory permissions and make sure that, you know, your Django process can write to the folder and your web server can read from it.

Yeah, that's the last thing we should cover.

So, yeah, where to deploy.

So one way you were just saying is a virtual machine where Linode, DigitalOcean, I'm sure there's others we're forgetting.

But, yeah.

Yeah, all of the cloud servers offer pretty much all of these things as far as I can tell.

They all seem to offer what I'd call a hosted runtime or a platform as a service where you just push your app code and it runs it for you and you don't have to worry about it.

They all seem to offer a virtual machine solution where you can provision a virtual machine.

It's like having Ubuntu server there and you have to install the right software.

But again, you can get images, like base images, which you provision from that one and it's already got the right Python installed.

And then you just have to pip install, you know, Django or your project requirements and create a virtual environment, pip install your requirements and run it.

And it works because that base image has all the things you need to run a Django project on it.

And then they all now seem to offer a container runtime where you can push a Docker container.

And so, you know, it doesn't really matter which hosting provider I think.

Yeah, they're all, but they're all challenging and confusing.

I mean, I've only done it with a couple of them.

I understand in the abstract how it is done.

I could figure out how to do it in all the others.

But realistically speaking, you just sort of pick one.

If a beginner asked me, I would say do not go anywhere near a virtual machine.

You should do it as a learning exercise, but just use a platform as a service.

Use Docker, Azure, Python, anywhere.

Just get it up there.

The trap of virtual machines I found is that it feels like real engineering because it is, you know, DevOps is like a whole separate profession and like it's like getting gnarly and you get in there and you fix things, but it's just endless.

And your end users do not care where your site was hosted.

They just want it to work and be up.

And so unless you are at significant scale, in which case you shouldn't be the only developer, I would say don't go anywhere near this stuff, except for learning exercises worth doing.

Or if you know what you're doing, you've automated scripts, which I suspect is kind of where you're at, Carlton.

Yeah, and this is what I was going to say.

So you pick one and you learn it.

And then you make sure that your deployment to that is scriptable.

So tools here like Fabric or Ansible.

You know, Ansible is the big sort of name and that's what's built in Python.

Yeah.

But you, so you've got a deployment script.

So when you run, you know, my project deploy, Ansible playbook deploy, it uploads your code.

you know does the git pull or whatever on the server in the right place it migrates the database

it collects static it runs you know the deployment checks that you want to do it reboots your process

managers that restarts your django application the all these kind of things you know it refreshes

your ssh certificate from let's encrypt it yeah you know a script all of these bits and then you

can start to think oh you know i've got this running on app engine i could easily get this

going on you know this app service over here or this bean elastic beanstalk over here by just

changing a few bits of the script and then all of a sudden instead of being able to do it in one you

can do it in three and then you think oh i could do this with a virtual machine and yeah i can

provision a virtual machine and and you slowly increase the yeah you slide you slide down into

more and more control well and it depends how what value that has to you yeah so um tom dyson said on

the wagtail episode that you know we were talking about the price or did he say or was it in the

after chat i don't know but he was saying that you know that actually the platforms of the service

they're really quite affordable quite you know until you scale up quite high because the time

you take yes configuring virtual machine or whatever is it's like oh it'd be much cheaper

if i did it on this micro instance that only costs x dollars a month yeah but you're not counting

your hourly rate that it took to get that micro instance in the position where it could serve

those requests exactly i mean i've i've wasted weeks and weeks and weeks of my time on solo

projects or you know early stage startups fiddling around with virtual machines when

you know you know thinking yeah exactly that thinking oh well i'm saving fifty dollars a

month versus this other this platform of service meanwhile two weeks of my life have gone away

so yeah and you could that could have been two weeks of your life writing copy or writing user

interface code which actually so i see one so you should it is fun to learn how to do this stuff and

is interesting but value your time and i would say be very specific about this is a uh a learning

exercise unless you're in a big company and then you know you get paid unless your focus is down

towards that devops stuff yeah because there are different ways you can go you might be more

interested in that back-end system admin devops stuff in which case learn it because you ain't

going to get the roles that you want without without that experience but if it's not your

specialty if it's not your what they call the area of genius then head somewhere else area of

genius i'd like that yeah my wife told me about it she read some books so i'll have to find out

what the book was oh okay that's such a nice way to phrase it yeah well and i so i i know that i

am not a devops person i am a very product focused engineer if that's a term um i kind of veer more

even though i spend all this time on jango i veer much more towards the front end and i just want it

to work and talk to users and get feedback right if you imagine a continuum right yeah where like

at the top end you've got um i don't know doing the graphic design for the buttons and in the ui

that kind of stuff and at the bottom end you've got the um configuring the network layer for your

kubernetes cluster like django's sort of up the front end side of it even though it's it is a

back-end framework yeah it is there's so much gnarly stuff below to be able to serve requests

that django's actually front end yeah that's the title for the podcast django's front end

And I think, you know, in terms of just a side note on career advice, because I get emailed for career advice all the time, which is kind of hilarious to me. But I would say that it is probably much more marketable to have a strong backend knowledge, though it narrows down the number of companies you can work at, because not that many companies are at scale. However, you can spend 5-10 years, you know, learning how to do all these things that are really hard to learn otherwise, whereas, you know, CSS or JavaScript, you can do that on your own a little bit.

Yeah, but you can also spend five or 10 years

learning that stuff, which-

Oh, you can and should.

I'm just saying, maybe this is,

the bias that I see is that people respect

10 years of backend experience

more than 10 years of frontend experience.

And maybe that's just picking the wrong clients, but-

No, there is that bias.

I think it's totally misplaced

because somebody who really knows CSS

is absolutely invaluable.

And it's just as much a skill

and it's just, you know,

great experiences can't be crafted without it.

Yeah, even the most hardcore,

you know, lives in the command line

engineer, when they see a site, they can say that's an ugly site and they will implicit, you

know, implicitly judge it in some way. So anyways, um, all right, I think we covered it. Uh, it's a

complicated topic. Um, I've been spending months and months trying to figure out how to simplify

this, um, for, for my new book. So I understand the pain of, of all this, but the takeaway is

you should check the deployment checklist. You should be aware of the check flag and pick a

platform as a service if you're just starting out get it running and then be aware that there are

all these other levels and it's it is really fun and interesting to learn all this stuff but

it's deep yeah and be so you know be a on the first hand be prepared to take the time because

it is deep and you need to get it right but on the second hand be conscious of hey am i going down a

rabbit hole that i don't really need to here yeah don't spend two weeks on like you know depending

think seriously you know what what's my career what's my project what's you know is this a

benefit to me yes um great anyway that that's about all that that's about all we've got to

say about deployment i think so yeah so we will see you next week carlton i'll talk to you then

all right take care bye