My First Deployment: The Illusion of Simplicity
I used to think that deployment meant moving code, a small step after the “real work” of coding is done.
When I started my first deployment, I thought it would be easy. I believed that fixing a simple redirect error would only take a few minutes. But I soon learned that it was much harder than I expected.
The Illusion of Simplicity
I used to think that deployment meant moving code from my computer to a server. I pictured it like flipping a switch. When I saw my first error—a wrong network call—I was sure I could fix it quickly.
This mindset is not unique—many developers have been there, believing that deployment is a small step after the “real work” of coding is done.
Understanding the Depth of Deployment
Soon enough, I discovered that deployment is not just about patching a redirect error or uploading files. It is a multifaceted process that involves a thorough understanding of both the development and the production environment.
I realized that the complexities of deployment lie in its many layers, such as:
Server configurations
Environment variables
API connections
Security Protocols
CORS limitations
This process taught me that writing code is creative work, but making that code work on a live website takes careful planning and technical skill.
I also learned that a simple redirect error doesn’t really exist!😂
Unpacking the Mistakes
My first deployment had many problems. I accidentally left behind parts of an old Python back-end server. This old code was mixing things up and was interfering with how the project. So, I switched my code calls to a tool called Axios, which made things even more confusing.
Axios is a JavaScript library that simplifies the process of making HTTP requests
I soon encountered a notorious problem: CORS (Cross-Origin Resource Sharing). A seemingly minor misconfiguration on the Shopify API call threw my integration into disarray. This issue was compounded by another unexpected revelation—the subtle yet significant differences between a Windows development environment and a Linux-based web server. What worked flawlessly on my local machine suddenly behaved unpredictably in production. Each mistake was a step in my learning curve, teaching me the importance of environment parity and careful resource management.
Then I ran into a big issue with CORS (Cross-Origin Resource Sharing). A small mistake with my Shopify API call - thinking I would simply call my data - prevented me from deploying my app due to CORS security reason. The plan was to create a mechanism to hold my API call.
CORS lets websites from one domain use resources (like files) from another domain. It's a way to make the web more open while still keeping things secure
This is where I also discovered that my Windows computer worked very differently from the Linux server that hosts cloud projects on the internet.
These errors taught me to pay close attention to the differences between my development and production environments, and also some Linux commands!
Cloudflare vs Netlify
I decided to stay on Cloudflare — as our site was already there — and try its Wrangler CLI to deploy my project. I was excited about using it, but it did not work as I hoped. The settings clashed, and error after error appeared.
After successfully not breaking my laptop, I looked for an easier solution. That is decided to try I found Netlify. Netlify made deployment much easier. It offered clear instructions and simple controls. A clean way to set up your functions ( APIs & back-end, environment variables and an extremely easy hosting. All of that while passing all the security vulnerabilities that I struggled with Cloudflares Wrangler’s CLI.
Cloudflare:
More advanced but can be tricky to configure (Wrangler CLI issues, clashing settings, frequent errors).
Great for those already using Cloudflare’s DNS and comfortable with command-line tools.
Offers robust security—but the setup can be complex.
Netlify:
Extremely user-friendly with clear instructions and simple controls.
Makes it easy to set up functions, environment variables, and hosting with fewer hassles.
Provides a smoother, more straightforward deployment experience overall.
Deployed!
After seeing my first product going live, It was one of the most rewarding feelings, I felt proud of what I’ve accomplished and really excited about all of the projects to come. After 3 full weeks of constant errors, I’ve finally made it work!
My success did not come in one big moment. I learned from each mistake and fixed problems one by one. Slowly, I removed the error messages, corrected my configurations and set up everything properly.
Deployment Short Guide
For those new to this process, deployment can be summarized in a few key steps:
Preparation: Ensure your code is clean, well-documented, and tested in an environment that mirrors production as closely as possible.
Configuration: Set up your environment variables, server settings, and API endpoints. This step often includes adjustments for differences between development and production environments.
Platform Selection: Choose a deployment platform that aligns with your project’s needs. Whether it’s Netlify, Vercel, or another service, the right platform can simplify the process immensely.
Execution: Deploy your code, monitor the process, and be prepared for troubleshooting. Errors are not the end—they’re signposts directing you to what needs fixing.
Iteration: Deployment is rarely perfect on the first try. Learn from mistakes, adjust configurations, and iterate until your project is stable and fully operational.
Conclusion
Looking back at my first deployment, I see it as a major learning experience. Every mistake taught me how to build better software. I learned that making a project work well takes time, patience, and a commitment to learning. Even though my first deployment was difficult, it helped me grow as a developer and prepared me for future challenges.
Embracing the challenges of deployment has changed the way I work. Now, I know that every error is a chance to improve and become better at what I do.
Let’s Connect!
💼 LinkedIn: alex-kazos
👨🏻💻 GitHub: alex-kazos