#100DaysOfDevOps - Day Forty - Four After completing a full Jenkins-based CI pipeline over the last few days, I wanted to take time to talk about GitHub Actions properly before jumping into writing workflows. Today was more about concepts and structure than hands-on work. What I covered: ✅ what GitHub Actions is ✅ why it is one of the most popular CI tools today ✅ how it compares to Jenkins ✅ why GitHub Actions feels simpler when your code already lives in GitHub ✅ why Jenkins is still valuable because it can work across multiple platforms ✅ the role of: GitHub Actions documentation GitHub Marketplace ✅ GitHub Actions concepts like: workflow job runner secrets triggers One thing that really stood out to me today is that the core ideas behind CI tools are usually not different. A lot of the time, what changes is the naming, the interface, the level of setup required, etc. So in many ways, learning Jenkins first made GitHub Actions easier to understand, because I could already recognize the same ideas under different names. When you understand the concept deeply, moving between tools becomes much easier. YouTube Video Link: https://lnkd.in/eBpD3YHN #DevOps #100DaysOfDevOps #GitHubActions #Jenkins #CICD #ContinuousIntegration #Automation #GitHub #PlatformEngineering #CloudEngineering #LearningInPublic #TechdotSam

CI/CD shouldn’t be this annoying. Yet somehow, every time I start a new repo, I end up: • rewriting the same GitHub Actions workflows • copying YAML from old projects (and hoping it still works) • debugging pipelines that fail for non-obvious reasons • dealing with slightly different setups across repos • spending more time maintaining pipelines than shipping code None of these are hard problems — just repetitive ones that add up. So I started putting together NERV-Actions. The goal isn’t to reinvent CI/CD. It’s to remove the friction: a small, reusable set of actions that makes pipelines more consistent, easier to plug in, and less painful to maintain. Still a work in progress, but it’s already reducing a lot of the “why is this pipeline different again?” moments. If this sounds familiar, you can check it out here: 👉 https://lnkd.in/gXJJNxTr Curious if others are feeling the same pain with GitHub Actions. #GitHubActions #CICD #DevOps #SoftwareEngineering

#100DaysOfDevOps - Day Forty - Six Today I continued working on the GitHub Actions version of my CI pipeline. The focus was on moving from the workflow skeleton into actual execution, one stage at a time, while testing and troubleshooting along the way. What I worked on today: ✅ created the .github/workflows/ci.yaml file ✅ pushed it to GitHub and confirmed the workflow was triggered ✅ verified that the checkout stage worked ✅ observed how GitHub Actions provisions a runner automatically ✅ added the backend test stage ✅ set up Python on the runner ✅ installed pip ✅ confirmed the backend test/lint stage ran successfully After that, I moved into the image build stage and started setting up: Docker-related steps GitHub secrets for Docker authentication environment variables for image names and tags That part came with multiple errors, including: wrong field names wrong action version invalid Docker tag formatting mismatched secret references And honestly, I’m glad it happened that way. Because one thing this journey keeps reinforcing is: CI/CD is not learned by only watching clean demos. It is learned by writing, testing, failing, correcting, and understanding why the workflow failed. So even though the image build stage is still being resolved, today still felt like strong progress because the earlier stages are now working, and the workflow is taking shape properly. Big takeaway: The deeper skill is not avoiding errors, it is learning how to read them and move forward with clarity. YouTube Video Link: https://lnkd.in/eDVKJz8d #DevOps #100DaysOfDevOps #GitHubActions #CICD #ContinuousIntegration #Docker #Automation #GitHub #YAML #PlatformEngineering #CloudEngineering #LearningInPublic #TechdotSam

If you’ve been in the DevOps game for a while, chances are you’ve crossed paths with Jenkins. It was a trailblazer in CI/CD automation, but let’s face it—those days are behind us. Maintaining Jenkins in 2023 can feel like wrestling with a dinosaur: outdated UI, finicky plugins, and constant server babysitting. Enter GitHub Actions: the modern CI/CD solution that’s baked right into GitHub itself. Whether it’s native GitHub integration, eliminating infrastructure headaches, or leveraging the marketplace of pre-built actions, GitHub Actions delivers simplicity and scalability where Jenkins struggles. Plus, it’s all managed in YAML—clean, lightweight, and easy to debug. That’s not to say Jenkins doesn’t still have its place. For legacy systems, non-GitHub repositories, or custom infrastructure needs, it may remain the right tool for the job. But for most teams using GitHub, it’s time to make the switch. What’s holding you back from adopting GitHub Actions, or if you’ve already made the move, what’s been your experience so far? #DevOps #CICD #GitHubActions

Today I learned Basic Workflow Trigger: GitHub Actions Most CI/CD tools feel like you need a PhD to configure them. GitHub Actions is different. It lives right inside your repo, and the setup is just a YAML file. That's it. Here's the theory behind it: GitHub Actions is an automation platform built into GitHub. Every time something happens in your repo — a push, a pull request, a merge — it can trigger a workflow. A workflow is a sequence of jobs that run on virtual machines called runners. The mental model: event → trigger → jobs → steps → actions. The simplest real trigger looks like this: on: push: branches: [ main ] pull_request: branches: [ main ] This tells GitHub: "Run my workflow whenever someone pushes to main OR opens a pull request targeting main." From there you define jobs — install dependencies, run tests, deploy. All automated. All logged. All free for public repos. Why it matters: → No more "it works on my machine" → PRs get automatically tested before merging → Your team gets instant feedback on every change → You build the habit of shipping with confidence I went from zero to a working CI pipeline in under an hour. If you haven't tried it yet — today is a good day to start. What was your first GitHub Actions workflow? Drop it below #GitHubActions #DevOps #CICD #LearnInPublic #100DaysOfCode #Automation #SoftwareEngineering #GitHub #OpenSource #WebDevelopment

🚀 Leveling up my DevOps game with GitHub Actions! Recently, I worked on improving the CI/CD pipeline for Expenso, and it turned into a deep dive into some powerful GitHub Actions concepts. Here’s what I implemented 👇 🔁 Reusable Workflows * Created a separate repository to manage reusable CI workflows * Centralized logic for build, test, and Docker processes * Easily reused across services without duplicating code 🧩 Composite Actions * Built custom composite actions for common steps like: * Installing dependencies * Running tests * Building applications * Helped keep workflows clean, modular, and maintainable 🧪 Testing with Jest * Integrated unit and coverage tests using Jest * Ensured pipelines fail on test failures * Generated coverage reports for better visibility 🔍 SonarQube Integration * Added static code analysis in the pipeline * Passed secrets securely for authentication * Configured branch-based analysis * Moving towards enforcing quality gates for production readiness 🐳 Docker Integration * Built and pushed Docker images as part of CI * Used dynamic tagging based on app version --- 💡 Key Learnings: * Reusable workflows = pipeline-level reuse * Composite actions = step-level reuse * Reusable workflows run in the caller repo context. * Secrets must be explicitly passed across workflows * Treat CI/CD like production code: modular, reusable, and scalable --- This setup now feels much closer to how real-world systems are built and maintained. Still exploring more around deployment strategies and scaling this further 🚀 #GitHubActions #DevOps #CI_CD #Docker #SonarQube #Jest #SoftwareEngineering

𝐆𝐢𝐭𝐇𝐮𝐛 𝐀𝐜𝐭𝐢𝐨𝐧𝐬 𝐯𝐬. 𝐆𝐢𝐭𝐋𝐚𝐛 𝐂𝐈/𝐂𝐃: 𝐖𝐡𝐢𝐜𝐡 𝐬𝐢𝐝𝐞 𝐚𝐫𝐞 𝐲𝐨𝐮 𝐨𝐧? 🤔 It's one of the biggest debates in the DevOps world. Both are powerhouse tools, but they approach automation with a different philosophy. Here’s my quick breakdown: ▶️ 𝐆𝐢𝐭𝐇𝐮𝐛 𝐀𝐜𝐭𝐢𝐨𝐧𝐬: Think of it like a flexible, event-driven system. The real magic is the Marketplace. You can grab pre-built Actions for almost anything, making your workflow.yml clean and composable. It’s like building with high-quality Lego bricks. ▶️ 𝐆𝐢𝐭𝐋𝐚𝐛 𝐂𝐈/𝐂𝐃: This feels more like a fully integrated, opinionated assembly line. The gitlab-ci.yml is structured with clear Stages (Build, Test, Deploy) that run in order. It gives you a very clear, top-down view of your entire Pipeline. For me, the choice often comes down to the ecosystem and team preference: • GitHub Actions :  for its massive community and plug-and-play reusability. • GitLab CI/CD :  for its seamless, all-in-one platform experience when you're already using GitLab for source control. What's your team's choice and why? Drop your thoughts in the comments! 👇 #DevOps #CI #CD #GitHub #GitLab #GitHubActions #GitLabCI #Automation #SoftwareEngineering

⚙️ #PythonJourney | Day 158 — CI/CD: Automation That Saves Lives Added GitHub Actions to the project. Now every push runs tests automatically. If something breaks, I know immediately. If it passes, I have confidence to deploy. 14 tests running in 44 seconds. Green or red. No surprises. What I learned: → CI/CD isn't optional, it's essential → Catching bugs early beats finding them in production → Automated testing gives peace of mind → GitHub Actions is simple but powerful It's simple, but it changes everything. #DevOps #GitHub #CI #CD #Automation #Backend #Testing

Just deployed my first project using GitHub Actions! A few days ago, CI/CD felt confusing and honestly a bit intimidating. But today, I successfully automated my deployment process — and it feels like a big step forward. Here’s what I learned along the way: • Automation saves time, but more importantly — it reduces human error • Small configuration mistakes can break the entire pipeline (and teach you a lot 😅) • Understanding the flow (build → test → deploy) is more important than memorizing syntax It wasn’t perfect. I faced errors, failed builds, and a lot of trial & error. But that’s the process. Next goal: Improve the pipeline and implement zero-downtime deployments 🔄 If you're learning CI/CD, keep going — it starts making sense sooner than you think. What was your biggest challenge when you first worked with GitHub Actions? #githubactions #cicd #webdevelopment #devops #learninginpublic

⚙️ GitHub Actions: Automate Everything From Code to Production! Yesterday evening (27th April 2026), I attended a live session on GitHub Actions by Shubham Londhe and honestly, it was one of those sessions you don’t want to end. 🔥 Beautifully structured, hands-on, and packed with real-world examples. That one session was enough to inspire me to sit down and write this blog. 🙏 I’ve put together a complete beginner-friendly guide on GitHub Actions covering everything from what it is, the problems it solves, core concepts like Workflows, Jobs, Steps, Runners and Secrets, all the way to a real-world CI/CD pipeline walkthrough. If you’re in DevOps or just getting started, this one’s for you. 📄 Full blog attached — give it a read! A huge thank you to Shubham Londhe 🙏❤️ for delivering such a wonderful session. The way you break down complex topics and make them feel simple is a rare skill. The DevOps community is genuinely lucky to have you. If you haven’t attended one of his sessions yet, do yourself a favour and don’t miss the next one. Drop a comment if you found this helpful, or share it with someone who’s just starting their DevOps journey! #GitHubActions #DevOps #CICD #Automation #GitHub #CloudEngineering #DevOpsCommunity #LearningInPublic