‍

‍

This presentation was presented to the Lofty team on Lab Day. Lab days are our every-other-Friday interval development days where the entire team works on collaborative projects to advance their development and test new technologies for the company.

‍

Transcript:

‍

Alright, happy lab day everybody. I'm gonna show you a demo of Docker Compose Preview environments with this GitHub action called pool preview.

So, I'm gonna go create a quick, I have a contrived pull request, which we'll create. And as we create it, I'm gonna apply the label pool preview to it. We will create that pull request. And because this label is attached, you'll see this action started here for deploying. So we're gonna pull that out real quick. Yeah, so we'll see that's running. Now while that's running, we'll go ahead and go look at an open request that we have.

I opened this one yesterday. I've been fiddling with different commits in here. So it shows some broken builds, but you can see that we have a deployment here. If I click on that, it opens up the preview URL. This one's not listening on port 8000, but if I go to, we have two microservices running. So if you put the port on it, you can see we have our swagger docs. And this is just a couple of blocks for one of our fence line microservices.

This is running on an AWS lightsail instance. So it's super cheap, like less than 10 bucks a month. And this was automatically created by the pull preview action. And it will be automatically deleted when the pull request is closed. It's really simple to set up. It uses our existing Docker compose setup verbatim. And this is an example of the configuration. Move myself out of the way. So it's a pretty simple GitHub workflow. And we use the pull preview action here. The only thing we have to do is put a couple of secrets in place.

So we have to set up an AWS access key and secret access key that has permission to create the light sale instance. And then I also stuffed basically my local dotenv file into a secret for the preview environment and this just gets created as a dotenv file on the instance so that the app has whatever environment variables it needs to run. And then this is all just set up in the secrets and variables for actions under repository secrets. So that's it, once it's configured you just apply that tag and it goes and builds your environment And something else that's really cool for both debugging but also like, you know, you deploy a feature environment.

Someone needs to go look at it, like someone from the PO team or someone from the UX team, or really anyone, someone from the dev team too. You might need to go create some test data for people to work with. And so if you go actually look at the details of these builds…

Let me go find one that I didn't cancel. Can I see the original ones? Let me see this build. It's got a pending deployment. Oh, I messed around with my stuff. That's my fault. Well, the point is that it actually copies the admin from this line of the configuration.

It copies your pub key over from github onto the instance, and that means you can SSH directly in the instance and it gives you all the command to do that in the output of the build. And so that means you can get in there and access a shell and create some data or debug something if things go wrong.

So the idea here is that we can get preview environments and get product review and UX review before code gets merged to like the development branch.

‍

‍