GitHub Secrets & Deployment

[00:00:00]
>> Brian Holt: OK. New repository secret. Who wants to copy and paste a bunch of stuff? I'm going to reuse the same ones that we used from Vercel, but in theory you probably want a third set of services just for test. So you would have one just for production, one for just for test, one for just for preview environments. Generally you keep your environments separate.

[00:00:25]
The less you mix them, the better, and if you're at a company that makes a bunch of money, you usually don't care about an extra $200 worth of infrastructure. I imagine you and I both care about $200 a month, so that is up to you. So, it's more or less what we're going to get out of here. We already set this up once, so let's just go ahead and get these out of here.

[00:00:48]
We are going to copy that. I'm going to close a bunch of these just to make this easier for me. We'll keep Neon open. No, I have it opening over here so we're just going to close that as well. All right, so this is blah, this is, this was this one. Next, project ID, add secret. OK, and we have to do this every single time for each one of these, which is quite annoying, I understand.

[00:01:30]
But in theory, you set this up once and you really don't have to do it again. New repository secret, that is that one, and we need to do Stack secret server. They don't have like a really nice pasting thing like Vercel does, which is just a shame because it's really nice to just paste the entire .env in there and it just works.

[00:02:02]
Yeah, and the other thing is we're not doing this by environment, we're doing this just at the repository level. If you wanted to have your GitHub build multiple environments, like, OK, I have to do one build and I'm going to build production and dev and test and staging and canary, and these all have different secrets, you set up an environment for this one, an environment for this one, and then each environment has its own tree of secrets, right?

[00:02:29]
We're not doing that today, we're keeping it pretty simple. But hopefully you can see it's the same process just repeated a bunch of times. I don't think anyone wanted to see me do this three times longer though. AI Gateway. This one you probably could, I'm trying to remember, I think you could just give it a fake key. But we won't.

[00:02:58]
We're just going to give everything. Resend key, this one, I know for a fact you can give this one a fake key. Blob, I'm going to reuse our pre-production one here. Blob base URL. You can tell I've done this before. Read write token for pre-production environments. Blah. And I need this one. Add secret, very good. Upstash, Redis REST URL.

[00:04:12]
And I need the secret for that. So certainly making these some of these variables would be good for debugability because you're not going to be able to see, like in the logs, which URL for Redis that we were hitting, for example. I can see that being helpful. These are all for production, so I'm going to skip that. And then Neon, I don't need to put anything because the Neon branch is going to get created on the fly.

[00:04:40]
What I do need to put in here is I need to go to Neon, click my account. Create a personal API key, this is for FEM Wiki Masters. And I'm going to copy and close. And I'm going to add a new secret here for Neon API key, like that, add secret. And I think, let's double check our action here. You got these three, that one, all right.

[00:05:17]
So I have the database URL or that will be created on the fly, rather. I have the three for Stack, I have the two for Upstash, I have a fake Resend key, I have the two for Blob. Oh, you do need to add project ID. Yes, you do need a project ID and we do need a test user email as well. So, let's go get a project ID from Neon, that's pretty easy to get.

[00:05:45]
Neon, we're going to go to the projects that you're on here. It's going to be like this thing up here. So that mine is rapid block up here. That's the one that you need. So, new repository secret, this is going to be Neon project ID and it'll be rapid block blah, right? This will tell us what to branch off of, right, that's how, why you need that.

[00:06:25]
Let me go. Did I use the same, so. Yeah, where is my FEM Wiki Masters? I need to make sure that that test credentials works OK. Sign in. 123 tester like that. Ah, test@example.com, blah. Nope. OK, so just make up a set of credentials then. So this will be test2@example.com. Maybe we'll call it like, whatever, I actually don't care.

[00:07:13]
Doesn't matter. Sign up. Right, now. Let's go in here to GitHub. We're going to new repository secret. This will be test user email will be test2@example.com. For anyone that doesn't know, you can send infinite email to example.com and it's OK. They're very, the people that own example.com are very OK that you use that as an example.

[00:07:42]
If you send it to bob@aol.com, poor Bob does not like that. So it is always OK to use example.com. We did test email, I think, test user email and then, did I do test user password as well? No. Test user password, blah, add secret. And then I, there was one more, right? No, whatever, you don't need that one, that one's fine. We did the Neon project.

[00:08:19]
I think we're ready. I think that's all the stuff that we need. OK. So let's try and let's go to our actions. The last one that like this failed. The nice thing now is that with GitHub, you can actually rerun jobs now, so I'm going to rerun, let's say all failed jobs. And let's see what happens. So this one, it did not rerun it because it had already run before successfully.

[00:08:51]
Our TypeScript checks should finish pretty quickly because the, oh. Nope, it's still mad about something here. OK, well, we'll have to go figure that out in a second. Oh, because I haven't pushed the correct path yet for the package lock. Well, let's see if unit test works, OK? We will see if all of our credentials worked out OK.

[00:09:32]
Nine tests pass. Deleting the Neon branch. And should be passed unit tests. Pretty cool. If we're being super honest, I had a couple of job opportunities when I left my last job, and it was this workflow of like creating a branch, running a bunch of tests on it, and then deleting it afterwards, that I was like, this is pretty cool.

[00:09:55]
I kind of want to work on this, right? So, end-to-end tests here, these take a decent amount longer, particularly because it goes and grabs a full Chromium instance, right, to run the end-to-end test on every single time. But that's, in fact, that's you can see that's still what it's doing. So, most of the time is spent installing Playwright browsers.

[00:10:39]
Let's get status here. Get this, this should really just be the one thing, right? Yeah, whatever, it fixed a bunch of double quotes, who cares? Get commit -m. Fixed the cache for TypeScript. Get push origin main. And this will kick off another round of actions because we pushed to main, right, so it's going to run it for that as well.

[00:11:11]
So in theory, the TypeScript, usually the lint finishes first, but TypeScript is usually not too far behind it. Now, what's cool about this is this is going to wait for all of these to pass, and then if all of these pass, it's immediately going to go to Vercel like cool, I have a new passing commit in main, please deploy it. There's no human in the loop here.

[00:11:33]
Vercel by default will just do that by default. You can set it to say like, I need a human in the loop here, like, get ready for deployment, get out the test deployment, but do not promote it to production. Mine right now will automatically promote it to production. The more you can automate the things, the better time you're going to have.

[00:12:00]
Like, LinkedIn had like the most arduous CI/CD platform ever, like it was very sophisticated. But like, if something broke in the middle of the night and I got paged, I had to go fix it, like I had to wake up no less than two more people to say like, you need to review this and you need to click deploy, right, which was such a pain in the butt.

[00:12:20]
It was intentional, right? Like it's a very, it's a large company. It's like there's a lot of people involved there. They didn't want people just like YOLO cowboying it. But I wanted to YOLO cowboy, so I was pretty upset. So these are all passing now. If we go to FEM traffic, we should be able to see deployments here. You can see this already went out.

[00:12:51]
Fix the cache for this, so if we click on this and visit, this is the deployment that has just gone out because of that. You could make this wait for someone to come in and say like, yes, I approved this deployment to go out, but we didn't do that. So if you actually go to blah, and we click on just overview and click visit, this is the one that we just put out, right?