Untitled

If you’ve ever tried to build something whether it’s a treehouse, a wedding plan, or a software project, you know the feeling. You start with excitement, but ten minutes later, you’re drowning in a sea of "What do I do first?" and "Did I remember to fix that thing?"

This week, I built and deployed a website feature. But the hero of the story wasn't the code I wrote. It was a tool called Jira.

If you have no idea what Jira is, think of it as a To-Do list with superpowers. Here is how it saved me from chaos during my latest project.

1. It Stopped the "Brain Fog" (The Backlog)

When you start a project, you have 50 ideas in your head. Change the logo! Fix the footer! Add a contact form! It’s overwhelming.

In Jira, there is a place called the Backlog. It’s basically a storage bin for ideas. I took every single thought I had for my "Gotto Job" website and dumped them into the Backlog as "Tickets." Once they were in Jira, I didn't have to stress about remembering them. My brain was free to focus on the work.

2. It Helped Me Focus on "Just One Thing" (Sprints)

Have you ever had a list of 20 tasks and felt so paralyzed you did zero? That’s what happens when you look at the whole mountain.

Jira uses something called Sprints. A Sprint is just a promise to yourself: "For the next few days, I will ignore 95% of the list and only focus on these 3 specific items."

I moved three small tasks (like "Fix the Headline" and "Update the Footer") into my Sprint. Suddenly, a massive project felt easy. I wasn't building a whole website; I was just fixing a headline.

3. The Satisfaction of "Moving the Box" (The Board)

This is the best part. Jira gives you a digital board with columns: To Do, In Progress, and Done.

There is a weirdly satisfying psychological effect when you click a task card and drag it from In Progress to Done. It’s a visual trophy. It proves you are moving forward. When I was working solo, seeing those cards pile up in the "Done" column kept me motivated when the coding got tough.

4. It Gave Me Clear Instructions (Acceptance Criteria)

Ever write a note to yourself like "Fix the thing," and then three days later you look at it and go, "What thing? Fix it how?"

Jira forces you to be specific. Inside every ticket, I wrote "Acceptance Criteria." Instead of just "Fix Footer," I wrote:

Must show today's date.

Must include my name.

Must be visible on mobile.

When I sat down to code, I didn't have to guess. I just followed the instructions I gave myself earlier.

The Verdict?

Before using Jira, my projects were a mess of sticky notes and forgotten ideas. Using Jira turned the process into a game one where I knew the rules, saw my score (progress), and actually crossed the finish line.

After mastering the basics of Git locally, it was time to go global. The second half of my DevOps sprint was all about GitHub—not just as a storage locker for code, but as a collaboration hub.

Phase 1: The Professional Profile (Assignment 4)

You can't show up to a party without introducing yourself. I spent time polishing my GitHub profile to look the part.

Trending: I explored the "Trending" tab to see what the world is building.

The Workflow: I learned the difference between Starring (bookmarking) and Forking (copying). Forking is key—it’s how you get your own copy of a project to mess around with safely.

Phase 2: The Collaboration (Assignment 5)

This was the real deal. I simulated joining an open-source team.

The Challenge: Contribute to a shared repository (devops-micro-internship-interviews) without breaking anything.

The Tech: I set up SSH keys (no more typing passwords!) and learned the "Triangle Workflow."

origin = My Fork (where I push)

upstream = The Original Repo (where I pull updates)

The Result: I created a feature branch, added my name to the student list, and opened my very first Pull Request (PR).

There is something incredibly satisfying about seeing that green "Open pull request" button. I’m no longer just coding alone; I’m part of the ecosystem now.

Key Takeaway: Syncing with upstream before pushing is the secret to a happy life (and no merge conflicts).

I’ve officially started my journey into DevOps, and the last few days have been a whirlwind of terminal commands, SSH keys, and green commit messages. Here’s a look at how I went from "installing software" to deploying a live website on AWS.

Phase 1: The Setup (Assignment 1)

It all started with the basics. I installed Git (goodbye, default Windows command prompt; hello, Git Bash!) and learned the importance of identity.

The Big Lesson: git config --local vs git config --global. It seems small, but keeping work and personal emails separate is a pro move I’m glad I learned early.

Phase 2: Building & Deploying (Assignment 2)

This was the "cool" part. I didn't just write code; I shipped it.

Local: I built a simple "CodeTrack" website and used git add and git commit to save snapshots of my work.

Cloud: I spun up an AWS EC2 instance, installed Nginx, and moved my files to the live server. Seeing my name on a public IP address was a huge "I made this!" moment.

Phase 3: The Safety Net (Assignment 3)

Finally, I learned why developers don't just push code directly to production. I practiced the Feature Branch Workflow.

Instead of risking the main code, I created a sandbox using git checkout -b feature/contact-page.

I built a Contact page in isolation, verified it, and then merged it back using git merge. It felt like magic watching the files disappear and reappear as I switched branches.

Current Mood: 💻☁️ Feeling like a real engineer. Next stop: Open Source!