Part 13: CI/CD with GitHub Actions

Deploying by hand works, but across many projects it's easy to forget the exact steps for this one. A CI/CD pipeline does it the same way every time. You push a commit to GitHub, it runs the tests, and only if they pass does it deploy.

It matters even more for projects built with AI assistants. Once you're past the proof-of-concept stage, you don't want the agents reaching into your cloud account. You can't be sure what they'll do there - dropping the database, for one. It's safer to experiment with the infrastructure early and figure it out. Then take that access away and let the agents ship only through CI/CD.

Let's build a GitHub Actions pipeline for that.

The pipeline structure

We want four jobs that run in this order:

• Backend unit tests and frontend tests, in parallel.
• The slower backend integration tests, only if both fast jobs pass.
• Deploy, only if the integration tests pass and we're on main.

Ask the assistant:

Create a GitHub Actions workflow.

- first run frontend and backend tests in parallel
- then backend integration tests
- then deploy

For deployment, authenticate with OIDC - don't create a user.

The assistant writes a single .github/workflows/ci-cd.yml. You don't need to read it line by line - the structure matches the four jobs we asked for. The two test jobs run in parallel. The integration job waits for both, and deploy runs only after it, and only on main.

The deploy job assumes an AWS role over OIDC, so there's no long-lived key in the repo. Set the repository Actions secret AWS_ROLE_TO_ASSUME to the GitHubDeployRoleArn output the stack created in Part 12: Deploy to AWS with infrastructure as code. The job then rebuilds the container on the instance, the same way we did by hand.

Ship it

Commit the workflow and push:

git add .github/workflows/ci-cd.yml
git commit -m "Add CI/CD pipeline"
git push

Open the Actions tab and watch the run. On a pull request the tests run and deploy is skipped. On a push to main the tests run and then the server pulls the new code and restarts.

Now that the pipeline deploys on its own, the admin key from Part 12: Deploy to AWS with infrastructure as code has done its job. Remove its AdministratorAccess policy or delete that IAM user, so nothing that powerful is left in your account.

With that, our proof of concept is complete and ships on its own. Before we wrap up, Part 14: Delete the AWS resources takes the cloud resources back down so nothing keeps costing money.