Every self-taught developer struggles along a path of processes because it’s the most obvious path, but that doesn’t mean it’s the most efficient or even industry standard. My lightbulb moment arrived after countless cPanel logins and plenty of accidental live file overwrites because I thought “It’s okay, it’s only one line of code”.
Spoiler alert: It was not fine.
For a long time, my workflow looked like this:
- Open cPanel.
- Navigate through File Manager.
- Upload a file or make edits within File Manager.
- Accidentally overwrite something important.
- Refresh the site.
- Put my head in my hand and think “oops”
For the most part, it worked, but it was a time-consuming, fragile, messy, and one click away from disaster. Eventually, I reached a point where I wanted a more stable workflow with a safety net baked in.
That’s when I started looking into GitHub.
The Turning Point
The shift wasn’t a dramatic event, it was more of a slow realisation of “Hang on, I use GitHub for my other coding projects… perhaps there’s a way to push updates from GitHub to my host”. It wasn’t a leap so much as a gentle nudge, the kind where your brain finally connects two things that have been sitting next to each other the whole time.
Once that thought landed, it became impossible to ignore. The more I looked at my current workflow, the more it felt like I was trying to build a house with a spoon. Yes, technically possible. No, not ideal.
I created a repository and pushed my existing BlankSlate child theme files into it, and began exploring deployment options. Suddenly, I had version history, clean commit messages, and the ability to rollback changes instead of hoping for the best. Most importantly, I had a workflow that didn’t involve navigating cPanel’s clunky UI.
It wasn’t just about convenience; it was about control and finally feeling like I was developing with intention rather than patching things together on a live site and hoping the house didn’t fall down.
The Solution
With everything sitting neatly inside my private GitHub repository, the next logical step was figuring out how to get those changes to my actual site without diving back into cPanel. That’s when I stumbled upon the world of Continuous Deployment (CD), which sounds more intimidating than it is.
In simple terms, Continuous Deployment means:
“When I push changes to GitHub, my host automatically updates the live site.”
Once I understood this concept, I took to Google and learnt about GitHub Actions, which is essentially a small automated script that runs every time I push an update. Its whole job is to take my latest changes and deploy them straight to my hosting environment. Goodbye cPanel, hello smooth workflow.
Closing Thoughts
Making the jump from cPanel chaos to a GitHub-driven workflow wasn’t just a technical upgrade; it was a mindset change. It marked the moment I stopped treating my site like something fragile and started treating it like a project I can build with confidence. That small change in process reshaped how I approach every update, experiment, and idea that eventually becomes part of the JexiDev ecosystem.
It’s funny how something as simple as a cleaner workflow can change how you feel about your own work. Everything felt calmer, more intentional, and far less like I was one click away from disaster. It gave me the space to think bigger, try new things, and trust myself a little more.
This entry captures an important shift from “Just make it work” to “Build it properly”, and it’s one of the foundations that’s allowed everything else to grow.
Found this helpful?
Help keep the JexiDev conveyor belt moving by buying me a coffee. Your support lets me keep building tools, refining ideas, and documenting the journey for others.
Previously: Entry #01: The Retrospective
Coming Next: Entry #03: I Finally Sacked Off Premium Themes for Good