Forem: Akash Roy

Deploy to Azure Kubernetes Service (AKS) using Azure Pipelines

Akash Roy — Wed, 08 Oct 2025 08:55:32 +0000

If you’ve already built your first Azure Pipeline, this next step will show you how to take your code all the way to production — deploying automatically to an Azure Kubernetes Service (AKS) cluster.

This post is a simple walkthrough for anyone who wants to see their containerized app running on Azure, without deep Kubernetes expertise.

What We’ll Do

Containerize a sample app
Push the image to Azure Container Registry (ACR)
Create a YAML-based pipeline to deploy it on AKS
Validate the deployment

Step 1: Prepare Your App and ACR

Let’s assume you have a simple Node.js or Python app.

Create a Dockerfile in your project root:

FROM node:18
WORKDIR /app
COPY . .
RUN npm install
CMD ["npm", "start"]

Now, build and push this image to Azure Container Registry (ACR):

az acr build --registry <your-acr-name> --image sampleapp:v1 .

Step 2: Connect Azure DevOps with ACR and AKS

In your Azure DevOps project:

Go to Project Settings → Service Connections
Create two connections:
- Azure Resource Manager (for AKS)
- Docker Registry (for ACR)

These connections will authenticate your pipeline securely.

Step 3: Create a Deployment YAML

Add deployment.yaml in your repo:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: sampleapp
spec:
  replicas: 2
  selector:
    matchLabels:
      app: sampleapp
  template:
    metadata:
      labels:
        app: sampleapp
    spec:
      containers:
      - name: sampleapp
        image: <your-acr-name>.azurecr.io/sampleapp:v1
        ports:
        - containerPort: 80

Step 4: Build the Azure Pipeline

Create .azure-pipelines/aks-deploy.yaml:

trigger:
- main

pool:
  vmImage: ubuntu-latest

variables:
  imageName: sampleapp
  tag: '$(Build.BuildId)'

stages:
- stage: Build
  jobs:
  - job: BuildImage
    steps:
    - task: Docker@2
      inputs:
        containerRegistry: 'acr-connection'
        repository: '$(imageName)'
        command: 'buildAndPush'
        Dockerfile: '**/Dockerfile'
        tags: |
          $(tag)

- stage: Deploy
  dependsOn: Build
  jobs:
  - job: DeployToAKS
    steps:
    - task: KubernetesManifest@1
      inputs:
        action: deploy
        kubernetesServiceConnection: 'aks-connection'
        manifests: '**/deployment.yaml'
        containers: |
          $(imageName)=$(imageName):$(tag)

Commit and push this YAML file to your main branch.

Step 5: Run and Verify

Once the pipeline completes, verify the deployment:

kubectl get pods
kubectl get svc

You’ll see your app live on AKS — deployed automatically through Azure DevOps!

Wrapping Up

You’ve just connected CI/CD to a live Kubernetes cluster. From here, you can:

Add health checks or rolling updates
Integrate Helm for versioned deployments
Set up Blue-Green or Canary strategies

This forms the core of a modern cloud deployment pipeline — repeatable, automated, and secure.

Next up: I’ll write about securing pipelines using Azure Key Vault for secret management — stay tuned.

Build Your First Azure Pipeline (YAML-based CI/CD)

Akash Roy — Sat, 17 May 2025 14:13:11 +0000

Now that you’ve seen how Azure DevOps works and what role pipelines play in the DevOps lifecycle, it’s time to get hands-on. In this blog, we’ll walk through creating a complete CI/CD pipeline using YAML in Azure Pipelines.

We’ll cover:

Creating a new Azure DevOps project
Connecting your Git repo
Writing your first YAML pipeline
Running and debugging your build

Let’s go step-by-step.

Step 1: Create a New Project in Azure DevOps

Go to https://dev.azure.com/ and sign in.
Click on New Project.
Enter project name (e.g., my-first-pipeline), select Private, and click Create.

Step 2: Push Code to Azure Repos (or Connect GitHub)

You can either:

Push your local project to the Azure Repo created automatically, OR
Connect an external GitHub repo (from Pipelines > New Pipeline > GitHub)

Make sure your repo has a basic project setup — for example, a Node.js or Python app with tests.

Step 3: Create Your First Pipeline

Go to Pipelines > New Pipeline.
Choose your source (Azure Repos Git or GitHub).
Select your repository.
Azure will try to auto-detect a starter pipeline. You can use it or paste your own.

Step 4: Write the YAML for CI

Here’s a basic CI pipeline for a Node.js project:

trigger:
  branches:
    include:
      - main

pool:
  vmImage: 'ubuntu-latest'

steps:
  - task: NodeTool@0
    inputs:
      versionSpec: '18.x'
    displayName: 'Install Node.js'

  - script: |
      npm install
      npm test
    displayName: 'Install dependencies and run tests'

  - script: npm run build
    displayName: 'Build application'

For Python:

trigger:
  branches:
    include:
      - main

pool:
  vmImage: 'ubuntu-latest'

steps:
  - task: UsePythonVersion@0
    inputs:
      versionSpec: '3.x'

  - script: |
      pip install -r requirements.txt
      pytest
    displayName: 'Install deps and run tests'

Step 5: Run the Pipeline

Once committed, the pipeline will automatically run.

You’ll see:

Each step’s status (success/failure)
Logs for every command
Artifacts (if any) saved from the build

Step 6: Debug Failures

Use the logs tab to inspect each task output
Common issues: missing dependencies, wrong version, permission errors

Step 7: Add Deployment to Azure and Set Up an Azure Service Connection (Optional)

Before your pipeline can deploy to Azure resources, it needs a secure way to authenticate. Azure DevOps handles this using Service Connections.

To create one:

Go to your Azure DevOps project
Navigate to Project Settings > Service connections
Click New service connection
Choose Azure Resource Manager
Select Service principal (automatic) (recommended)
Choose your subscription and authorize access
Give it a recognizable name (e.g., MyServiceConnection)

This connection will be referenced in your pipeline YAML to authorize deployments.

  - task: AzureWebApp@1
    inputs:
      azureSubscription: 'MyServiceConnection'
      appName: 'my-web-app'
      package: '$(System.DefaultWorkingDirectory)/**/*.zip'

Best Practices

Use separate pipelines for CI (build/test) and CD (deploy)
Store your pipeline YAML in the root of your repo (azure-pipelines.yml)
Protect your main branch with build validation policies
Use variable groups and secrets via Azure Key Vault

What’s Next

In the next blog, we’ll look at using Terraform with Azure DevOps to provision infrastructure as code. We’ll start by writing a basic Terraform script to deploy a resource group, and run it from a pipeline.

From pipelines to infrastructure — this is where DevOps gets powerful.

Inside Azure DevOps: Boards, Repos, Pipelines, and Artifacts

Akash Roy — Thu, 08 May 2025 04:51:32 +0000

Azure DevOps is one of the most complete DevOps platforms out there — and it's heavily adopted across enterprises. But if you're new to it, all the moving parts can be a little confusing.

In this post, we’ll break down the four major services you’ll be working with most: Boards, Repos, Pipelines, and Artifacts — and explain how they fit together in a real DevOps lifecycle.

What is Azure DevOps?

Azure DevOps is a suite of services from Microsoft that supports the entire software development lifecycle (SDLC). It includes tools for planning, version control, CI/CD, package management, and more — all integrated under one roof.

The four core services we’ll focus on are:

Azure Boards – Track work items like epics, user stories, bugs, and tasks
Azure Repos – Git-based source code management
Azure Pipelines – CI/CD pipelines for building, testing, and deploying code
Azure Artifacts – Package and dependency management

Let’s explore them one by one.

1. Azure Boards

Boards help you plan, track, and discuss work across teams. It’s fully integrated with Git commits, pull requests, and pipeline deployments.

Key features:

Work item types: Epic, Feature, User Story, Task, Bug
Kanban boards and backlogs
Sprint planning and burndown charts
Queries and dashboards for visibility

If you're using Agile or Scrum, Azure Boards can be your centralized hub for project management.

2. Azure Repos

Azure Repos offers cloud-hosted Git repositories for your source code.

Features include:

Branch policies (e.g., require PR review, build pass before merge)
Code search, diff, blame, and history
Integration with Boards and Pipelines
Pull request workflows with discussion threads

Azure Repos is comparable to GitHub or GitLab in terms of capabilities but shines in enterprise scenarios due to tight integration with Azure AD and Azure Pipelines.

3. Azure Pipelines

Pipelines provide CI/CD automation for your projects. You can build and deploy apps written in any language, to any platform.

Highlights:

YAML-based and classic editor
Microsoft-hosted or self-hosted agents
Support for containers, VMs, Kubernetes, serverless, and more
Built-in integration with GitHub, Repos, Artifacts, and Key Vault

A typical flow:

Code pushed to Git → Pipeline triggers → Build & test → Deploy to staging or production

We’ll build a working pipeline using Azure Pipelines in the next blog.

4. Azure Artifacts

Artifacts is your in-house package management system.

Supports:

NuGet, npm, Maven, Python, and Universal Packages
Versioned and scoped feeds for dev, test, prod
Retention policies and clean-up rules
Integrated with CI/CD pipelines

Use it to store and share internal libraries or build outputs between stages.

How It All Ties Together

Here's how the services connect in a DevOps workflow:

Plan features in Boards
Code in Repos
Trigger CI/CD in Pipelines
Use or publish packages with Artifacts

Every commit, pull request, and release can be linked to work items — giving you end-to-end traceability.

Best Practices

Use service connections with appropriate permissions for security
Define pipeline as code (YAML) for versioning
Link PRs and commits to work items in Boards
Automate deployment of packages using Artifacts feeds

What’s Next

Now that you know the building blocks of Azure DevOps, we’ll use them to create your first end-to-end CI/CD pipeline with source control, builds, and deployment in the next blog.

Time to get your hands dirty.

CI/CD 101: From Code Commit to Production

Akash Roy — Wed, 07 May 2025 07:08:40 +0000

In the world of modern software delivery, speed and reliability are everything. Users expect features to roll out fast — without downtime or drama. That’s where CI/CD comes in.

In this blog, we’ll break down what CI/CD really is, how it powers DevOps, and walk through a real example so you can see it in action.

What is CI/CD?

CI/CD stands for:

Continuous Integration (CI) – Automating the build and test process every time code is committed.
Continuous Delivery (CD) – Automating the release of that tested code to staging or production.

In simple terms:

You commit code → It’s built and tested → If successful, it’s deployed automatically

This approach avoids the nightmare of last-minute integration hell, ensures bugs are caught early, and allows teams to ship smaller, safer changes more frequently.

Benefits of CI/CD

Faster deployments: Shipping becomes routine, not a big event.
Improved quality: Automated testing catches issues early.
Shorter feedback loops: Stakeholders see progress faster.
Reduced risk: Small, incremental changes are easier to roll back.

Typical CI/CD Flow

Here’s a high-level look at what happens in a CI/CD pipeline:

Developer pushes code to a Git repository
CI pipeline triggers:

Runs tests
Lints code
Builds artifacts (e.g., a Docker image or compiled binary)
1. If all steps pass, CD pipeline triggers:
Deploys to staging environment
Optionally runs automated integration tests
Promotes to production

Tools Involved in CI/CD

Depending on your stack, you might use:

Source Control: GitHub, Azure Repos, GitLab
CI/CD Engines: Azure Pipelines, GitHub Actions, GitLab CI, Jenkins
Artifacts: Azure Artifacts, GitHub Packages, JFrog Artifactory
Environments: Azure App Service, AKS, App Center, etc.

In our upcoming blogs, we’ll focus on Azure Pipelines and GitHub Actions.

Example: CI/CD for a Node.js App Using Azure Pipelines

Let’s say you have a simple Node.js app in a Git repo. You want every push to the main branch to:

Install dependencies
Run unit tests
Build the app
Deploy to Azure App Service (if all goes well)

Here’s what a basic YAML pipeline could look like:

trigger:
  branches:
    include:
      - main

pool:
  vmImage: 'ubuntu-latest'

steps:
  - task: NodeTool@0
    inputs:
      versionSpec: '18.x'
    displayName: 'Use Node.js'

  - script: |
      npm install
      npm run test
    displayName: 'Install and Test'

  - script: npm run build
    displayName: 'Build Application'

  - task: AzureWebApp@1
    inputs:
      azureSubscription: 'Your-Service-Connection-Name'
      appName: 'your-app-service-name'
      package: '$(System.DefaultWorkingDirectory)/**/*.zip'
    displayName: 'Deploy to Azure'

This is a minimal setup. Real-world pipelines often include linting, code coverage checks, approval gates, infrastructure provisioning, and rollback mechanisms.

Best Practices

Keep builds fast — under 10 minutes ideally
Fail fast: stop pipeline early if a key step fails
Store pipeline definitions in code (YAML, not UI)
Use secrets for credentials (never hardcode passwords or tokens)
Protect production branches with approvals or checks

What’s Next

Now that you understand the value of CI/CD and how it works, we’re ready to build one ourselves.

In the next blog, we’ll create your first Azure DevOps Project and link it to a Git repo. From there, we’ll configure a working pipeline for real deployment.

Time to get hands-on.

Azure 101: Getting Started with Azure Cloud

Akash Roy — Tue, 06 May 2025 12:24:20 +0000

If you’re diving into DevOps, sooner or later you’ll find yourself working with cloud infrastructure. And when it comes to enterprises, Azure is one of the biggest players in the game. But for many newcomers, Azure can feel like a maze of services, menus, and jargon.

This post breaks down how to get started with Azure practically — with just enough context to understand what's happening, and a CLI-driven walkthrough to create your first resource group.

What Is Azure?

At its core, Microsoft Azure is a cloud computing platform that offers:

On-demand access to computing, storage, networking, and AI services
A pay-as-you-go model
Massive global scale

Whether you’re hosting a web app, spinning up Kubernetes clusters, or building a DevOps pipeline — Azure has a service for it.

Key Concepts in Azure (You’ll Hear These Everywhere)

Before we dive in, let’s get clear on a few building blocks:

Subscription: Your billing boundary. Everything you create lives inside a subscription.
Resource Group (RG): A logical container that holds related resources like VMs, databases, storage, etc.
Region: The physical data center location where your resources live (e.g., East US, West Europe).
Resources: Actual services like Azure VM, App Service, or Key Vault.

Azure Portal vs CLI vs Infrastructure as Code

Azure gives you multiple ways to interact:

Azure Portal: GUI in the browser for manual control.
Azure CLI (az): Fast, scriptable command-line tool.
ARM Templates / Bicep / Terraform: Infrastructure as Code options for automating deployments.

In this series, we’ll focus mostly on CLI and Terraform — because repeatability and automation are DevOps cornerstones.

Hands-On: Set Up Azure CLI and Create a Resource Group

Step 1: Install the Azure CLI

macOS

brew install azure-cli

Ubuntu/Debian

curl -sL https://aka.ms/InstallAzureCLIDeb | sudo bash

Windows
Use the official MSI installer:
https://learn.microsoft.com/en-us/cli/azure/install-azure-cli

Step 2: Login to Azure

az login

This opens a browser window and logs you in with your Microsoft account.

For CI/CD service principals:

az login --service-principal -u <appId> -p <password> --tenant <tenantId>

Step 3: Check and Set Your Subscription

az account list --output table
az account set --subscription "<subscription-name-or-id>"

Step 4: Create Your First Resource Group

az group create --name devops-rg --location eastus

Step 5: List and Delete (Optional)

az group list --output table
az group delete --name devops-rg --yes

Best Practices for Beginners

Use consistent naming conventions: project-env-type-region
Stick to a primary region for experiments (e.g., eastus or centralindia)
Use a separate dev/test subscription from production if possible

What’s Next?

Now that you’ve installed Azure CLI and created your first resource group, you're ready to start deploying real infrastructure.

In the next post, we’ll explore CI/CD concepts from a DevOps perspective — from Git push to production deployment.

Let’s get some pipelines flowing.

What is DevOps? Why It Matters in Modern Software Development

Akash Roy — Tue, 06 May 2025 11:39:20 +0000

Let’s be real — "DevOps" gets thrown around a lot.

Some think it's just about automating deployments. Others think it’s just a fancy job title with no clear definition. And if you're just getting started, it’s easy to get overwhelmed by all the tools, pipelines, YAML files, and buzzwords.

So let’s strip it all down and talk about what DevOps actually is — and why you need to care if you're building anything in the cloud today.

Dev + Ops = DevOps? Not Quite

At face value, "DevOps" combines Development and Operations. But it’s more than just two teams collaborating. It’s a cultural shift in how software gets built, shipped, and maintained.

Back in the day, developers would write code, toss it over the wall, and the operations team would figure out how to run it in production. Naturally, this led to finger-pointing, delays, and a ton of miscommunication.

DevOps breaks that wall. It’s about developers and ops folks working together, continuously, with shared goals and responsibilities.

What DevOps Actually Means (in simple terms)

At its heart, DevOps is about these key things:

Collaboration — No more silos between dev, QA, and ops.
Automation — From code push to production, everything is streamlined.
Continuous Everything — Integration, delivery, deployment, testing — happening all the time.
Monitoring and Feedback — Not just deploying, but observing, learning, improving.

Think of DevOps as the muscle that gets your app from laptop to live — safely and repeatedly.

Why DevOps Became So Important

Software today is no longer shipped once every 6 months. Businesses want updates daily, sometimes hourly.

Here's what the old way looked like:

Code freeze for weeks
Manual testing
Panic deployments at 2 AM
"It worked on my machine" excuses

Now compare that to DevOps:

Automated testing and deployments
Small, frequent releases
Rollbacks when something breaks
Real-time monitoring and feedback loops

DevOps makes software delivery smoother, safer, and faster — which is exactly what businesses need in a cloud-first world.

Why Should You Learn DevOps?

Whether you're a developer, tester, or just curious about cloud technologies — DevOps is the common ground that connects it all. Knowing DevOps means you understand how real-world software is built and maintained.

You'll also:

Build confidence in working with tools like Azure DevOps, GitHub Actions, Terraform, and Docker
Understand modern deployment strategies like blue-green, rolling, and canary
Be better prepared for certifications like AZ-400 and real-world SRE roles

Coming Up Next

In the next blog, we’ll roll up our sleeves and get into Azure basics — setting up your first cloud account, creating a resource group, and understanding how Azure structures your infrastructure.

Stick with this series. By the end, you’ll be confidently deploying real apps to the cloud with clarity and purpose. No fluff. Just practical knowledge.

How to Create a Virtual Machine on Azure Using a Reusable Terraform Script

Akash Roy — Sun, 20 Apr 2025 09:11:14 +0000

Deploying infrastructure shouldn't be a copy-paste headache. Here's how to make your Azure VM setup repeatable and clean using Terraform.

When I started using Terraform to manage infrastructure on Azure, one thing became clear very quickly: writing the same Terraform config every time gets old fast.

In this blog, I'm going to show you how to create an Azure Virtual Machine using a reusable Terraform script. By the end of this post, you'll have a modular setup you can use across projects—without rewriting the whole thing each time.

What You’ll Need

Before we begin, make sure you’ve got the following:

An Azure account
Terraform installed
Azure CLI installed and logged in (az login)

Step 1: Create the Folder Structure

Let’s keep things clean.

mkdir terraform-azure-vm
cd terraform-azure-vm

mkdir modules
mkdir modules/vm

We’ll keep our reusable VM code inside modules/vm and the environment-specific code in the root folder.

Step 2: Build the Reusable VM Module

Inside modules/vm/, create these files:

`main.tf`

resource "azurerm_network_interface" "nic" {
  name                = "${var.vm_name}-nic"
  location            = var.location
  resource_group_name = var.resource_group_name

  ip_configuration {
    name                           = "internal"
    subnet_id                      = var.subnet_id
    private_ip_address_allocation = "Dynamic"
  }
}

resource "azurerm_windows_virtual_machine" "vm" {
  name                = var.vm_name
  resource_group_name = var.resource_group_name
  location            = var.location
  size                = var.vm_size
  admin_username      = var.admin_username
  admin_password      = var.admin_password
  network_interface_ids = [azurerm_network_interface.nic.id]

  os_disk {
    caching              = "ReadWrite"
    storage_account_type = "Standard_LRS"
  }

  source_image_reference {
    publisher = "MicrosoftWindowsServer"
    offer     = "WindowsServer"
    sku       = "2019-Datacenter"
    version   = "latest"
  }
}

`variables.tf`

variable "vm_name" {}
variable "resource_group_name" {}
variable "location" {}
variable "subnet_id" {}
variable "vm_size" {}
variable "admin_username" {}
variable "admin_password" {}

Step 3: Use the Module in Your Environment

Go to the root folder and create:

`main.tf`

provider "azurerm" {
  features {}
}

module "vm" {
  source              = "./modules/vm"
  vm_name             = "dev-vm"
  resource_group_name = azurerm_resource_group.rg.name
  location            = azurerm_resource_group.rg.location
  subnet_id           = azurerm_subnet.subnet.id
  vm_size             = "Standard_B1s"
  admin_username      = "azureuser"
  admin_password      = "MySecureP@ssw0rd123"
}

resource "azurerm_resource_group" "rg" {
  name     = "dev-rg"
  location = "East US"
}

resource "azurerm_virtual_network" "vnet" {
  name                = "dev-vnet"
  address_space       = ["10.0.0.0/16"]
  location            = azurerm_resource_group.rg.location
  resource_group_name = azurerm_resource_group.rg.name
}

resource "azurerm_subnet" "subnet" {
  name                 = "dev-subnet"
  resource_group_name  = azurerm_resource_group.rg.name
  virtual_network_name = azurerm_virtual_network.vnet.name
  address_prefixes     = ["10.0.1.0/24"]
}

Step 4: Don’t Forget the Backend (Optional but recommended)

For team use or remote state management, configure a backend.tf file using Azure Storage Account.

Step 5: Deploy It!

terraform init
terraform plan
terraform apply

Done! Your Azure VM is up and running.

Wrapping Up

With this modular approach, the next time you need a VM? Just tweak a few inputs. No more rewriting long scripts or fighting with syntax every time.

Let me know in the comments if you'd like to see a Linux version, auto-shutdown scripts, or cost-saving tricks next!

Happy Terraforming!