Project Setup and Tech Stack Selection for My Blog Website

Setting up my blog website was a bigger challenge than I expected, but it was a great learning experience. I started with a project plan, picked my tech stack (centered around Azure), and set up my pipeline—only to hit some unexpected roadblocks. Here’s how I navigated the challenges and got everything running.

---

The first thing I did was create a project plan. I had never done this before, so I just grabbed a Google Docs template and started writing. I did some research on what makes a good project plan and narrowed it down to three key areas:

• Project Scope – What’s included in the project and what’s not.
• Objectives – What I actually want to achieve with this blog.
• Requirements – What tools, services, and configurations I’ll need.

At first, I thought I had a solid vision, but when I tried to write it down, I realized I wasn’t as clear as I thought. What are the objectives of this blog? Who’s my target audience? Suddenly, this fun side project felt a lot more serious. After some reflection, I was able to define these properly and move forward.

---

Now for the fun part—choosing the tech stack! This is something I actually enjoy because it makes me feel like a Solution Architect (which, by the way, is my dream role). Since I wanted to showcase my Azure skills, the stack was going to be Azure-heavy. Here’s how I broke it down:

• Database: Azure Cosmos DB – It’s scalable, flexible, and perfect for storing blog posts.
• Hosting: Azure Static Web Apps – Ideal for a simple frontend with easy integration.
• Backend Logic: Azure Functions – This would handle all communication between the frontend and the database.
• Frontend: Vue.js – I had never used it before, so this was my way of challenging myself.
• Languages: HTML, CSS, JavaScript – The basics for web development.

I kept things minimal and efficient, ensuring that each choice had a purpose. No overengineering—just what I needed to get things running.

---

Pre-requisites

Before getting started, I made sure I had the following:

• Azure account
• GitHub account
• Azure DevOps (ADO) account

Steps I Followed

1. Created a GitHub repo – The central place for my code.
2. Set up a project in ADO – Organizing tasks and keeping track of progress.
3. Created a pipeline in ADO and connected it to GitHub – This is where things got tricky.

I had to authorize Azure Pipelines via OAuth, chose the minimal template, and ran it. Everything should have worked smoothly, right? Nope. I was hit with an error about parallelism.

Troubleshooting Pipeline Parallelism Issues

I assumed the default pipeline template would just work out of the box (looking at you, Microsoft). But nope—my pipeline failed because new accounts don’t get parallel jobs by default. The only way to fix this? Fill out an Azure DevOps Parallelism Request Form and wait 2-3 business days. No way was I waiting for that! I was in full motivation mode and needed a workaround.

Attempt #1: Remove Parallelism

I modified the YAML file to remove parallel execution. Easy fix, right? Nope—error again. It’s never that simple.

Attempt #2: Explicitly Define Job Dependencies

I tried manually setting job dependencies so that each job would only start once the previous one finished. Another fail.

The Real Fix: Self-Hosted Agent

After more digging, I found out that every running job consumes a parallel job, and new accounts start with zero. The only real solution? Set up a self-hosted agent.

This turned into a mini-project of its own. Here’s what I did:

1. Followed Microsoft’s documentation – Azure DevOps Self-Hosted Agent Guide

2. Installed the necessary software – I had most of it but grabbed Visual Studio Build Tools just in case.

3. Ran the agent setup in PowerShell – Had no idea you could run cmd.exe inside PowerShell, but hey, you learn something new every day.

4. Configured the agent –

   • Entered my ADO org URL
   • Chose PAT as my authentication method
   • Left most default values as-is
   • Allowed unrestricted access
   • Struggled to find my user account name (solved with whoami in CMD)
   • Misread the “Prevent Start Immediately” prompt (oops—had to start it manually later)

5. Started the agent manually – Had to run services.msc to actually get it running. Finally, my pipeline worked!

---

Using the Pipeline to Deploy

Once my pipeline was running, I used it to automate:

• Deploying my Azure Static Web App
• Provisioning an Azure Cosmos DB instance
• Creating an Azure Function App to handle backend logic

After a few hiccups, everything finally started falling into place. This whole process was way more complicated than I initially thought, but I walked away with a deeper understanding of Azure Pipelines and DevOps workflows. Now, onto the next phase of the project!

---

Final Thoughts If you’re starting a similar project, my advice is: expect the unexpected. Things that seem simple can quickly turn into troubleshooting nightmares. But that’s also the fun part—you learn a ton along the way.

Would I do anything differently? Maybe read the fine print on Microsoft’s limitations before assuming things will just work.

But remember:

“

Hitting roadblocks and finding workarounds is what makes projects like this so rewarding!

”