Introduction
This week, I dedicated my time to deploying five applications from my repository to production. Below, I will document the progress, challenges, and solutions I encountered along the way. The apps include a mix of personal tools, web applications, and utilities. Here’s a breakdown of the applications:
The Applications
-
R3vr
A Go-based command-line tool for browsing and interacting with websites through the terminal.
Technologies: Go, Terminal UI
Deployment: GitHub Container Registry -
Warehaus
An inventory management system built using Next.js. It leverages AWS Amplify for front-end hosting, AWS RDS for the backend, and GitHub Actions for CI/CD.
Technologies: Next.js, AWS Amplify, AWS RDS, API Gateway, Vercel
Deployment: AWS, Vercel -
Otto
A load balancer written in Go that uses configuration files to distribute server loads across multiple ports.
Technologies: Go, Qo5 (a load balancing algorithm), Config Files
Deployment: GitHub Actions, Docker -
Portfolio Website
A personal portfolio hosted at chiso.dev, showcasing projects and experience, built using Astro.
Technologies: Astro, Fly.io, GitHub Container Registry
Deployment: Fly.io, GitHub -
Data-Buddy
A utility to efficiently index and display large CSV datasets, part of my implementation of the Maestro feature in the OICR desktop application.
Technologies: TypeScript, Wails, Electron
Deployment: GitHub Packages, Docker
Deployment Process
I took a unique approach to each project based on the requirements and the tools I used.
R3vr
For R3vr, my goal was to decide whether I wanted this to be a standalone CLI tool or a package that could be installed from a registry. Since I wanted the flexibility of both options, I chose to release it as a package that can be pulled from the GitHub Container Registry.
Here’s a snippet of the deployment pipeline:
name: Build and Deploy
on:
push:
branches:
- main
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- name: Set up Go
uses: actions/setup-go@v2
with:
go-version: 1.18
- name: Build
run: go build -o r3vr
- name: Push to GitHub Container Registry
run: |
docker build . -t ghcr.io/your-username/r3vr:latest
docker push ghcr.io/your-username/r3vr:latest
Warehaus
For Warehaus, I utilized a variety of AWS products, including AWS Amplify for the front end, AWS RDS for the PostgreSQL database, and API Gateway to manage traffic. GitHub Actions automated the deployment process, pushing changes to Amplify on each commit.
One challenge I faced was ensuring that the deployment process remained consistent across AWS services. Here’s a simplified version of the workflow:
name: Deploy to Amplify
on:
push:
branches:
- main
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v2
- name: Deploy to Amplify
run: amplify publish --yes
Otto
The deployment for Otto, a load balancer, was a bit more complex. Using Go and Qo5, I ensured the load distribution could be handled via config files. GitHub Actions was again a great help in automating this, deploying the app to Docker containers. You can check out the documentation for Otto’s API [here](link to Otto documentation).
Portfolio Website
My new portfolio website, built with Astro, was deployed to Fly.io. One issue I faced was ensuring a smooth CI/CD process. I resolved it by adding a GitHub Actions workflow that pushes the latest build to Fly.io automatically on each commit. Here’s a snippet:
name: Deploy to Fly.io
on:
push:
branches:
- main
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- name: Build Astro Site
run: npm install && npm run build
- name: Deploy to Fly.io
run: fly deploy
Data-Buddy
Data-Buddy was deployed using GitHub’s package manager. I ran into some issues with package conflicts, but resolving them involved better management of my version control and dependencies. I used the GitHub Packages registry for this deployment:
name: Build and Publish
on:
push:
branches:
- main
jobs:
publish:
runs-on: ubuntu-latest
steps:
- name: Build Wails App
run: npm run build
- name: Publish to GitHub Packages
run: npm publish
Production Reflections
”Production” is the point where your code interacts with the outside world. It’s not just about deploying but also ensuring others can run, test, and build your application while maintaining quality and security. There are numerous protocols to keep your application secure and efficient, and cybersecurity teams work hard to make sure only the necessary parts are 100% safe.
Here’s what I’ve learned:
- Avoid high-cost providers: Choose scalable solutions that align with your budget.
- Set alerts: Use monitoring tools to track uptime, errors, and performance.
- Maximize visibility: If your app is only live for a short period, ensure it’s seen and used during that time.
Production, in a way, also lives in memory—it is remembered as long as the application has been used.
You can find the source code for each application in their respective repositories:
Each repo contains workflows and more details in the .github folder. Check out the ReadMe files for further documentation.
Conclusion
Deploying applications to production can be a complex process, but with the right tools and planning, it becomes manageable. I’ll continue updating this post with more insights as I refine these workflows.