DEV Community: OKEKE CHIMA

From Backlog to Deployment: My Hands-On Journey with Jira & Scrum

OKEKE CHIMA — Fri, 06 Feb 2026 18:52:07 +0000

This week, I decided to dive deeper into Agile by running a full sprint on a live project using Jira and Scrum. The goal was simple: take a feature from an idea all the way to deployment, while practicing structured Agile delivery.

Stepping into Multiple Roles

Working solo meant I wore multiple hats throughout the sprint:

Product Owner (PO): I prioritized which UI improvements would deliver the most value.

Scrum Master (SM): I managed the backlog, organized stories, and tracked progress daily in Jira.

Developer: I implemented the UI changes and ensured everything worked as intended.

DevOps Lead: I committed, deployed, and verified updates on a live server.

This approach gave me a realistic perspective of how cross-functional teams collaborate in a real-world environment.

Planning the Sprint

Before touching any code, I focused on backlog refinement:

Created user stories with clear acceptance criteria.

Estimated each story using story points, considering scope, complexity, and risk.

Ranked stories by value to prioritize what mattered most for the sprint goal.

With the backlog refined, I moved into sprint planning, selecting a few high-value stories and defining a concrete goal for the sprint.

Execution and Deployment

Once planning was done, I started incremental work on the first story. I tracked progress in Jira, moving stories across the board as each task was completed.

By the end of the sprint, I had implemented a visible UI improvement on the Go-To Job Board project. I manually deployed the updates to an AWS EC2 server, verified everything worked live, and captured evidence of the final product.

Live project:http://13.61.100.83/

Key Takeaways

Agile isn’t just for teams. Even solo projects benefit from structured backlogs, story points, and sprints.

Jira adds clarity. Breaking work into stories, subtasks, and sprints makes progress tangible.

Small wins matter. Incremental improvements give visibility and confidence, making delivery feel achievable.

Reflection

Running this sprint reinforced a simple truth: Agile is about structured delivery, not just completing tasks. By working through Jira and Scrum in practice, I experienced the full lifecycle of a feature:

Plan → Build → Ship → Verify → Reflect

Building in public and learning through hands-on practice continues to be the fastest way for me to grow as a developer and a DevOps practitioner.

Mastering Git, GitHub, and Deployment: My CodeTrack Assignment Experience

OKEKE CHIMA — Fri, 30 Jan 2026 13:17:43 +0000

In one of my recent assignments, I revisited some core Git and GitHub practices while working on my CodeTrack project. Many developers use Git and GitHub daily without fully understanding the principles behind them—but knowing how and why they work is essential for real-world software development.

Git is more than just a version control tool—it’s like a time machine for your code. Every change, every milestone, and every experiment is recorded, creating a clear history of your project. GitHub complements this by providing a central, collaborative hub where teams can review, discuss, and merge changes safely. Together, they make collaboration seamless and ensure your code is always backed up and organized.

What I Did in This Assignment

For this assignment, I revisited the CodeTrack project and took it a step further by deploying it to a live environment using an AWS EC2 instance. Here’s the workflow I followed:

Forked and cloned the repository to my local machine, created a feature branch, and made updates.

Launched an EC2 instance:

Ubuntu 24.04 LTS, t3.micro instance.

Set up the server environment:

sudo apt update && sudo apt upgrade -y
sudo apt install nginx -y

Transferred project files from my local computer to the remote server using scp (secure copy protocol).

Configured the server:

Set permissions, organized files, and placed index.html and style.css in /var/www/html/ for Nginx to serve.

Restarted Nginx and verified the live site using the public IP of the instance.

This process wasn’t just about running commands—it was about understanding why each step matters. Git ensured my code remained clean, trackable, and collaborative-ready, while GitHub acted as a single source of truth. The deployment step bridged the gap between development and a live environment, a critical skill for any aspiring DevOps engineer.

Lessons Learned

Pull Requests matter: I practiced creating pull requests, which mirrors how teams review, discuss, and safely merge code.

Version control builds accountability: Every change is recorded and auditable, making collaboration smoother.

Deployment connects the dots: Moving from local development to a live server highlighted the importance of infrastructure, file organization, and proper server configuration.

Whether you’re debugging, collaborating, or deploying, Git and GitHub form the foundation of modern software workflows. Mastering them transforms you from just writing code to building, managing, and delivering projects with confidence and precision.

GitHub fork link for this project: https://github.com/ccokeke0023/devops-micro-internship-interviews

Deploying a Production-Ready Portfolio Website Using Linux Fundamentals

OKEKE CHIMA — Fri, 23 Jan 2026 09:22:03 +0000

This week, I deployed a production-ready portfolio website, an experience that significantly deepened my understanding of Linux fundamentals in a real-world context. Rather than working purely at a theoretical level, this project required me to apply core concepts in a practical, production-like environment.

The deployment was carried out on an Ubuntu virtual machine, with Nginx configured as the web server to deliver the application. From server setup and package management to service configuration and validation, every step reinforced the importance of understanding how Linux systems operate under the hood.

While the process came with its challenges, it was ultimately very rewarding. It tested my ability to troubleshoot issues, follow best practices, and make informed decisions when configuring and serving applications in a live environment.

The completed portfolio is live and accessible at:
http://100.52.219.98

Overall, this exercise highlighted how essential Linux skills are in modern DevOps workflows, particularly in areas such as system administration, deployment, and web serving. More importantly, it strengthened my confidence in translating foundational knowledge into practical solutions—an ability that is critical in production environments.

EpicBook web app on AWS using a simple two-tier architecture

OKEKE CHIMA — Tue, 23 Sep 2025 11:40:07 +0000

This week, I rolled up my sleeves and deployed the EpicBook web app on AWS using a simple two-tier architecture.

Architecture

Node.js app on Ubuntu EC2

MySQL on Amazon RDS

Nginx as reverse proxy + PM2 for persistence

Steps I Took

Launched EC2 + RDS, tightened security groups (HTTP, SSH, MySQL).

Installed Node.js, npm, PM2, Nginx; cloned repo; configured .env.

Created epicbook DB in RDS, granted privileges, ran migrations.

Replaced default Nginx config → routed port 80 → 8080.

The Gotchas

Passwords matter — the # in my DB password broke parsing until I quoted it.

MySQL barked with ERROR 1046 (3D000) — turns out you must create the DB before assigning privileges.

Takeaway
This was more than just spinning up an app. Debugging under pressure taught me how tiny misconfigs (networking, creds, DB setup) can derail a deployment. Every blocker forced me deeper into AWS, Node.js, and MySQL internals

DevOps Micro Internship – Deploying a Two-Tier Architecture in AWS

OKEKE CHIMA — Tue, 23 Sep 2025 11:19:05 +0000

DevOps Micro Internship – Deploying a Two-Tier Architecture in AWS

As part of my Week 4 DevOps Micro Internship under the mentorship of Pravin Mishra, Anisa Bibi, Praveen Pandey, and other co-mentors, I worked on building and deploying a two-tier WordPress architecture on AWS. The objective was to design infrastructure that is secure, scalable, and highly available—while gaining hands-on experience by implementing it in practice.
What I Built

Web Tier: WordPress hosted on an Amazon EC2 instance inside a public subnet.

Database Tier: MySQL database on Amazon RDS, deployed in private subnets with no public access.

AWS Concepts I Practiced

CIDR & Subnets – planning IP ranges and segmenting networks into public/private layers

Security Groups – controlling traffic at the instance level with least-privilege rules

NACLs – subnet-level security for an additional layer of protection

Route Tables & Internet Gateway – enabling clean routing and external connectivity

Multi-AZ RDS – ensuring high availability and automatic failover for the database

What I Did

Designed a Virtual Private Cloud (VPC) with carefully planned networking, routing, and security

Configured Security Groups and NACLs to enforce layered security across tiers

Deployed Amazon RDS (MySQL) in a Multi-AZ setup for resilience and fault tolerance

Launched and configured a Linux-based EC2 instance with Apache, PHP, and WordPress

Validated the architecture by successfully publishing a test blog post on WordPress

Key Takeaways

Separating the web and database tiers improves both security and scalability

Managed services like RDS simplify operations while increasing reliability

Strong network design upfront (CIDR, subnets, routing) makes future scaling easier

From Jira Ticket to Live Server: My Week 3 DevOps Sprint

OKEKE CHIMA — Tue, 09 Sep 2025 07:43:16 +0000

Have you ever wondered what it really takes to move a single feature from a Jira ticket all the way into production?

That was exactly the challenge I faced in Week 3 of my DevOps Micro-Internship—a 5-day solo Scrum sprint where I had to plan, code, deploy, and troubleshoot on an AWS EC2 instance.

🎯 Sprint Goal: Deploy a visible footer showing version, date, and author details on the Mini-Finance app hosted on EC2.

🗓️ Sprint Breakdown
✅ Day 1 | The Launchpad

Jira was my mission control. I broke down one Epic into Stories and Subtasks.

First commit: created the footer’s HTML.

Provisioned an EC2 instance, installed Nginx, and configured the web root.

✅ Day 2 | The Polish

Fixed broken image paths and cleaned up CSS for proper rendering.

Transferred updated files to the server with SCP.

Learned the importance of nginx -t before reloading—saves headaches!

✅ Day 3 & 4 | Visibility + Reliability

Ensured the footer was responsive across devices.

Added a /healthz endpoint to check service availability.

Lesson learned: small, daily increments made testing smoother and reduced rollback risks.

✅ Day 5 | The Retrospective

Footer live and sprint goal achieved.

Captured burndown and demo deployed successfully.

📌 Reflections

What went well

Clear acceptance criteria

Incremental delivery

What needs improvement

Automating deployments with CI/CD in the next sprint

Scrum in action
Transparency. Focus. Commitment.

🔑 Key Takeaway

This week wasn’t just about shipping a footer. It was about end-to-end ownership—planning, fixing, configuring, deploying, monitoring, and improving. That, to me, is the essence of DevOps.

⚙️ Tech Stack

AWS EC2 • Ubuntu • Nginx • Jira • Git • SCP • HTML/CSS

A big thank you to Pravin Mishra for structuring such a practical internship, and to mentors like Praveen Pandey, Anisa Bibi, and the DMI community for their support.

I’m excited to carry this ship-to-production mindset forward as I grow in the Cloud & DevOps space.

Week 2 -Git & GitHub

OKEKE CHIMA — Fri, 29 Aug 2025 18:47:59 +0000

Week 2–Git & GitHub Hands-On Assignment:
In this post, I’ll walk you through my Git & GitHub learning journey, where I set up Git locally, created and managed a project, explored branching workflows, and finally deployed my app on an AWS EC2 instance.

✅ *Task 1: Create a Local Project Directory
*
The first step was setting up a project directory. Since I’m on Linux, I installed Git using my package manager. Then I ran the following commands to initialize my project:
mkdir CodeTrack
cd CodeTrack
git init
This created a new folder named CodeTrack and turned it into a Git repository.

✅ Task 2: Configure Git Locally
Next, I configured Git to identify me in this repository.
git config --local user.name "Okeke Christian"
git config --local user.email "eceokekechima@gmail.com"
git config --local --list
This ensures that all commits in this project are linked to my name and email.
When to use Local vs Global?
Global config: Applies to all repositories.

Local config: Overrides global settings for a specific repo (useful if you’re working on multiple projects with different identities).
Step 1: Git Setup Verification
I checked my Git version to confirm installation:
git --version

Output: 2.34.1

Step 2: Create & Modify Files
I created some starter files:
touch index.html style.css
Then I edited them using Visual Studio Code, copying initial content from a GitHub assignment repo.
Step 3: Track & Commit Files
I staged and committed my changes:
git add index.html style.css
git commit -m "Initial commit — Added index.html and style.css"
To verify my commits, I used:
git log --oneline
Step 4: Branching Workflow (Adding Contact Page)
One of the best parts of Git is branching. I created a feature branch to add a Contact Page.
git checkout -b feature/contact-page
touch contact.html
git add contact.html
git commit -m "feat(contact): add contact page with email and phone"
I also updated index.html to include a link to contact.html, then committed the changes.
After switching back to main, I confirmed the link wasn’t visible until I merged the branch.
git checkout main
git merge feature/contact-page
Lesson learned: Changes in a feature branch stay isolated until merged into main.
Step 5: Deploying on AWS EC2
I deployed my static site on an AWS EC2 instance with Nginx.

Steps included:
1.Launch EC2 (Ubuntu).
2.SSH into the instance:
3.ssh -i "cc-key.pem" ubuntu@
4.Install Nginx & start the service.
5.Copy project files (index.html, style.css, contact.html) into Nginx’s web directory.

6.Access the site via browser using the EC2 public IP.
GitHub Profile Setup
I updated my GitHub profile with a professional bio:
Network Engineer | Cloud & DevOps Enthusiast | Learning Git & GitHub
I also added my profile picture and location.
🔎** Why does this matter?**
A professional GitHub profile acts like a live portfolio — showcasing real projects, coding style, and collaboration skills. This builds credibility with recruiters and collaborators.
Forking & Pull Request Workflow
Finally, I practiced contributing to an open-source repo (mini_finance):
Forked the repo.
Cloned it locally & set up SSH authentication.
Created a new branch feature-readme-update.
Updated README.md with assignment notes.
Pushed changes and opened a Pull Request.

👉 Why a PR is important?
A Pull Request is not just about merging code — it’s about collaboration, code review, and knowledge sharing.

Key Takeaways
Local vs Global Git config helps manage identity across projects.
Branching keeps features isolated until merged.
GitHub is more than storage — it’s your portfolio.
Deployment on EC2 gives real-world DevOps exposure.
Pull Requests encourage teamwork and clean code practices