Side projects are both a learning ground and a platform for testing new ideas for many of us. I, too, have been working on my own side products for years. Unfortunately, the CI/CD processes for these projects often remain at the "manually SSH in, git pull, systemctl restart" level. This situation has led to significant time loss and errors, especially when I had to fix something at 3:00 AM.
Bringing the massive CI/CD pipelines we use in corporate projects to side projects is often overkill. It doesn't make sense in terms of cost, time, and complexity. Therefore, for my side projects, I've made three main pragmatic CI/CD design choices to be fast, reliable, and easy to maintain. In this article, I will explain these choices and their reasons based on my own experiences.
1. Minimalist Git-Triggered Deployment: The Simplicity of Push-to-Deploy
Manual deployments, even for small changes, accumulate over time and become a significant burden. At one point, for the backend of one of my side products, I had to connect to the server and run commands one by one for every update. This was both tedious and increased the risk of typing incorrect commands when I was tired. On one occasion, I accidentally confused the production database with the test database and feared several hours of data loss.
