So… this was actually my first time dealing with a situation like this.
The app was already live, users had submitted their data 🧑💻📥, and suddenly I needed to add new features. I panicked a bit at first 😅, what if I broke something in production? What if user data got messed up?
That’s when I realized:
“Okay, I need a proper dev environment… and I need it now.” ⚙️🔥
Before building that dev environment, I paused for a moment to review my production setup.
And honestly… it was pretty solid for a first build 💪🙂
🏗️ My Production Architecture (Simple Overview)
Basically, my production environment runs on Google Cloud Platform (RESTful API, database, storage) and Netlify (frontend deployment). Here’s the simplified architecture:
- Frontend (Vue.js) → Deployed on Netlify as a static web app 🌐
- RESTful API (Flask) → Built with a Dockerfile 🐳 and deployed to Google Cloud Run
- File Storage 📄 → I use Google Cloud Storage to store user-uploaded documents (like invoices, etc.), organized into several folders based on category 🔐
- Database (MySQL) 🗄️ → Hosted on a Compute Engine VM 🖥️
So yeah... production worked. It served real users. But that also meant I had to be careful.
One wrong change… and boom 💥, users would feel it 😬
So how did I end up building the dev environment?
At first, I had no idea where to start, so I explored, asked around, and slowly pieced everything together. Here’s how the journey played out 👇
1. Cloning the Production Database to a Dev Database 🗄️➡️🗄️
The first thing I had to do was duplicate my production SQL database.
I needed the exact same structure but in a safe sandbox where nothing I changed could affect real users.
So I decided to clone the production database inside the same MySQL server, then restore it into a brand-new database for dev database.
Here’s how I did it using the MySQL CLI:
# 1. Export production database
mysqldump -u root -p app_prod > app_prod_backup.sql
# 2. Create a new dev database
mysql -u root -p -e "CREATE DATABASE app_dev;"
# 3. Import production data into the new dev database
mysql -u root -p app_dev < app_prod_backup.sql
2. Creating a New Branch from main 🌿
I knew enough to not touch production code directly.
So I created a dev branch.
It became my sandbox, my first real “safe space” to test anything I wanted.
3. Deploying a New Cloud Run Service ☁️⚙️
This part felt like a milestone.
Spinning up a separate Cloud Run service for dev made me feel like:
“Okay… I’m doing this the right way.”
Now dev had its own backend service, completely isolated.
4. Switching Environment Variables to the Dev Database 🔧🗃️
Next, I updated the environment variables so the dev backend pointed to the dev DB.
This was one of those steps where I double-checked everything, because I was scared I’d accidentally reconnect to production 😅
5. Cloning the Storage Bucket 📦📤
Then came the storage problem:
“Wait… uploaded files also need a dev version??”
Yup.
So I cloned the production bucket into a dev bucket.
6. Updating Backend Config to Use the Dev Bucket 🔁📁
After that, I switched the backend to use the dev bucket.
7. Updating Frontend to Use the Dev API 🌐➡️⚙️
Of course, the frontend also needed to point to the new dev API URL.
Another one of those steps where I said to myself:
“Please don’t typo… please don’t typo…” 😆
8. Testing, Experimenting, and Adding Features Safely 🛠️✨
Once everything was separated—DB, bucket, Cloud Run, branch—it felt so good.
For the first time, I could test new features freely without worrying about real users.
And honestly?
This was the first time I truly appreciated how important a dev environment is.
Wrapping Up — Any Thoughts or Suggestions?
Do you think this setup is on the right track?
I’m open to any insights or best practices that could make it even better 🚀✨
Top comments (0)