Latest / North Meets South Web Podcast / The one with environment config

Transcript

The one with environment config · North Meets South Web Podcast

• 0:00
  Michael: Go go. This is Michael Dyrynda.
• 0:02
  Jake: And this is Jake. Oh, hold on. And this is Jake Bennett.
• 0:06
  Michael: And welcome to episode 160 of the North Meet South Web Podcast.
• 0:12
  Jake: I have to get paper towel because I just literally spilled bubbly tint on my laptop.
• 0:16
  Michael: I did the same thing. I picked up my 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 splooshed everywhere. So fortunately, it was on the desk out on the on the dining table, so I can deal with that later.
• 0:35
  Jake: 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.
• 0:44
  Michael: I think I think we're okay. I think we're okay.
• 0:47
  Jake: Yep. You just needed to have a captain cook at your microphone there.
• 0:51
  Michael: A captain cook.
• 0:54
  Jake: In Aussie slang, that means have a look or brief inspection apparently.
• 1:01
  Michael: I listened I listened to the latest It's a
• 1:03
  Jake: good thing I'm a true blue.
• 1:05
  Michael: Oh, true blue. Loyal friend. Yeah. That's right. I, I was listening to the latest Business of Laravel podcast, and friend of the show, Greg Skirmen, was on with Matt Scarpa this episode Of course.
• 1:17
  And and they ended up talking a bit about Aussie slang, and and, Matt had mentioned that on the in the Aragon AU speaker chat, you know, it it doesn't occur to us as Aussies that people observing from outside of Australia don't understand some of the lingo and and Mhmm.
• 1:37
  Jake: And
• 1:37
  Michael: vice versa. So yeah.
• 1:39
  Jake: Yeah. People have heard the story, I think, of the time that I was, like, on we were we were chatting and you had to go get a delivery at the door. Mhmm. And I I was still in your ear because I could hear the AirPods. You were, like, hooked up on AirPods, and I was in on an Aussie to Aussie conversation, and it was a different type of language than you you you and I have ever spoken.
• 2:02
  Michael: Yes.
• 2:02
  Jake: Didn't understand most of it and, that was
• 2:05
  Michael: You could certainly be left behind. I'm I'm gonna I'll send you this, is it this video that I just saw the other day? No. Not this one. I there was a video that, Marty Friedel, I think, shared with the with the chat talking about oh, no.
• 2:24
  Sorry. It was Simon. It was Simon Vashlow that shared a I'll have to put the a link to this in the in the show notes if I can find the original video, but it was basically one side of a conversation, like a phone conversation between 2 Aussies and 2 Aussie men specifically. It's, it's a good one. It's a lot of yeah, yeah, nah, nah, oh, yeah, yeah, nah, alright, yeah, okay, yeah, yeah, Nah.
• 2:47
  Yeah. Of course. Very
• 2:50
  Jake: Alright. So I'm gonna I'm gonna quiz you on some Australian slang here.
• 2:54
  Michael: Okay? Here we go. So you can tell me you can tell me what
• 2:56
  Jake: the meaning is. Carrying on like a pork chop means what?
• 3:01
  Michael: Means, like, you know, just being crazy, doing all kinds of weird things, just acting
• 3:07
  Jake: Acting unreasonable. I'll I'll count that. Yep. A grommet.
• 3:12
  Michael: A grommet?
• 3:13
  Jake: No. Grommet. No. It says says a young surfer is a grommet.
• 3:18
  Michael: A young surfer. Okay. Well, I never Okay. Never got into surfing culture, so that makes sense, though. Alright.
• 3:25
  Jake: Whoop whoop. Like, I'm driving in the whoop whoop.
• 3:27
  Michael: You you're driving into whoop whoop. It's, going into the middle of nowhere. Yeah.
• 3:32
  Jake: Okay. Whoop whoop, not whoop whoop, whoop whoop.
• 3:34
  Michael: Not whoop whoop. No. Whoop whoop in the middle of nowhere.
• 3:38
  Jake: How did that one come about? What's whoop whoop? What is that? Is it just don't know?
• 3:42
  Michael: It's usually like dingo usually dingo whoop whoop, and I don't know why dingo, but it's like, it just just means it's a far distance from anything. The 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.
• 4:03
  Jake: Whoop whoop.
• 4:04
  Michael: There it is.
• 4:05
  Jake: Okay. Mates rate.
• 4:07
  Michael: Mates rate? It's, you know, you look after your mates, you give them a a good deal. Good good price.
• 4:12
  Jake: Good discount. A friend's discount. Okay. Have a captain cook.
• 4:15
  Michael: Have a captain cook? Which you you got me Yeah.
• 4:18
  Jake: Do you know
• 4:19
  Michael: this one? Haven't I'd I
• 4:22
  Jake: It says have a look or brief inspections to have a
• 4:24
  Michael: To have a look around, like, contextually, yeah, I I get it. I, like, I feel like it's something that maybe I've heard once or twice, but it's it's not common. And so, you know, it's not not common vernacular for for men's.
• 4:37
  Jake: I've got I've got 2 2 left for you. A 2 pot screamer.
• 4:43
  Michael: Two pot screamer?
• 4:45
  Jake: A 2 pot screamer. That guy's a 2 pot screamer. Nah. Someone who can't hold their liquor.
• 4:52
  Michael: Someone who can't. We've,
• 4:57
  Jake: yeah. I was curious about that if you had actually
• 4:59
  Michael: heard that before. I've never heard Tubot Screamer. Cadbury is one that we've we've Cadbury? That I use often. Is your someone's a Cadbury, they're a glass and a half.
• 5:08
  Jake: Oh, okay. Okay.
• 5:10
  Michael: It takes them a glass and a half to get drunk.
• 5:12
  Jake: Okay.
• 5:13
  Michael: And there's another one that I can't it's on the I can't can't can't can't grasp it, but there is another one.
• 5:19
  Jake: Alright. I remember you telling me Whispers. Whispers is a good one.
• 5:22
  Michael: Whispers. That's right.
• 5:23
  Jake: The guy who never saw it. If you shout, it's like if you shout that's like you're getting you're picking up the the round of drinks.
• 5:29
  Michael: Tap the wrap. Yep.
• 5:30
  Jake: And the guy and the guy who never does that is called whispers. So that's That
• 5:33
  Michael: whispers never shouts. That's right.
• 5:34
  Jake: Whisper never shouts. Okay. Last one is have a roux loose in the top paddock.
• 5:39
  Michael: Have a roux, like, being, like, 10¢ short of the dollar. Being a bit
• 5:42
  Jake: Yeah. Exactly.
• 5:43
  Michael: Not not not smart.
• 5:45
  Jake: Not the sharpest tool in the shed. Yeah. Not the, brightest crown on the box.
• 5:49
  Michael: The brightest crown. That's right.
• 5:50
  Jake: Yep. Yep. I've been using, I've been so speaking of my dog, I've been saying he's dumb as a box of rocks. I like that one.
• 5:57
  Michael: Dumb as a box of rocks.
• 5:58
  Jake: Yeah. Dumb as a box of rocks. Hot dog. Dumb as a box of rocks. He's been I don't know.
• 6:03
  I don't really wanna 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.
• 6:09
  Michael: I feel like we've had this. Yeah. I think
• 6:11
  Jake: We we have 4 chickens now, and my son wants to get chicken collars so we can take them to soccer games here when the soccer season starts. Yep. Walk the chickens. Chicken leashes. It's ridiculous.
• 6:22
  Michael: Are they hens? You get an eggs out of them or what?
• 6:25
  Jake: Yes. You can yes. They you can only get hens here in town. And so, yeah, we had to get hens, but, yeah, they're they're good. They're fun.
• 6:33
  They're really funny, actually. You let them out and they just kinda roam around the yard and Roam around? Yep. It's it's funny to watch them. They always stay together.
• 6:40
  There's there's 4 of them and they just kinda always hang out together and they're scratching and packing 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
• 6:54
  Michael: about We had 5 bad ways. Yeah.
• 6:56
  Jake: Oh, man. Well, at least. Remember when we used to do spin drift? Every use we used to spin drift all the time?
• 7:00
  Michael: That's right. We tried to
• 7:02
  Jake: Not that it's a competition, Aaron, because it definitely is not. Yeah. I did try and get a sponsor of Spindrift back in the day.
• 7:07
  Michael: Don't
• 7:07
  Jake: He started with the best.
• 7:08
  Michael: Bathe with Aaron.
• 7:10
  Jake: No. No. No. Aaron started with the best. I gotta say that.
• 7:12
  That lemon Spindrift 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?
• 7:22
  Michael: Bubbler.
• 7:23
  Jake: Yeah. It's pretty good actually. This is triple berry breezer bubbler. Pretty good.
• 7:27
  Michael: Alright. I I did actually have a mineral water earlier. It's made with wonky fruit, and if I can find Dash Water is is the name
• 7:37
  Jake: of it.
• 7:37
  Michael: So they make it with wonky fruit, which is, you know, like, you go to the supermarket and you and you buy fruit, or you go to the greengrocer and you buy fruit. And it's like, the good stuff goes there because 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 farmers market Gotcha.
• 7:54
  Jake: Yeah. Yeah.
• 7:54
  Michael: Or in in the instance of, dash water, they they make wonky fruit. They use the wonky fruit to to make their mineral water. So I had, I don't know what it was. It was a raspberry? Raspberry is one.
• 8:08
  Yes. Sparkling water infused with wonky was raspberries. Very nice. Okay. It's it it's definitely definitely more than a a passing I don't remember the exact phrasing Aaron used, but, like, you know, it looks like, it's like someone shouted the the name of the fruit from the other room is the only connection
• 8:26
  Jake: that we've
• 8:26
  Michael: ever get. So
• 8:27
  Jake: Okay.
• 8:28
  Michael: Yeah. This this one was okay.
• 8:30
  Jake: 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. And maybe we can just keep this episode focused on 1. I don't know.
• 8:39
  Maybe. We've tried. 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 2 things that we could talk about. Let's talk about the 1, and then if we have You
• 8:51
  Michael: wanna you wanna stay on track and in thinking about the first topic, you've already thought of the second one.
• 8:57
  Jake: Yep. Well, I know what it is. I know what the okay.
• 8:59
  Michael: So here it
• 8:59
  Jake: 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.
• 9:11
  Right? So that typically is in your dot GitHub directory, and inside of there you'll have some sort of YAML file. Maybe we call it tests dot 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 you're going to it's going to pull down, you know, all your dependencies.
• 9:37
  It's going to then 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 the meaty bit, and here's here's where it is.
• 9:55
  What do you do with ENVs? Now there's about 3 different places you could place these ENVs. And so the question for me is where do you place each and what is your your heuristic for determining what goes where. So let me give you some options for where you can put e and v values. You can put them straight in your YAML file.
• 10:16
  So in your test dot YAML, you can actually define for each of the different actions that you're going to 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. It doesn't necessarily have to be Laravel. It could be like you're migrating. I guess, in that case, you would be migrating your database.
• 10:38
  It could be that sort of stuff. Right? You could set those ENVs directly on that. You could also put them in like a dotenv.example file that you copy over or a dotenv.ci file that you copy over out of your thing. You can copy that to the ENV Or in the case of PHPUnit, you have something specialized for that like PHPUnit dot XML, which you can also override by the way with ENVs that you set specifically on that PHPUnit actions.
• 11:05
  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 I'm gonna I'm gonna clarify one more time.
• 11:18
  Here are the 3 options that you have, and I will I'm I'm even sort of I feel like giving you a little bit of a leg up because these are the places I've I've decided to put them. GitHub actions has a place where you can put secrets in a repo. Mhmm. Let's narrow it down to a dotenv.ci file. We can talk about why that would be later, but dotenv.ci and PHPUnit.XML.
• 11:38
  Okay. Those are the options. Let me hear your thoughts.
• 11:41
  Michael: Alright. So it may or may not shock you to know that we actually use all of them.
• 11:48
  Jake: We do too. No. We do too.
• 11:50
  Michael: In different situations. Mhmm. Mhmm. So the PHP unit dot
• 11:56
  Jake: XML file.
• 11:57
  Michael: It is. Yeah. Yeah. The, the PHP unit dot 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, you know, on another machine, these are the things that we don't want to change.
• 12:19
  Things like And you put that in
• 12:20
  Jake: which file?
• 12:22
  Michael: Into the PHPUnit.xml. Ml.
• 12:23
  Jake: Okay. PHPUnit.xml. I'm just gonna write this down for myself because I'm interested here. PHPUnit.xml.
• 12:29
  Michael: Yep. So these are specific values that we don't want to change where they're running. Things like bcrypt rounds, log channel, cache driver, qknet, like, that kind of stuff that we want to always be the same everywhere. That goes in the PHPUnit. XML.
• 12:45
  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 paren paren or brackets brackets no, brace brace, secrets dot and whatever and so we map those 1 to 1. 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 testing 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 .env.ci but we use this for our review environments.
• 13:44
  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 1Password URLs in our dotenv. Review. And so we will just run that through 1Password's hydrate or fill or whatever 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.
• 14:21
  So yeah, all 3 of them. .Env. Example we will put some things, you just have to be very cautious about what you're putting in there because obviously .env. Example is typically committed to your git repository and so whatever you put in there is going to be in your git history forever. So you have to be careful that you like didn't put the secret in the wrong file or whatever else because you don't have to then roll those things, those credentials, if if they do end up in GitHub for whatever reason.
• 14:55
  Jake: Yep.
• 14:57
  Michael: And then developers also have like, for testing, you can have a dotenv dot testing on your local machine, and then Laravel will handle swapping that in when you run PHP artisan test or whatever. Laravel will always look for a dotenv file that matches whatever your configured app_env is in the environment, and it will try and find find a corresponding dotenv dot 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, you know, whatever configured there. You might have your own set of testing credentials for API endpoints and things like that, where where you want to know, be able to run those things locally.
• 15:46
  So that will then use and that will then build off your, you know, your local dotenv.env.testing will override those values in a test test situation.
• 15:54
  Jake: Is that is that how it works? Is that it's like if you have dotenv.testing, does that override your doten, like, your local dotenv? Is that what it is? So, like, you will use your dot is it? Okay.
• 16:06
  Michael: Because we only say I only say in the dotenv dot testing the things that I know I need to change in my environment. I'm pretty sure I need
• 16:16
  Jake: to look that up. Only override dotenvvalues. That's not I'm curious about that actually. I don't know that to be true, but I am curious
• 16:26
  Michael: about that. I could be wrong, but I'm that's how I've got
• 16:28
  Jake: it set up. So Yeah. Yeah. No. That's that's good.
• 16:32
  So, man, there's just a lot of different sort of so here's the situation. Right? I'm trying to teach the new developer today, a junior developer who's struggling with, like, hey. These tests aren't passing. So why aren't they passing?
• 16:49
  Well, because the database can't get set up in CI. Like, the migrations won't run, and then with my if I can get the migrations to run, then the tests fail because they're looking for a different database, and it's like, okay. Well, where do we set that stuff? Right? So I'm trying to sort of standardize those things.
• 17:06
  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 Docker 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 dot 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.
• 17:38
  Mhmm. 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.
• 17:54
  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, you know, 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 sort of that some some of that environment.
• 18:10
  The next step that we typically do is we're typically go typically going to copy over some e n v. You you can either just like dot you can either touch dotenv 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. Yeah. Right?
• 18:32
  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 like 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.
• 18:54
  So what we've decided to do is say dotenvci sorry dotenv.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.
• 19:26
  And there might be some of those that are shared between the test dot yaml and that dotenv.ci. Right? You might have to have like for us, I know that when we use, our our test database name is typically like MySQL underscore testing is what we use. Right? Now I wanna make a distinction between this because dotenv.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.
• 19:51
  So we sort of allow you to decide that on your side, if you'd like to, but env.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 p, sorry. Yes. Let me just say that right. I think I might have said some of that backwards.
• 20:21
  Okay. Let me let me run that back real quick. Did I say did I say our test dot yammer first? Is Is that what I said first? I think that's what I said first.
• 20:27
  Okay. So then last, you have PHPUnit.XML. So this is anything that is just the overrides for running the tests, like our PHPUnit tests. Mhmm. Right?
• 20:36
  So, this would be typically shared between, honestly, probably your your obviously, when you're running tests locally, it's gonna use PHPUnit dot XML, and when you're running tests in CI, it's gonna use PHPUnit XML. So like what you said, those things that will not change across any of the environments that just need to be set up, right, those bcrypt rounds, you know, some of the like the cache driver is gonna be array. The database or the queue driver is probably gonna be sync. The mail driver is probably gonna be array or log. Right?
• 21:07
  Those sorts of things. Those are what we would set up in our PHPUnitDocsML. So I've got it all written up for our developers to say, like, hey. Here's here's kind of how it should work and here's an example of each, but it's still a bit tricky. Right?
• 21:23
  And so we're sort of on this path to try and standardize this across the different 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. Mhmm.
• 21:58
  If there's 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 1 password stuff. For your 1 password stuff, are those those 1 password, environment variables also used for your developers in their local development environment?
• 22:19
  Michael: We're 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 1 password. Sure. And then you give developers access to that specific vault, and then they can just use like opcolon/ local dev/ whatever the the then item is, and then you Now is that
• 22:47
  Jake: does that actually go in your dotenv? Is that what it's like a URL that goes in there? In your dotenv file? Interesting.
• 22:52
  Michael: Yeah. So that way you can you so essentially, you just put all of those all of those things into the 1Password file, into the dotenv file, and you commit all of that directly in there. And so when you hydrate it, there's the the one password CLI. You pass it, like, the name of what that vault is. And so you authenticate using all of the the 1Password stuff.
• 23:17
  And then when you spin up your local environment for your app, you can just run o p whatever it is, local dev, and then it will pull all those values out. It'll
• 23:29
  Jake: Like prompt for
• 23:30
  Michael: the password
• 23:30
  Jake: or something to
• 23:31
  Michael: say, like,
• 23:31
  Jake: I'm gonna
• 23:32
  Michael: Yeah. But it will replace them in that file, and then you write that the output of that file to your dotenv dot local. So be dot So the dotenv dot whatever file So basically you just commit .env.op, for example, into into your git repository. And that has all the opcolon /URL references in there.
• 24:01
  Jake: Mhmm.
• 24:02
  Michael: And so that just goes into ci. And that way, you blow away dotenv, you blow away dotenv.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 it into dot.env, for example, and then it will have all of those values swapped out for whatever they actually are.
• 24:28
  So no one actually needs to know.
• 24:30
  Jake: That you're running.
• 24:31
  Michael: Yeah. Based on the environment which corresponds to the to the vault that those credentials are then stored in inside of 1 password.
• 24:38
  Jake: Well, that's really freaking cool. And so in your continuous integration development or environment, it does the same thing. It runs that CLI script and then it does it replaces those and then writes that output file.
• 24:49
  Michael: In CI, we don't. Just because we don't expose those things into, into GitHub actions. So those things just use GitHub secrets. But in order, like 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 they're all done that way.
• 25:11
  And that way also with, like, our Kubernetes, like, in production, we can go into 1 password if we need to update an ENV file. And we've got, like, a watcher in there that basically goes, every 2 minutes, has anything changed? If it does, it will repopulate the ENV file or the environment, and it will then, restart the the containers so that it picks up the new environment.
• 25:33
  Jake: That's interesting. We I will say I have benefited greatly from being able to have cached EMV values that don't change unless I redeploy. So sometimes I'll know a PR is coming and I'll have new ENV values that I know are gonna have to go in that maybe aren't even replacing old ones or sometime I mean, sometimes it's replacing old ones, or updating them. And I know I can change it with, like, a 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.
• 26:03
  And I have to be the one to manually tell it, nope. Redeploy. Clear the cache. Clear the clear the configs, and it will then, you know, only at that point will it re, decide what those values are. So
• 26:15
  Michael: anyway, that's interesting. 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 to change an environment variable, like, you wanna be able to do that fairly quickly. If you wanna toggle the feature off or or something, like, you wanna, you know, flick the kill switch, then you wanna be able to do that basically instantaneously.
• 26:37
  So 2 minutes is better than 10:15.
• 26:39
  Jake: Yeah. I I agree with that. My my question on that is when it runs that, it replaces your dotenv values and then does it run the cache, you know, config cache again or does it clear the cache and re recache it?
• 26:52
  Michael: Yeah. And then do you have
• 26:53
  Jake: to do, like, a f p m restart in order to do that, or you're saying it
• 26:55
  Michael: just I don't know. We I we delegated all of the Kubernetes set up to Stewart. So
• 27:03
  Jake: Alright, Stewart.
• 27:03
  Michael: I just You need a lot of stuff. I just got I just got told that, if I need to update an ENV value, I can I can just change it in one password and wait a couple of minutes?
• 27:12
  Jake: That's really nice. I I will say, like, I was I've had I feel like I used to be able to do that, but I can't do it anymore. Like, I couldn't do that anymore. So anytime I change a ENV value, even if I recash the config, it doesn't matter. It's like my my front end my actual application doesn't react to it unless I restart FPM.
• 27:31
  Once I restart fpm then it will work. But restarting fpm Right. Because you're probably using like drops all the open yeah. It drops all the open connections and stuff which sucks.
• 27:39
  Michael: You're probably using, opcache, I would assume in production. And if you're using opcache, then it will hold on to all of that stuff until you reload
• 27:48
  Jake: That makes sense.
• 27:48
  Michael: Fpm. Yeah.
• 27:50
  Jake: Yeah. That makes sense. The benefits of the downfalls of our
• 27:54
  Michael: cache because it will it'll do the config cache, but until you then restart f m, it will pick up those changes.
• 28:00
  Jake: Yeah. 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'll recache the config, and then it will, you know, restart FPM for that particular site, and then we should then we're good. But Yeah. It's just, you know, it's what we have to do.
• 28:17
  We can't just change
• 28:18
  Michael: the e n d. We have
• 28:19
  Jake: to do that.
• 28:20
  Michael: So so many different ways. You know, obviously, 4 gs 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 Laravel 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 in a lot of situations, and for a lot of people you know a load balancing in front of 1 or 2 nodes and just scaling horizontally that way is spin them up and tear them down and and have reproducible environments for, spin them up and tear them down and 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 it running on, EKS and things like that.
• 29:22
  So it's all all controlled. And then all of the platform itself is managed by the Stewart. Operator. Yeah. No.
• 29:29
  Not even like Stewart. We so we, my team, is responsible for the application and how that's deployed and all of that, but we have an, 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 deploy to the environment, and and it's all nicely separated out and and, you know, compliant compliance is a big piece as well. So
• 29:59
  Jake: Yeah. I gotta look to see we use, we use something other than 1Password, but I feel like when we were first signing on to this, there was this idea of, you know, a CLI tool that would allow you to pull that stuff from there. But I don't know if it's quite as good as 1 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.
• 30:26
  Yeah.
• 30:27
  Michael: I feel
• 30:27
  Jake: 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 which one I'm talking about, that's really freaking hard to get set up correctly. The ENV is just it's a beast. Right?
• 30:44
  And it's, some of the things that are up there don't 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.
• 31:00
  And it's like if we're using Yeah. You know, Twilio even doesn't necessarily have a great sandbox stuff. I mean, like, sort of does, but not totally. It's not like a
• 31:10
  Michael: Yeah.
• 31:11
  Jake: I don't know.
• 31:12
  Michael: There's there's some stuff. Sending an SMS or making a phone call.
• 31:16
  Jake: Correct. Correct. Yeah. Exactly. You just kinda have to actually do it.
• 31:19
  And so, you know, it's it's I'm 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. Like Yeah. So anyway, as a result, I'll just don't give it to him, but then that
• 31:37
  Michael: makes it so important. The the tricky thing as well. Right? If you've, like, you set this environment up on your machine 5 years ago or whatever. And, you know, you it it works and you've, like, added stuff to it and whatever.
• 31:49
  And it's you don't often go back to the very beginning and recreate those things, and so you don't hit the pain points of someone who is new to the project. 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
• 32:23
  Jake: Yeah. It
• 32:23
  Michael: can be done. And that's like when Stewart came on, his first job was to containerize the application and get that all 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
• 32:40
  Jake: That pod and Kubernetes, you know, it's just set. Right? It's just like you don't have to do
• 32:43
  Michael: it again. But, you know, it was like a 4 or 5 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 in production for a few weeks after having staging environment running on PHP 8.3 for, you know, a month or 2 before that.
• 33:20
  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 all to production, we knew fairly reliably the application was going to continue working because we had been running all of this stuff in PHP 8.3 for 2, 3 months beforehand, which which was really handy as well. So
• 33:43
  Jake: Absolutely. That's pretty cool. Yeah. So that's something we're working on. The next time that we're together, maybe we can talk about oh, boy.
• 33:51
  Now I'm gonna forget what it was.
• 34:01
  Michael: It's gone.
• 34:01
  Jake: Nope. Lost it. It's gone. Yeah. I will come back.
• 34:04
  I will I will remember it next time, but, yeah. There was the e and v's and then, totally forgot. Lost it. It'll come back to me later. I'm positive.
• 34:13
  Michael: Too much good too much good chat about,
• 34:15
  Jake: the base. Yeah. Too much of that good stuff. So anyway, I I feel like I'm not even necessarily closer to a solution than what it was when we first started. I've discussed it.
• 34:23
  Like, I've got it written up in a wiki, so that they kinda have an idea. But the interesting thing to me is that dotenv.local. So do you guys like, do you ever even have a dotenv setup? Or do you when you're on your local machine, like, working your your local development environment, do you ever do you just do dotenv dot local?
• 34:42
  Michael: On my local the same. My local machine, I think I've just got it dotenv. Yeah. Yeah.
• 34:46
  Jake: Just dot dotenv.notd.env.local.
• 34:49
  Michael: Yep.
• 34:49
  Jake: But the dotenv.local is what's written
• 34:51
  Michael: on my local machine. Have a dotenv. Yeah.
• 34:54
  Jake: Okay. But, like, when one password runs, does it copy all the secrets to a dotenv dot local? Or just do your dotenv?
• 35:01
  Michael: The intent. Yeah. That's the intent. Is that your dot in, well, yeah. So we're not.
• 35:08
  So I said we can do that. We're not at the moment. So we've got a dotne.review, which in our review environments gets, populated and then and created. Locally, we're still Wild West. It's, you know, oh, I need to work with this new thing.
• 35:23
  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 this third party service.
• 35:35
  And it's like, okay. This now goes into CI. But the next person that pulls down the project, they're like, well, I don't have these environment variables, and this part of application doesn't work. So you know, as as you get into a bigger team, you've got to figure out how to share those credentials. So yeah, 1 password is certainly the way.
• 35:51
  We haven't gone, as I said, all the way to doing that for all the environments, but it is it is how it would be done using that that same concept. And then I think 1Password put out a 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 secret store dotenv in, in git. And and that's how you would do it. You would reference all of these vaults and the items and their keys in the e n f e file, and then there's 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's you know, that then becomes the policy of of the team.
• 36:34
  We only ever put a reference to something in there. We never put an actual value in there. So
• 36:40
  Jake: If you wanted to get a sponsorship for Laracon Australia, you should do a little article or a little video on how to set up 1 password with your GitHub stuff, and then you just reset 1 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?
• 36:57
  How do you share secrets with the team? What do you do in your CI environment? What should you do? You know what I mean? How should you do that?
• 37:03
  And then you should pitch that to Jeffrey. Be like, I've got a 5 episode series that I would love to talk about managing your ENVs among a team. Yeah. You should do that. After they're kinda you maybe.
• 37:13
  Or maybe before they're kinda you, you tell 1Password, hey, we're really interested in talking about this. This is how we're doing it. We're currently using 1Password. We'd love to have you sponsor the conference. Yeah.
• 37:23
  I can talk about it from the stage.
• 37:25
  Michael: That'd be good. Yeah. Agile bits to to sponsor the conference. That'd be nice.
• 37:28
  Jake: That would be cool.
• 37:31
  Michael: Lots of lots of stuff on the go. All of our our schedule's out now.
• 37:35
  Jake: Nice.
• 37:36
  Michael: We published all the Genoa topics. We we haven't published the names and the topics together. We've published the topics. And the speakers are doing their their final intro videos at the moment, so we're putting out 2 weeks over the next 6, 8 weeks or so. As they all come out and they'll introduce themselves and their own topics and and we've got some we've got some really fun ones this year as well.
• 38:00
  Jake: That's fun. The site is looking really nice.
• 38:02
  Michael: Yeah. It's going well. I need to fix up the, the contrast of the yeah. I have to fix up the contrast of the schedule. We've got a bit of blue on 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.
• 38:24
  So terrorist banging on the dog. Excuse me.
• 38:33
  Jake: Oh, it's hilarious.
• 38:35
  Michael: Yeah. So I I gotta 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 Kinder gym. And, yeah. So all that's happening at the moment. We're into the last sort of 3 and a bit ish weeks of early bird sales.
• 39:02
  So all all going going well there. So
• 39:07
  Jake: It's looking really nice too. The site looks awesome. Very excited.
• 39:09
  Michael: Yeah. Oh, well. Going well.
• 39:14
  Jake: 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 a squeeze. Yeah.
• 39:21
  Absolutely. So I can let you go, man. Hey, folks. Thanks so much for hanging out with us. Michael, what episode is this 1?
• 39:27
  Michael: What one? On 60.
• 39:28
  Jake: 160, folks. Find show notes for this episode at north meets south audio slash 160. Hit us up on twitter atjacobenn@michaelreda@northsouthaudio. Ready to be a podcaster of choice. 5 stars would be amazing.
• 39:38
  See you next time, folks. 2 weeks. Later. Bye.