DEV Community: Bolarinwa Olayinka

The Journey from a Simple 'Click' to a Confirmed Connection

Bolarinwa Olayinka — Thu, 31 Jul 2025 14:02:57 +0000

Building a modern application is rarely a single, smooth process. It’s a series of meticulously solved problems, often starting with the most basic components. This week, I hit a significant milestone on my latest project, but the journey to get there was a valuable lesson in full-stack debugging and resilience.

The task seemed straightforward: create a settings page in a React application that allows a user to save their Azure DevOps credentials. The first step was to build the two sides of the connection: the frontend, a user-friendly interface, and the backend, a robust Node.js server designed to receive and process the data.

At first glance, everything looked correct. I had two separate terminals open, each running a server. The frontend application was live in my browser, and the backend terminal showed the comforting message, "Backend server running on port 5000." My code was in place, and I confidently typed in the details and clicked the "Save Azure DevOps Settings" button.

Then came the first unexpected challenge. The frontend displayed a success pop-up, but nothing—absolutely nothing—happened in the backend terminal. The silence was deafening. My initial instinct was to blame a communication error, but the truth was far more subtle. After reviewing the code, I discovered a crucial detail: the frontend's save function was a placeholder. It was designed to simulate a successful save with a simple pop-up, but it was not actually sending a network request to the backend. It was a good reminder that just because an interface looks functional, it doesn't mean the underlying systems are connected.

The fix was to replace the placeholder with a proper fetch request, instructing the frontend to send the user's data to the backend endpoint. But with this correction came a new error: the dreaded "EADDRINUSE" message. This meant a ghost process was still occupying the server port, preventing my new, corrected server from starting. Debugging this required a methodical approach, checking for active processes, identifying the culprit, and terminating it before successfully restarting the server. It wasn't a complex fix, but it required persistence to get the system into the right, clean state.

Finally, with both my frontend and backend running, I clicked the "Save" button one last time. I watched my backend terminal as if it were a live status board. And there it was—a new line of text, a console.log message displaying the data I had just entered from my browser.

This seemingly small achievement—a line of text in a terminal—represented much more. It was a tangible confirmation that the full-stack system was connected and working as intended. The entire process, from identifying the initial placeholder code to meticulously clearing a stuck port, was a testament to the methodical and resilient approach required for technical development. This kind of work isn't just about writing code; it's about building and debugging systems, and it's a foundational skill for anyone looking to make a meaningful impact in the field.

With this vital connection established, the real work can now begin: adding the actual logic to the backend to create an Azure DevOps project via Infrastructure as Code. The foundation is solid, and the path forward is clear.
[A screenshot of the backend terminal, showing the successful console.log message. This confirms that the frontend application has successfully sent data to the backend.".]

Building an Azure CI/CD Dashboard: Errors, Solutions, and Lessons Learned

Bolarinwa Olayinka — Thu, 24 Jul 2025 22:23:29 +0000

In my journey to build a meaningful Azure CI/CD dashboard as part of my product-led platform, I faced several technical challenges and errors along the way. These obstacles became valuable learning experiences that helped me deepen my understanding of React development, npm, and continuous integration workflows. This blog post walks you through some common errors I encountered, how I diagnosed and fixed them, and the overall significance of these steps in delivering a functional dashboard.

Setting Up the React Project
I started with a React frontend intended to visualize CI/CD pipeline statuses, infrastructure deployment states, and user management info. The idea was to build a dashboard that clearly communicated the progress and health of a cloud-native product development environment.

Initially, I ran the following command to start the development server:

npm start

However, I immediately ran into an error:

npm ERR! enoent Could not read package.json: Error: ENOENT: no such file or directory, open '/workspaces/azure-terraform-setup/package.json

This meant that npm could not find the package.json file in my current directory. Since package.json is essential for npm to manage dependencies and scripts, this error stopped me in my tracks.

Solution: Navigate to the Correct Directory
Upon inspecting my project structure, I realized that my React frontend was inside a frontend folder. The root directory didn't contain the package.json file, but frontend did. So I changed directory:

cd frontend

Then I ran:

npm start`

bash
cd frontend
Then I ran:

npm install
npm start

This correctly started the React development server.

Missing index.js File Error
Once inside the frontend directory, I was greeted with a new error after running npm start:

Could not find a required file. Name: index.js Searched in: /workspaces/azure-terraform-setup/frontend/src

This error indicated that React’s build tools could not locate the entry point of the application — the index.js file inside the src folder.

Solution: Create the src Directory and Entry File
I checked and found that the src folder was missing. So I created it:

mkdir src
Then I created index.js inside src with basic ReactDOM rendering code:

`import React from 'react';
import ReactDOM from 'react-dom/client';
import App from './App';

const root = ReactDOM.createRoot(document.getElementById('root'));
root.render();`

This told React where to start rendering my components. Once I saved this, the npm start command successfully launched the app.

Syntax Errors in App.js
During development, I wrote a React component called App.js to display my dashboard. However, I encountered a Babel parser error:

SyntaxError: /workspaces/azure-terraform-setup/frontend/src/App.js: Identifier 'React' has already been declared.

This usually means I had imported React multiple times in the same file.

Solution: Remove Duplicate Imports
I reviewed App.js and found that import React from 'react'; was declared twice. Removing the duplicate import fixed the error immediately.

I also faced another syntax issue:

SyntaxError: Missing semicolon. (67:3)

Surprisingly, I had mistakenly included a command like npm start inside my App.js file as if it were code, causing a syntax error.

Solution: Clean up Code and Remove Erroneous Commands
I carefully scanned my App.js and deleted any non-code commands mistakenly placed inside the file. This allowed Babel to parse and compile the file without issues.

Dashboard Rendering the Same Content Repeatedly
Initially, my React dashboard component was rendering the exact same information block five times, which wasn’t the intended behavior. I wanted to show multiple different information blocks such as infrastructure status, build status, and user management.

Solution: Use an Array of Data Objects to Render Multiple Info Blocks
I created a constant array infoBlocks with multiple objects, each representing a different dashboard section:

const infoBlocks = [ { title: "🚀 Azure CI/CD Platform", description: "Welcome to your product dashboard.", items: [ "✅ Infrastructure deployed with Terraform", "✅ GitHub Actions connected", "🧪 Add environments, users, or services here", ], }, { title: "🔧 Build Status", description: "Check your latest builds.", items: [ "✅ Last build passed", "⏳ 2 builds in queue", "❌ 1 failed build needs review", ], }, { title: "👥 User Management", description: "Manage your team and permissions.", items: [ "🟢 12 active users", "🔒 3 pending invitations", "🛠️ Admin roles assigned", ], }, ];
Then, inside the App component, I mapped over this array to render distinct content blocks instead of repeating the same one.

This approach made the dashboard much more meaningful and visually informative.

Encountering Development Build Warnings
When I ran the app in development mode, the terminal showed:

Note that the development build is not optimized.
To create a production build, use npm run build.

webpack compiled successfully

Understanding the Warning
This is a normal message from React’s build system. It informs developers that the current build is optimized for debugging and fast rebuilds, but it is not suitable for production deployment because it is larger and slower.

Key Takeaways from Errors and Solutions
Always check your current directory when running npm commands to ensure you are in the folder containing package.json.

React requires a src/index.js file as the entry point. Creating this file is necessary if missing.

Watch out for duplicate imports and non-JavaScript commands mistakenly placed in source code.

Use data-driven rendering for components when you want to display multiple different info blocks dynamically.

Understand that development build warnings are normal and can be explained as part of your development workflow.

Conclusion
Building a dashboard for an Azure CI/CD platform was both rewarding and educational. The errors and challenges I faced along the way, such as missing files, syntax mistakes, and incorrect rendering, helped me solidify best practices in React development and npm project management.

By overcoming these obstacles, I have built a meaningful, functional dashboard that visually represents vital CI/CD and user management information. This experience positions me well to continue delivering scalable, user-friendly cloud products.

How to Deploy an Azure Linux Virtual Machine Using Terraform

Bolarinwa Olayinka — Sat, 19 Jul 2025 18:43:04 +0000

Architecture Overview

In this guide, I’ll walk you through how to deploy a Linux Virtual Machine (VM) on Microsoft Azure using Terraform — an Infrastructure as Code (IaC) tool.

This example sets up:

A Resource Group

Virtual Network

Subnet

Public IP

Network Interface

Linux VM
Prerequisites
Before you begin, ensure you have:

Azure CLI installed and logged in

Terraform installed

An active Azure subscription

Terraform Configuration

terraform {
  required_providers {
    azurerm = {
      source  = "hashicorp/azurerm"
      version = "~> 4.0"
    }
  }
}

provider "azurerm" {
  features {}
}

Use environment variables or a secret manager for production

  subscription_id = "<your-subscription-id>"
  tenant_id       = "<your-tenant-id>"
  client_id       = "<your-client-id>"
  client_secret   = "<your-client-secret>"
}

variable "prefix" {
  default = "ybeedigital"
}

Infrastructure Resources

Resource Group

resource"azurerm_resource_group" "myrg" {
  name     = "${var.prefix}-resources"
  location = "UK South"
}

2. Virtual Network and Subnet

resource "azurerm_virtual_network" "main" {
  name                = "${var.prefix}-network"
  address_space       = ["10.0.0.0/16"]
  location            = azurerm_resource_group.myrg.location
  resource_group_name = azurerm_resource_group.myrg.name
}

resource "azurerm_subnet" "internal" {
  name                 = "internal"
  resource_group_name  = azurerm_resource_group.myrg.name
  virtual_network_name = azurerm_virtual_network.main.name
  address_prefixes     = ["10.0.2.0/24"]
}
3. Public IP

resource "azurerm_public_ip" "main" {
  name                = "${var.prefix}-pip"
  location            = azurerm_resource_group.myrg.location
  resource_group_name = azurerm_resource_group.myrg.name
  allocation_method   = "Static"
  sku                 = "Standard"
  idle_timeout_in_minutes = 30

  tags = {
    environment = "staging"
  }
}

Network Interface

resource"azurerm_network_interface" "main" {
  name                = "${var.prefix}-nic"
  location            = azurerm_resource_group.myrg.location
  resource_group_name = azurerm_resource_group.myrg.name

  ip_configuration {
    name                          = "internal"
    subnet_id                     = azurerm_subnet.internal.id
    private_ip_address_allocation = "Dynamic"
    public_ip_address_id          = azurerm_public_ip.main.id
  }
}

Linux Virtual Machine

resource"azurerm_linux_virtual_machine" "main" {
  name                  = "${var.prefix}-vm"
  location              = azurerm_resource_group.myrg.location
  resource_group_name   = azurerm_resource_group.myrg.name
  network_interface_ids = [azurerm_network_interface.main.id]
  size                  = "Standard_B1s"
  admin_username        = "adminuser"
  admin_password        = "P@ssw0rd123!"  # Replace in production with SSH keys

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

  source_image_reference {
    publisher = "Canonical"
    offer     = "0001-com-ubuntu-server-jammy"
    sku       = "22_04-lts"
    version   = "latest"
  }

  computer_name                  = "${var.prefix}-vm"
  disable_password_authentication = false

  tags = {
    environment = "staging"
  }
}

Optional: SSH Authentication (Recommended)
Instead of a password, use an SSH key:

admin_ssh_key {
  username   = "adminuser"
  public_key = file("~/.ssh/id_rsa.pub")
}

disable_password_authentication = true

How to Deploy
Initialize Terraform

terraform init
Preview the changes

terraform plan
Apply the configuration

terraform apply

Conclusion
Using Terraform to deploy infrastructure on Azure automates your setup process and ensures consistency, repeatability, and easy scalability.

This guide showed you how to provision a Linux Virtual Machine along with essential networking components, all managed as code. As your infrastructure grows, you can extend this foundation with services like:

Azure Key Vault

Azure Monitor

Managed PostgreSQL/MySQL databases

Load Balancers

VM Scale Sets

Embrace Infrastructure as Code with Terraform to streamline your cloud operations and accelerate deployment. Happy building!