?? Pipeline Dreams: How Azure DevOps Took My Node.js App from Localhost to AKS
A few weeks ago, I kicked off what I like to call my DevOps journey, starting small by containerizing a Node.js API with Docker and slowly perfecting it on my local machine. But of course, running things locally was just the start.
Next came the real adventure: learning new tools like Helm (because who doesn’t love packaging things into a neat little chart?), Lens for visualizing my Kubernetes cluster (10/10 would recommend), and the endless fight between config files, secrets, and YAML indentation nightmares.
But the end goal was always clear: ? Take my local setup, move it to the cloud, and finally automate the whole thing through a CI/CD pipeline.
After navigating the different service connections, container registries, and even emailing Microsoft to ask, “Hey, can I have more parallel jobs, please?”, I’ve finally arrived at a fully automated deployment flow.
So here’s the full breakdown (with bonus battle scars included):
?? Step 1: Building the Foundation with Service Connections
You won't be able to touch the pipeline until the groundwork is in place. Think of service connections as the secure API keys that let Azure DevOps communicate with all your external resources without throwing mysterious authentication errors.
Without them, your pipeline is basically standing outside the club like, “But my name's on the list!”
Here’s how I set mine up:
?? AKS Service Connection
To talk to my Kubernetes cluster (because "kubectl who?" without context):
?? GitHub Service Connection
So the pipeline can actually find and build my code:
?? Azure Subscription Service Connection
To interact with Azure resources in the deployment stage:
?? Why does this matter? This connection lets the pipeline authenticate securely and run Azure CLI commands like fetching AKS credentials or managing resources, without having to manually log in every time. It's basically the pipeline's backstage pass to Azure.
?? GHCR (GitHub Container Registry) Service Connection
For pushing the Docker images I build straight to GHCR:
?? Pro tip: Name your service connections clearly. You'll thank yourself later when debugging the inevitable “wrong service connection” errors, trust me on that one.
?? Step 2: The Moment I Emailed Microsoft
If you're on the Azure DevOps free tier like me, you’re limited to one parallel job. Which is nice… until your builds start queuing up like you're giving away free RTX 5090 Founder Editions.
So I filled out the Azure DevOps Parallelism Request Form and sent Microsoft my plea for help.
In my case, I explained:
"Hey Microsoft, I'm running production grade workloads and need concurrent pipelines to support builds and deployments without delays.", (They don't need to know I'm just learning the basics ??. I'm pretty sure my email read like I was running NASA grade workloads.).... and shoutout to Microsoft for not leaving me on read, they actually responded quickly, and my parallelism was unlocked. ??
If you haven't done this yet and you're scaling your pipelines, I'd 100% recommend getting ahead of it.
?? Step 3: Crafting the Azure DevOps Pipeline
Once the groundwork was set, I built a two-stage YAML pipeline that handles:
领英推荐
?? Stage 1: Build
? Checks out the repo.
? Builds a Docker image.
? Pushes it to GHCR, using the build ID as the tag.
?? Stage 2: Deploy
? Authenticates with AKS using az aks get-credentials.
? Validates the cluster is reachable and the namespace exists.
? Runs a helm upgrade --install to deploy the latest image.
?? Debugging Along the Way
One key thing I added was a file listing step using ls -R. Why? Because my Helm step was failing with “path not found” errors.
Turns out, Azure DevOps doesn’t magically check out your repo in every stage unless you explicitly say so. Adding - checkout: self in both stages fixed it. Shocking, I know. It's almost like computers do exactly what we tell them to and not what we want them to. ??
?? The Full Pipeline YAML (High-Level)
?? Helm Doing the Heavy Lifting
In the deploy stage, Helm takes care of the deployment with:
And with that, I was deploying automatically to AKS after every push to main.
?? The Final Result
? Code push triggers build.
? Docker image builds and pushes to GHCR.
? Helm deploys the new version to AKS.
? I sit back and sip some rum while my app goes live.
Well, except for the occasional harmless warning like:
(Spoiler: it's usually nothing to worry about.)
?? Lessons Learned
That’s the journey so far! It’s been a fun and sometimes mentally draining ride from a local Docker container to a full cloud-native CI/CD workflow.
If you're on a similar path, feel free to connect or drop me a message. I’d love to hear how others are tackling AKS deployments, Helm charts, or Azure DevOps adventures!
#DevOps #AzureDevOps #AKS #Kubernetes #Helm #Docker #CloudNative #CICD #GitHubActions #CloudComputing #InfrastructureAsCode #YAML #DevJourney