In this episode, Jake and Michael discuss different approaches to configuring a Laravel app, for consistency, security, and shareability among a team and across environments.
Show links
North Meets South Web Podcast
The one with environment config
In this episode, Jake and Michael discuss different approaches to configuring a Laravel app, for consistency, security, and shareability among a team and across environments.
Show links
- Duration:
- 40m
- Broadcast on:
- 08 Aug 2024
- Audio Format:
- mp3
- Go go go, this is Michael Drenda. - And this is Jake. Oh, hold on, and this is Jake Bennett. - And welcome to episode 160 of the Northmead Southward Podcast. (rock music) - Bennett, I have to get paper towel 'cause I just literally spilled bubbly drink on my laptop. - I did the same thing. I picked up my water vessel and I realized that I forgot to put something in the dishwasher that I had just turned on. So I put it down and water just sploosh it everywhere. So fortunately it was on the desk out, on the dining table so I can deal with that later. - Well, hopefully this doesn't impair the ability of my laptop to do what it needs to do. And hopefully these random key presses I'm making are not stopping the recording or anything insane. - I think we're okay, I think we're okay. - Yep, you just needed to have a captain cook at your microphone there. - A captain cook. - And Aussie slang, that means have a look or brief inspection apparently. - I listened to the latest. - It's a good thing I'm a true blue. - A true blue friend. - A loyal friend. - Yeah, that's right. I was listening to the latest business of Laravel podcast and friend of the show, Greg Skerman, was on with Mascalfa this episode and they ended up talking a bit about Aussie slang and Matt had mentioned that on the, in the, when I speak a chat, it doesn't occur to us as Aussies that people observing from outside of Australia don't understand some of the lingo and vice versa, so yeah. - Yeah, people have heard the story I think of the time that I was like, we were chatting and you had to go get a delivery at the door. And I was still in your ear because I could hear the AirPods, you were like hoping to hear pods. And I was in on an Aussie to Aussie conversation and it was a different type of language than you and I have ever spoken. - Yes. - Didn't understand most of it and, you know. - You'd certainly be left behind. I'll send you this video that I just saw the other day. No, not this one. There was a video that Marty Friedle I think shared with the chat talking about. Oh no, sorry, it was Simon. It was Simon of Rachael Otis. I will have to put a link to this in the show note so if I can find the original video, but it was basically one side of a conversation, like a phone conversation between two Aussies and two Aussie men specifically, it's a good one. It's a lot of yeah, yeah, yeah, yeah. All right, yeah. Okay, yeah, yeah. Nah, you're off course. Very. All right, so I'm gonna quiz you on some Australian slang here, okay? - Here we go. - So you can tell me what the meaning is. Carrying on like a pork chop means what? - Means like, you know, just being crazy, doing all kinds of weird things, just going-- - Acting unreasonable, I'll count that, yep. A grommet. - A grommet? - No. - A grommet? No, it says a young surfer is a grommet. - A young surfer, okay. - Well, I never got into surfing culture, so that makes sense, though. - All right. Whoop-whoop, like I'm driving in the whoop-whoop. - You're driving into whoop-whoop, it's going into the middle of nowhere, yeah. - Okay, whoop-whoop, not whoop-whoop, whoop-whoop. - Not whoop-whoop, no, whoop-whoop in the middle of nowhere. - How did that one come about? What's whoop-whoop? What is that? It's just don't know. - It's usually like dingo, usually dingo whoop-whoop. And I don't know why dingo, but it's like, "Ah, it just means it's a far distance from anything. "Etymology is said to have been derived "from the nickname given to men who carried fleeces "in shearing sheds after the sound they made "as they ran around." - Whoop-whoop, it is. - There you go. - Okay, mates rate. - Mates rate, you look after your mates, you give them a good deal, good price. - Good discount, a friend's discount, okay. Have a captain cook. - Have a captain cook. - You've got me-- - Yeah, do you know what? - It says have a look or brief inspections to have a captain cook. - To have a look around, like, contextually, yeah, I get it. I feel like it's something that maybe I've heard once or twice, but it's not common, and so, you know, it's not common vernacular, but for me it's-- - Okay, okay, I've got two left for you. A two-pot screamer. - Two-pot screamer. - A two-pot screamer. - That guy's a two-pot screamer. - Nah. - Someone who can't hold their liquor. - Someone who can't. We've-- - I was curious if you had actually heard that before. - Yeah, I've never heard two-pot screamer. Cadbury is one that we've-- - Cadbury? - That I use often, someone's a Cadbury, they're a glass and a half. - Wow, okay, okay. - It takes them a glass and a half to get drunk. - Okay. - And there's another one there. - I can't, I can't grasp it, but there is another one. - All right, I remember you telling me whispers. Whispers is a good one. - Whispers, that's right. - The guy who never showed me a shout. It's like, if you shout, that's like you're getting, you're picking up the round of drinks. - Picking up the chat, the wrap. - Yeah. - And the guy who never does that is called whispers. So-- - Whispers never shouts, that's right. - Whispers never shouts. Okay, last one is have a Rulus in the top paddock. - Have a Rulus, like being like 10 cents short of the dollar, be in a bit. - Yeah, exactly. - Not smart. - Not the sharpest tool in the shed. Yeah, not the brightest crayon in the box. - Not the brightest crayon, that's right. - Yep, yep. I've been using, I've been speaking of my dog, I've been saying he's dumb as a box of rocks. I like that one. - No, there's a box of rocks, yeah. - Dumb as a box of rocks, dog. Dumb as a box of rocks. He's been, I don't know, I don't really want to talk about it. It's not appropriate to talk about on this show. By the way, did I tell you we have chickens now? We got chickens. - I feel like we've had this. Yeah, I think we did too. - We have four chickens now, and my son wants to get chicken collars, so we can take them to soccer games here when walk, soccer season starts. Yep, walk the chickens. Chicken leashes, it's ridiculous. - Are they hens, you get eggs out of them or? - Yes, you can only get hens here in town. And so, yeah, we had to get hens. But yeah, they're good, they're fun. They're really funny, actually. You let them out, and they just kind of roam around the yard. - Roam around? - Yeah, it's funny to watch them. They always stay together, there's four of them, and they just kind of always hang out together, and they're scratching and pecking at the ground and stuff. It's funny. - Nice. - Anyway, nothing to do with anything. Except for, hey, what I will say is, I think you and I beat Aaron to the whole popping off thing. You know, we've been talking about-- - We had five out of wait, yeah. - Oh, man, well, at least, remember we used to do spin drift. Every used to do spin drift all the time. - That's right. - We're gonna be trying to-- - Not that it's a competition, Aaron, because it definitely is not. Yeah, I did try to get his sponsor of spin drift back in the day. He started with the best. - He started with the best. - He started with Aaron. - No, no, no, Aaron started with the best. I gotta say that, that lemon spin drift is quite delicious, although I prefer the grapefruit. He did say he would review that later. I gotta say that this one, though. This one's the best one I've had in a while. Bubbler? - Bubbler. - Yeah, it's pretty good, actually. This is Triple Berry Breezer, bubbler. Pretty good. - All right, I did actually have a mineral water earlier. It's made with wonky fruit. And if I can find, Dashwater is the name of it. So they make it with wonky fruit, which is, you know, like, you go to the supermarket and you buy fruit or you go to the green grocer and you buy fruit. And it's like, the good stuff goes there 'cause it looks good. But what do they do with the wonky fruit? The wonky fruit, you know, usually gets sold off or goes to a farmer's market or in the instance of Dashwater, they make wonky fruit. They use the wonky fruit to make their mineral water. So I had, I don't know what it was, it was a raspberry? - Raspberry's the one, yeah, sparkling water infused with wonky was, raspberry's. - Very nice. - Okay, it's definitely more than a passing, I don't remember the exact phrasing, Aaron used, but like, you know, it looks like, oh, it's like someone shouted the name of the fruit from the other room, is the other room. - Ah, there we go. - It's the flavor you get, all right? - Okay. - Yeah, this one was okay. - I like it. Hey dude, I got a couple topics to talk about today, but I've got one that I think would be a fun one to start with. Maybe we can just keep this episode focused on one, I don't know, maybe. - We can try. - I've got an interesting thing to, we've kind of come to a conclusion, but we haven't standardized it across our code base. Actually, I've got two things that we could talk about. Let's talk about the one, and then if we have-- - You want a style track and in thinking about the first topic, you've already thought of the second one. - Yep, well I know what it is, I know what the, okay, so here it is, okay, here's the first one. We're talking about running your tests in some sort of continuous integration system. So for us, we use GitHub Actions to run our tests, right? So that typically is in your .github directory, and inside of there you'll have some sort of yaml file. Maybe we call it tests.yaml. Inside of there you're going to set up your container that's going to pull down MySQL, it's going to pull down PHP, and it's gonna go through the process of setting that up, and then it's going to pull down all your dependencies, it's going to, then the real fun starts, okay? So now you've got your Laravel. Your Laravel stuff is downloaded, and your composer installed. So now we get into the meaty bit, and here's where it is. What do you do with ENVs? Now there's about three different places you could place these ENVs. And so the question for me is, where do you place each, and what is your heuristic for determining what goes where? So let me give you some options for where you can put ENV values. You can put them straight in your yaml file. So in your test.yaml, you can actually define for each of the different actions that you're gonna run. You can say ENV, and you can define straight in there an ENV value that will get picked up by your Laravel application, or that will get picked up by, you know, some command that's gonna run doesn't necessarily have to be there, but it could be like you're migrating, I guess in that case you would be migrating your database, it could be that sort of stuff, right? You could set those ENVs directly on that. You could also put them in like a.env.example file that you copy over, or a.env.ci file that you copy over out of your thing, you could copy that to the ENV. Or in the case of PHP unit, you have something specialized for that like PHP unit.xml, which you can also override, by the way, with ENVs that you set specifically on that PHP unit action. So there's a lot of stuff going on here. What is the methodology for setting ENVs? Where do you put what? That's the question. So I'm gonna clarify one more time. Here are the three options that you have. And I'm even sort of, I feel like, giving you a little bit of a leg up, 'cause these are the places I've decided to put them. GitHub Actions has a place where you can put secrets in a repo. Let's narrow it down to a.env.ci file. We can talk about why that would be later, but.env.ci and PHP unit.xml. Okay, those are the options. Let me hear your thoughts. - All right, so it may or may not shock you to know that we actually use all of them. - We do two. - No, we do two. In different situations. So the PHP unit.xml file. - That's why it's complicated. - It's not easy. - It is, yeah, yeah. The PHP unit.xml file, we will use for things that we want to be the same, irrespective of which environment we're running in. So if we're running in CI, or if we're running it locally, or if we're running it on another machine, these are the things that we don't want to change. - And you put that in which file? - Into the PHP unit.xml. - Okay, PHP unit.xml. I'm just gonna write this down for myself 'cause I'm interested here. PHP unit.xml. - So these-- - Yep, so these are specific values that we don't want to change where they're running. Things like Beaker at Rounds, Log Channel, Cash Driver, QKNet, like that kind of stuff that we want to always be the same everywhere. That goes in the PHP unit.xml. - Into our GitHub yaml file, into our pull request.yaml, we will then put all of the secrets that need to change, and we only put the secret things in there. And then we reference them from GitHub actions secrets. So, you know, dollar, and pran, pran, or bracket, bracket, and no brace brace, secrets, dot, and whatever. And so we map those one-to-one. There are some things in there that we hard code, things that are not secret as such, like URLs to, you know, UAT or staging or test environments for third-party testing, things like that that don't change or they just need to have some specific value. And then we actually have a third value or third type, which is kind of like the dot env.ci, but we use this for our review environments. So we will, when a pull request is opened and we add a review tag to it, we have a GitHub action that runs through and spins up a pod in Kubernetes. So we get like branch name dot review environment, whatever. And then what we do in that is we reference one password URLs in our dot env.review. And so we will just run that through one passes, hydrate or fill or whatever the command is, and it will find the corresponding keys and inject that into there, and then we use that in our review environments. So yeah, all three of them. Dot env.example, we will put some things. You just have to be very cautious about what you're putting in there, 'cause obviously dot env.dot.example is typically committed to your git repository. And so whatever you put in there is gonna be new git history forever. So you have to be careful that you like, didn't put the secret in the wrong file or whatever else, 'cause you don't wanna have to then roll those things, those credentials, if they do end up in GitHub for whatever reason. - Yep. - And then developers also have like for testing, you can have a dot env.testing on your local machine, and then Laravel will handle swapping that in when you run PS3 artisan test or whatever. Laravel will always look for a dot env file that matches whatever your configured app, underscore env is in the environment, and it will try and find a corresponding dot env.environment name. And then this is for like your machine-specific things. Like you might have a different username and password for the database, or you might have whatever configured there. You might have your own set of testing credentials for API endpoints and things like that, where you want to be able to run those things locally. So that will then use, and that will then build off your local dot env, dot env.testing, will override those values in a test situation. Is that how it works? Is that, if you have dot env.testing, does that override your dot env? Like your local dot env? Is that what it is? - I am pretty sure. - Is it okay? - 'Cause we only say, I only set in the dot env.testing the things that I know I need to change in my environment. - I'm pretty sure I need to look that up. - Only override dot env values. That's what I'm curious about that, actually. I don't know that to be true, but I am curious about that. - I could be wrong, but that's how I've got it set up, so. - Yeah, yeah, no, that's good. So, man, there's just a lot of different sort of, so here's the situation, right? I'm trying to teach, I'm a new developer today, a junior developer who's struggling with like, "Hey, these tests aren't passing." So why aren't they passing? Well, because the database can't get set up in CI, like the migrations won't run, and then if I can't get the migrations to run them, the tests fail, 'cause they're looking for a different database and it's like, okay, well, where do we set that stuff, right? So, trying to sort of standardize those things. And so, the conclusion that I had previously come to, maybe I can sort of share with you, right? So, if we're talking about layers, I suppose, anything that your doc or container or anything that your GitHub action would need to know about that is outside of the scope of your Laravel project, needs to be inside of the tests.yaml or that GitHub yaml file has to be. Now, if it's in there, and it's never gonna change, and it's not a secret, I'm okay with it being hard-coded for the most part, mostly. If it is a secret, it must reference a GitHub action secret, okay? So, there's top-top level. If there is a value that needs to be outside of the scope of your Laravel application, then it needs to be in that yaml file, okay? So, typically, how we set that up is at the very top, we're gonna be setting up our container, we're gonna be setting up MySQL, we're going to be naming whatever that database is going to be. And so, that's gonna be something we're gonna put in that yaml file. That's where we're gonna set some of that environment. The next step that we typically do is we're typically going to copy over some ENV. You can either just touch dot ENV or something like that, but then you don't have any keys, so you kinda need to copy over something, because the one thing that's pretty critical if you're gonna be testing is you have to generate a key for your application, right? You have to do PHP artisan key generate. So, you have to have something there that's waiting for your app key, you're also gonna need something like your app URL, that's gonna be pretty critical that you have that. So, you need to have some semblance of a ENV that's set up that you can then fill in with a app key, but also that probably has some default values that look like they make sense for your CI environment. So, what we've decided to do is say, dot ENV CI, sorry, dot ENV dot CI should include all the base environment variables needed for Laravel, right? Again, this is Laravel specific. So, now we're into the application, Laravel specific in order for the app to run in the GitHub action container. So, that's what lives in there. So, that's gonna be things like the database connection, that's gonna be things like the database name, the database user, the database password, the database port, if that's needed, that sort of stuff. And there might be some of those that are shared between the test dot yaml and that dot ENV dot CI, right? You might have to have like, for us, I know that when we use our test database name is typically like MySQL_testing is what we use, right? Now, I wanna make a distinction between this because dot ENV dot CI is what we would use in CI, but it might not necessarily be what you would use as a local developer for your own local testing stuff. So, we sort of allow you to decide that on your side, if you'd like to, but ENV dot CI is where we typically set up that stuff for the CI environment and it's going to be in sync with kind of what we would expect to be in our test dot yaml stuff. Then lastly, we have our, sorry, yes. Let me just say that right. I think I might have said some of that backwards. Okay, let me run that back real quick. Did I say our test dot yaml first? Is that what I said first? I think it's what I said first. Okay, so then last you have PHP_unit.xml. So this is anything that is just the overrides for running the tests, like our PHP_unit tests, right? So this would be typically shared between, honestly, probably when you're running tests locally, it's going to use PHP_unit.xml and when you're running tests in CI, it's going to use PHP_unit.xml. So like what you said, those things that will not change across any of the environments that just need to be set up, those be crypt rounds, something like the cache driver is going to be array. The database or the queue driver is probably going to be sync. The mail driver is probably going to be array or log, right? Those sorts of things. Those are what we would set up in our PHP_unit.xml. So I've got it all written up for our developers to say like, here's kind of how it should work and here's an example of each, but it's still a bit tricky, right? And so we're sort of on this path to try and standardize this across the different repositories, but it's just difficult. It's difficult to make it happen. There's just a lot of, you know, that YAML file is so large so many times and it's hard to just keep those things all in sync. And so we're trying to just standardize that and give at least new people an idea of like, here are the places you could put this and here's generally where, you know, what each one of these is responsible for. Does anybody else out there who has come up with a better solution for this or a better sort of heuristic? And like, hey, here's where each one of them go, I'd be happy to hear it. But that's kind of where we're at at this point. I like the idea of the one password stuff. For your one password stuff, are those one password environment variables also used for your developers in their local development environment? - We're not, but they can be. So the way that that works is you can like inject an environment kind of thing. So you can say inject dev or whatever, which references a vault in one password. - Sure. - And then you give developers access to that specific vault. And then they can just use like OP colon slash slash local dev slash whatever the then item is. And then you can grab this thing. - Does that actually go in your .env? Is that what it's like a URL that goes in there? - Yeah. - In your .env file. Interesting. - Yeah. So that way, you can, you've essentially just put all of those, all of those things into the one password file, into the .env file, and you can mirror all of that directly in there. And so when you hydrate it, is the one password CLI, you pass it like the name of what that vault is. And so you authenticate using all of the one password stuff. And then when you spin up your local environment for your app, you can just run OP, whatever it is, local dev. And then it will pull all those values out. It'll put them in-- - For your password something to say like, yeah, I'm gonna-- - Yeah. But it will replace them in that file. And then you write that output of that file to your .env.local. So the .env.whatever file. So basically you just commit .env.op, for example, into your Git repository. And that has all the op colon slash slash URL references in there. And so that just goes into CI. And that way you blow away .env, blow away .env.CI.env.testing, whatever. And then you give all of these things access to the one, like the relevant one password vault. And that way you can just spin it up. So you do like OP, whatever, and then you can give it a target, like an output, and it would just put into .env, for example. And then it will have all of those values swapped out for whatever they actually are. So now I want to actually-- - Based on what the environment is that you're running. - Yeah. - Based on the environment which corresponds to the vault that those credentials are then stored in inside of one password. - Well, that's really freaking cool. And so in your continuous integration environment, it does the same thing. It just runs that CLI script, and then it replaces those, and then writes that output file. In CI, we don't. Just because we don't expose those things into GitHub actions. So those things just use GitHub secrets, but in all of our production environment, our staging environment, our QA environment, our like our ephemeral review environments, they're all hooked up. And so they're all done that way. And that way also with like a Kubernetes, like in production, we can go into one password if we need to update an .env file. And we've got like a watcher in there that basically goes every two minutes, has anything changed if it does. It will repopulate the .env file or the environment, and it will then restart the containers so that it picks up the new environment. - That's interesting. We, I will say I have benefited greatly from being able to have cached .env values that don't change unless I redeploy. So sometimes I'll know a PRS coming and I'll have new .env values that I know we're going to have to go in, that baby aren't even replacing old ones, or sometimes, I mean sometimes it's replacing old ones or updating them, and I know I can change it with like total impunity until it gets deployed again and it doesn't matter at all because the values are cached. And so it doesn't make any difference. And I have to be the one to manually tell it, nope, redeploy, clear the cache, clear the configs, and it will then, you know, only at that point will it re-decide what those values are. - And we used to do it like that, we used to do it like that, but our deploy process is pretty heavy and it takes 10, 15 minutes. So if you need a change in environment variable, like you want to be able to do that fairly quickly, if you're going to toggle each or off or something, like you want to flick the kill switch, then you want to be able to do that basically instantaneously. It's a two minutes better than 10, 15. - Yeah, I agree with that. My question on that is when it runs out, it replaces your .env values. And then does it run the cache config cache again, or does it clear the cache and re-cache it? - Yeah. - And then do you have to be like a FPM restart in order to do that, or you're saying it just... - I don't know. We delegated all of the Kubernetes set up to stew it. So, I just got told that if I need to update an env value, I can just change it in one password and wait a couple of minutes. - That's really nice. I will say, I feel like I used to be able to do that, but I can't do that anymore. Like I couldn't do that anymore. So anytime I change an env value, even if I re-cache the config, it doesn't matter. It's like my front-end, my actual application doesn't react to it unless I restart FPM. Once I restart FPM, then it will work. But restarting FPM drops all the open connections and stuff, which sucks. You're probably using op-cache, I would assume in production. And if you're using op-cache, then it will hold onto all of that stuff until you reload. - That makes sense. - FPM, yeah. - Yeah, that makes sense. - The benefit from the way it's been deployed because it will do the config cache, but until you then restart FPM, it will pick up those changes. - I've thrown a recipe together in Forge that I can just say like run this for this particular site and it'll just do it. It will re-cache the config and then it will restart FPM for that particular site and then we should, then we're good. But it's just, yeah, it's what we have to do. We can't just change the unity. We have to do that. - I mean, this is just so, so many different ways. You know, obviously, Forge is really good in providing a really quick and easy one click for the most part, way to get up and running for a lot of lowerable applications. But as you start to scale or you have more things or you need to consider more intricacies of your own applications, it can then mean that, okay, maybe Forge isn't the tool for you. And like, Forge will take you a long way in a lot of situations. And for a lot of people, you know, a load balancing in front of one or two nodes and just scaling horizontally, that way is probably enough because we wanted to kind of spin up these ephemeral environments really easily and, you know, spin them up and tear them down and have reproducible environments for our other, you know, other parts of the business being able to have an environment that they could test against. It was just easier to put all of this stuff into Kubernetes and then deploy running it on EKS and things like that. So it's all controlled. And then all of the platform itself is managed by the operating, yeah, no, not even, like, sure. So we, my team, is responsible for the application and how that's deployed and all of that. But we have like an infrastructure or a systems team that is responsible for the actual EKS environment. And so they keep all of the security stuff up to date for us. We just deployed to the environment and it's all nicely separated out and, you know, compliance is a big piece as well. So, yeah, I got to look to see, we use, we use something other than one password, but I feel like when we were first signing on to this, there was this idea of, you know, CLI tool that would allow you to pull that stuff from there. But I don't know if it's quite as good as one password's integration. I know we had talked about using that at one point, but never, never fully made it there. It's one of those things where it's like, you know, it's hard to find the time to slow down and stop working on features to work on some of this infrastructure stuff. I feel like we're getting there, though, to the point where it's like, okay, I really need to have somebody take the time to do this because the developer experience is really important on these things. Like there's one application in specific, you know exactly what I'm talking about. That's really freaking hard to get set up correctly. The ENV is just, it's a beast, right? And it's some of the things that are up there don't have like great testing environments. Like there are no free sandboxes for it. Like we don't typically get to use services that are like Stripe, you know what I mean? We have, you know, some crusty XML thing that we have to use. And it's like, if we're using, you know, Twilio even doesn't necessarily have a great sandbox stuff. I mean, it sort of does, but not totally. It's not like a... - Yeah. - I don't know. - It's hard to simulate sending an SMS or making a phone call. - Correct, correct, exactly. You just kind of have to actually do it. And so, you know, it's hesitant to give that stuff to people who aren't me because not that I'm the only one who can't make a mistake, I certainly have made my share. I just don't ever want somebody else to be responsible for me giving them something and then screwing it up because it's like, that's my fault. - Yeah. - So anyway, as a real adult, I just don't give it to them. - Yeah, and this is the tricky thing as well, right? If you've like, you said this environment up on your machine five years ago, whatever. And, you know, it works and you've like added stuff to it and whatever, and it's, you don't often go back to the very beginning and create those things. And so, you don't hit the pain points of someone who is new to the approach work. Like, when I, you know, when I did some contract work for you a couple of years ago, it was like, okay, how do I actually get this up and running? All this stuff is here, but it's like incomplete or it's missing something or whatever else. So, you know, it's, it's unfortunately often falls on the lap of the new person to, you know, fix those things up and get it into a state where it can be done. And it's like, when Stewart came on, his first job was to containerize the application and get that all moved across. And so, you know, that's, that's what he did. And that's why, you know, we were in a position to have that all set up now as we had someone that knew what they were doing that got it all up and running, and so now, it's hard. - And Kubernetes, you know, it's just, right? It's just like, you don't have to do again. - And it, you know, it was like a four or five month project to go from like nothing to, okay, let's get our staging environment over there. Let's get a QA environment over there. Let's work on these ephemeral review environments. Let's cut one tenant across to this in production and just keep an eye on it to make sure everything's behaving. So, it did afford us the ability to get on PHP 8.3. Like we had an 8.3 container running a production for a few weeks after having staging environment running on PHP 8.3 for, you know, a month or two before that so that when we actually decided, okay, we're gonna update all of the dependencies. We're gonna set a minimum PHP of 8.3. We're gonna, you know, ship that auto production. We knew fairly reliably the application was gonna continue working because we had been running all of this stuff in PHP 8.3 for two, three months beforehand, which was really handy as well, so. - Absolutely, that's pretty cool. Yeah, so that's what we're working on. The next time that we're together, maybe we can talk about, oh boy, now I'm gonna forget what it was. - It's gone. - Nope, lost it, it's gone. Yeah, I will come back, I will remember it next time, but yeah, there was the ENVs, and then I totally forgot, lost it. It'll come back to me later. I'm positive. - Too much good chat about-- - Too much good chat. Yeah, too much of that good stuff. So anyway, I feel like I'm not even necessarily closer to a solution than what it was when we first started. I've discussed it, I've got it written up in a wiki, so that they kind of have an idea, but the interesting thing to me is that.env.local, so do you guys, do you ever even have a.env setup? Or do you, when you're on your local machine, like working in your local development environment, do you just do.env.local? - On my local machine, I think I've just got a.env, yeah. - Yeah, just.env.local, but the.env.local, yeah. But the.env.local is what's written up by one path. - On my local machine, I have a.env, yeah. - Okay, okay. But like when one password runs, does it copy all the secrets to a.env.local? Or just do your.env? - That's the intent, yeah. That's the intent, is that your.env, well, yeah, so we're not, so we can do that. We're not at the moment, so we've got a.env.review, which in our review environments gets populated and created locally, we're still world west. It's, you know, I need to work with this new thing. It's not working. Oh, I need to go and find out where the credentials are for this thing. You know, it's. - Okay, good. - Especially as the, as the team grows, you know, and one person works on some integration and they've got the keys that they developed with for this new party service and it's like, okay, this now goes into CI. But the next person that pulls down the project, they're like, oh, I don't have these environment variables and this part of the application doesn't work. So, you know, as you get into a bigger team, you've got to figure out how to share those credentials. So, yeah, one password is certainly the way we haven't gone. As I said, all the way to doing that for all the environments, but it is how it would be done using that same concept. And then I think one password put out a blog, you know, I think we've talked about this before, like a year ago or a year and a half ago where it says, you know, remove, remove your secrets store.env in Git and that's how you would do it. You would reference all of these vaults and the items and their keys in theenv file. And then there's never a concern that you're gonna, you know, commit a secret because the secret just doesn't exist in those files anymore. Because that then becomes the policy of the team. We only ever put a reference to something in there. We never put an actual value in there, so. - If you wanted to get a sponsorship for Larecon Australia, you should do a little article or a little video on how to set up one password with your GitHub stuff. And then you should reach out one password or talk to Jeffrey Way. Be like, hey, there's a lot of pain when we're talking about managing ENVs. How do you manage them locally? How do you share secrets with a team? What are you doing in your CI environment? What should you do? You know what I mean? How should you do that? And then you should pitch that to Jeffrey. Be like, I've got a five episode series that I would love to talk about managing your ENVs among a team. Yeah, you should do that. After they're kind of you maybe. Or maybe before they're kind of you, you tell one password, hey, we're really interested in talking about this. This is how we're doing it. We're currently using one password. We'd love to have you sponsor the conference. I can talk about it from this stage. - That'd be good. Yeah, agile bits to sponsor the conference. That'd be nice. - That would be cool. - Mm, lots of stuff on the go. All of our, our schedule's out now. - And nice. - We published all of the top topics we get. We haven't published the names and the topics together. We've published the topics and the speakers are doing their, they're fun to re-intro videos at the moment. So we're putting out two weeks over the next six, eight weeks or so as they all come out and they'll introduce themselves and their own topics. And we've got some, we've got some really fun ones this year as well, which is good. - That's fun. The site is looking really nice. - Yeah, it's going well. I need to fix up the contrast of the, yeah. I have to fix up the contrast of the schedule. We've got a bit of blue and blue that is not legible. Which I, like, I didn't even think about it because like it looked okay to me and it was within like everything else it fit. So, terrorist bang on the dog. Excuse me. - Oh, it's hilarious. - Yeah, so I got to get that fixed up but we're, you know, into the design of conference bags and we've got the proof for the conference t-shirts and we've got a little, little monkey here just got back from Kindergib. And yeah, so all that's happening at the moment. We're into the last sort of three and a bit-ish weeks of early bird sales, so all going well there. So, it's looking really nice, dude. The site looks awesome. - I'm very excited. - Yeah. Going well. Going well. - Very good, my friend. Well, I can tell your kids are home. You probably need to go say hi. Give that little one a hug and squeeze. Yeah, absolutely. So I can let you go, man. Hey, folks, thanks so much for hanging out with us. Michael, what episode is this one? What one? - I'm 60. - 160, folks. Find shown us for this episode at NorthmeadeSouth.org/160. Hit us up on Twitter @jigobenat. Michael, we're going to add North-South audio. Great to be a pride catcher of choice. Five shots will be amazing. See you next time, folks. Two weeks. Later. - Bye. (upbeat music) (upbeat music) (upbeat music) (upbeat music) (upbeat music)