lwcinfra

Building This Website with Azure Static Web Apps, AZ-104 Knowledge, and DevOps

📅 Created: 2026-04-10 | ⏱️ Read Time: 11 mins

Building This Website with Azure Static Web Apps, AZ-104 Knowledge, and DevOps

Overview

This project documents the process of building and deploying this portfolio website using Azure Static Web Apps, GitHub, and a structured DevOps workflow.

The goal is not only to publish a website, but also to treat it like a practical cloud project by applying infrastructure thinking, deployment workflow, and troubleshooting discipline.

Why I Built This

I wanted this website to serve two purposes:

  1. Present my technical profile in a clean and professional way
  2. Demonstrate practical cloud and DevOps skills through a real deployment

Instead of treating the site as only a design exercise, I used it as a hands-on lab to practice:

  • Azure hosting
  • Git and GitHub workflow
  • Static site deployment
  • CI/CD-style update flow
  • Troubleshooting deployment issues
  • Structuring a technical project for portfolio use

Technologies Used

  • Eleventy (11ty)
  • Markdown
  • Nunjucks layout
  • Git and GitHub
  • Azure Static Web Apps

AZ-104 Knowledge Applied

This project is not a direct AZ-104 lab, but it reflects several AZ-104-style concepts in practice:

  • Understanding Azure resource-based deployment
  • Working with cloud-hosted services instead of only local hosting
  • Thinking in terms of production readiness
  • Managing deployment flow in a structured way
  • Verifying configuration and troubleshooting issues during setup

It also helps reinforce an Azure administrator mindset: build, validate, troubleshoot, and improve.

DevOps Practices Applied

This project also includes DevOps-related practices:

  • Using Git for version control
  • Creating feature branches for isolated changes
  • Preparing pull request workflow for safer updates
  • Using Azure Static Web Apps as a deployment platform
  • Validating changes before pushing toward production-style release flow

The next planned improvement is to use Pull Request Preview in Azure Static Web Apps so that changes can be reviewed before merging into the main branch.

What Has Been Completed So Far

Current progress includes:

  • Initial website structure created
  • Pages such as Home and About Me added
  • Project / Lab section started
  • Site deployed to Azure Static Web Apps
  • GitHub repository connected to deployment workflow
  • Basic content and layout structure established

Current Focus

Right now, the focus is on improving the site step by step instead of rushing all features at once.

Current areas of work include:

  • expanding the Projects / Lab section
  • improving internal structure
  • documenting real implementation steps
  • preparing Pull Request Preview workflow
  • strengthening the site as a technical portfolio

What Will Be Added Later

This project will continue to evolve. Planned updates include:

  • Pull Request Preview with Azure Static Web Apps
  • clearer project navigation
  • more cloud and security lab write-ups
  • custom domain setup
  • better presentation of technical experiments
  • stronger production-style workflow

Notes

This page is intentionally being updated gradually.

The purpose is to show real progress, practical implementation, and iterative improvement rather than pretending the project was completed all at once.

1. What I Built

Summary

[Describe what you built in 2–4 sentences.]

Example: I built and updated a personal portfolio website hosted on Azure Static Web Apps.
The update included a Projects / Lab section and an initial project entry page.
The goal was to improve the site structure while also using a more production-style deployment workflow.

Key Changes

  • [Change 1]
  • [Change 2]
  • [Change 3]

Example:

  • Added a Projects / Lab listing page
  • Added the first project detail page
  • Updated site structure to support future project documentation

Technologies Used

  • [Technology 1]
  • [Technology 2]
  • [Technology 3]

Example:

  • Azure Static Web Apps
  • GitHub
  • GitHub Pull Requests
  • Eleventy
  • Markdown
  • Nunjucks

2. Why I Used PR Preview

Objective

[Explain why you used Pull Request preview instead of merging directly to production.]

Example: I used Azure Static Web Apps Pull Request preview environments to validate changes before releasing them to production.
This allowed me to review the updated site safely, confirm that pages rendered correctly, and reduce the risk of pushing broken changes directly to the live website.

Benefits

  • [Benefit 1]
  • [Benefit 2]
  • [Benefit 3]

Example:

  • Safer deployment workflow
  • Better validation before release
  • Clear demonstration of CI/CD thinking in a portfolio project

3. Branch Workflow Used

Workflow Summary

[Explain the Git workflow you used.]

Example: I used a feature branch workflow to isolate changes from the production branch.
All updates were made in a dedicated feature branch, pushed to GitHub, and reviewed through a Pull Request targeting main.

Branches

  • Production branch: [branch name]
  • Feature branch: [branch name]

Example:

  • Production branch: main
  • Feature branch: feature/pr-preview-test

Process

  1. Created a new feature branch
  2. Made content and structure updates locally
  3. Committed the changes
  4. Pushed the feature branch to GitHub
  5. Opened a Pull Request to main
  6. Used Azure Static Web Apps preview deployment for validation
  7. Merged the Pull Request after verification

Example Commands

git checkout -b feature/pr-preview-test
git add .
git commit -m "Add project lab listing and first project entry"
git push -u origin feature/pr-preview-test

4. What I Validated Before Merge
Validation Goal

[Explain what you checked in the preview environment.]

Example:
Before merging, I used the preview deployment URL to verify that the site behaved correctly in a staged environment.

Validation Checklist
 Homepage renders correctly
 Projects / Lab page renders correctly
 Project detail page opens correctly
 Internal links work
 CSS and layout display correctly
 Assets load correctly
 Mobile layout is acceptable
 No obvious routing issues
Issues Found

[Write “None” if no issues were found, or describe what was fixed.]

Example:
None during the initial validation.

or

Example:
I found a broken internal link in the Projects / Lab section and corrected it before merge.

Result

[State whether the preview passed validation.]

Example:
The preview deployment passed validation and was approved for merge into production.

5. What Happened After Merge
Deployment Outcome

[Explain what happened after the Pull Request was merged.]

Example:
After the Pull Request was merged into main, Azure Static Web Apps triggered a production deployment.
The updated version of the site was then published to the live environment.

Post-Merge Actions
[Action 1]
[Action 2]
[Action 3]

Example:

Confirmed that the production deployment completed successfully
Verified that the live site reflected the new changes
Cleaned up the feature branch after merge
Final Result

[Summarize the final outcome.]

Example:
The site was successfully updated using a feature-branch and Pull Request preview workflow.
This demonstrated a practical CI/CD-style deployment process rather than directly editing production.

6. What This Demonstrates
Skills Demonstrated
[Skill 1]
[Skill 2]
[Skill 3]

Example:

Git branching and Pull Request workflow
Azure Static Web Apps deployment
Preview validation before production release
Basic CI/CD and release discipline
Portfolio-oriented cloud project documentation