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

#100DaysOfDevOps - Day Forty - Eight Up until now, I had been tagging my Docker images in GitHub Actions using the workflow run number. It worked, but I wanted something more meaningful and more traceable. So today I moved toward using the Git commit hash as the image tag. What I worked on today: ✅ revisited why image tagging strategy matters ✅ moved from using the workflow run number to using github.sha ✅ explored GitHub Actions contexts and built-in variables ✅ checked commit hashes from both GitHub and git log ✅ learned why the full commit hash is too long to use directly ✅ extracted only the first few characters of the hash ✅ stored that shortened value as a workflow variable ✅ reused that variable across the image build, scan, and push stages ✅ observed how GitHub Actions automatically cleans up the runner after execution A better CI pipeline is not only about making it run but also about making its outputs easier to understand, track, and roll back when needed. I did hit another issue near the end around the backend image reference format, so there is still a bit of troubleshooting to finish. But overall, this was a strong step toward making the workflow more production-friendly. YouTube Video Link: https://lnkd.in/eM458884 #DevOps #100DaysOfDevOps #GitHubActions #Docker #ImageTagging #CICD #ContinuousIntegration #GitHub #Automation #CloudEngineering #LearningInPublic #TechdotSam

#100DaysOfDevOps - Day Forty - Five After introducing GitHub Actions yesterday and comparing it with Jenkins, the goal today was to define the structure first before plugging in commands stage by stage. That was the same approach I used with Jenkins: start with the framework, then build on it gradually. What I worked on today: ✅ identified the main building blocks of a GitHub Actions workflow: name on jobs ✅ understood what each one represents ✅ configured the workflow trigger using push ✅ limited the trigger to the main branch ✅ defined the runner using runs-on: ubuntu-latest ✅ understood the difference between: uses for reusable marketplace actions run for direct shell commands One thing I really appreciated today is how similar the underlying CI thinking still is. Even though GitHub Actions looks different from Jenkins, the core idea is still the same: define the structure, define the trigger, define the execution environment, and then define the steps. Tomorrow, the next step is to start plugging real commands into this workflow. YouTube Video Link: https://lnkd.in/er9GVjf7 #DevOps #100DaysOfDevOps #GitHubActions #CICD #ContinuousIntegration #Automation #GitHub #YAML #PlatformEngineering #CloudEngineering #LearningInPublic #TechdotSam

🚀 Day 5/7 – Git & GitHub Journey | Debugging & Restore Power Today was all about fixing mistakes in Git like a pro 🔥 Because real developers don’t just write code… they debug & recover smartly. 💡 Focus: Git Debugging & Restore Commands Mistakes are common: ❌ Wrong file changes ❌ Accidental commits ❌ Deleted important files 👉 Today I learned how to fix ALL of these using Git itself. ⚙️ Practical Tasks I Performed: ✅ 1. Checked file changes Used git status and git diff Understood staged vs unstaged changes ✅ 2. Restored modified files git restore filename 👉 Reverted file back to last committed state ✅ 3. Unstaged files git restore --staged filename 👉 Removed file from staging area ✅ 4. Undo last commit (without losing code) git reset --soft HEAD~1 ✅ 5. Completely discard changes git checkout -- filename (older way) 🧠 Key Learning: Git is not just version control… It’s a complete recovery system if you know the right commands 💪 🔥 Real DevOps Insight: In real projects, mistakes happen frequently. Knowing how to debug and restore safely saves time, code, and production issues. 📂 Skills Gained: Git Debugging 🔍 Code Recovery ♻️ Safe Commit Handling Better Development Workflow #Day5 #Git #GitHub #DevOps #Debugging #LearningInPublic #Automation #AWS #Cloud #DevOpsJourney

📌 Day 2 of #100DaysOfDevOps — Git + Jenkins = Your first real CI pipeline. Yesterday we installed Jenkins. Today we make it actually do something useful. Why integrate Git with Jenkins? Without this, Jenkins is just a server sitting idle. Connect it to Git and every code push automatically triggers a build — no human needed in the middle. 3 things that tripped me up (so you don't have to): → Always install the Git Plugin in Jenkins first — Jenkins won't talk to GitHub without it. Go to Manage Jenkins → Plugins → Available → search "Git" → Use a Personal Access Token instead of your GitHub password — GitHub deprecated password auth in 2021. Generate one under GitHub Settings → Developer Settings → Tokens → Webhook URL format matters — it should be http://[your-jenkins-ip]:8080/github-webhook/ — that trailing slash is not optional. Missing it = trigger never fires. 3 trigger types every DevOps engineer should know: 1. 🔁 Poll SCM — Jenkins checks your repo on a schedule (H/5 * * * * = every 5 mins). Simple but adds unnecessary load. 2. ⚡ GitHub Webhook — GitHub pushes a signal to Jenkins the moment code is committed. Instant. This is what production teams use. 3. ⏰ Build Periodically — Runs on a cron schedule regardless of code changes. Useful for nightly builds and scheduled tests. Real-world use case: Webhook-triggered pipelines mean your team gets build feedback in under 2 minutes of pushing code — catching broken builds before they reach staging. That's the difference between a reactive team and a proactive one. Quick setup recap: 1. Install Git Plugin in Jenkins 2. Add GitHub repo URL in your Jenkins job 3. Add Jenkins webhook URL in GitHub repo settings 4. Set trigger to "GitHub hook trigger for GITScm polling" 5. Push a commit — watch Jenkins fire automatically ⚡ 📄 Want the full step-by-step installation document? DM me and I'll send it across. What trigger are you using in your current setup — Webhook or Poll SCM? Tell me below 👇 #100DaysOfDevOps #Jenkins #Git #GitHub #CICD #DevOps #Automation #CloudEngineering #AWS #Webhooks

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

If a change isn’t in Git, it didn’t happen. That’s not something I’m adopting for this build, it’s something I stopped tolerating. In it-re-dc01, everything lives in one place: Ansible roles. Terraform modules. Docker Compose stacks. Helm charts. Docs. Runbooks. ADRs. One repo: it-re-dc01-infra. GitHub Actions runs on a self-hosted runner on re01-mgmt-01. Every push triggers: • ansible-lint • docker compose validation • terraform validate Merges to main trigger applies. Terraform state is not local. It’s stored and secured via Vault-backed workflows. Secrets don’t live in the repo. They’re issued dynamically. Git defines the desired state. Vault secures access to it. GitHub Actions enforces the path to change. No manual changes. No exceptions. I’ve seen what happens without this discipline. At one point, we ran Jenkins where the pipeline configuration lived inside Jenkins itself. When Jenkins went down, the pipelines went with it. We rebuilt them from memory and screenshots and it took two weeks. That wasn’t a tooling issue, it was a process failure. The tool doesn’t matter, the discipline does. No change, no matter how small or urgent, happens outside the pipeline. Because if your system can’t be rebuilt from Git, you don’t control it. #GitOps #PlatformEngineering #CI/CD

Jenkins CI/CD Mastery – Building a Real Pipeline Most people “learn” Jenkins by just clicking around the UI. I’m trying to go beyond that and actually understand how the full flow works — from code → build → artifact. 🔹 What I worked on today I set up Jenkins on a cloud VM and connected it to a GitHub repository. Then I configured a Maven build and automated the whole process — build, test, and package. The goal was simple: 👉 Stop doing manual builds and let Jenkins handle it. 🔹 Before touching Jenkins… I first looked at the project itself. Checked: • pom.xml (dependencies and build config) • Project structure (main code vs test code) Honestly, this step is underrated. If you don’t understand what you’re building, your pipeline will eventually break — and you won’t know why. 🔹 Local testing (this saved me) Before running anything on Jenkins, I tested locally: mvn clean mvn test mvn package This helped me catch issues early instead of debugging inside Jenkins later. 🔹 Jenkins part Created a freestyle job, connected GitHub, and added: mvn clean test package Ran the build and tracked everything through console output. Finally saw the .jar file getting generated inside Jenkins workspace — small win, but satisfying. 🔹 Problems I faced Nothing worked perfectly (as expected): • Maven wasn’t installed → had to fix that • Port 8080 conflict → changed app port • Dependencies taking time → verified via logs This is where the real learning happened. 🔹 What I understood today • Always use clean builds — old files can mess things up • Console output is your best friend when debugging • Even a small mismatch (Java/Maven version) can break everything • Automation only works if your basics are clear #DevOps #Jenkins #CICD #Maven #LearningInPublic #Cloud Vikas Ratnawat CloudDevOpsHub Community

🚀 𝟗𝟎 𝐃𝐚𝐲𝐬 𝐨𝐟 𝐃𝐞𝐯𝐎𝐩𝐬 | 𝐋𝐞𝐚𝐫𝐧𝐢𝐧𝐠 𝐢𝐧 𝐏𝐮𝐛𝐥𝐢𝐜 | 𝐇𝐚𝐧𝐝𝐬-𝐎𝐧 | 𝐏𝐫𝐨𝐣𝐞𝐜𝐭𝐬 🌳 Branching out into Version Control: My First Git Repo! Day 22 of #90DaysOfDevOps is done! ✅ Today, I transitioned from scripting to mastering Git—the absolute backbone of DevOps and modern software engineering. 👨💻 I set up my global config, initialized my first repository, and got hands-on with the core workflow: Working Directory ➡️ git add (Staging) ➡️ git commit (Repository). ✅ git init → git add → git commit → Repeat! 💡 Biggest Aha! Moment: Understanding the Staging Area. It isn’t just an extra annoying step; it’s a drafting space that lets you group related changes together before sealing them into a commit, keeping the project history clean and logical! 🔗💻 GitHub Repo: https://lnkd.in/dZsmFiQT #90DaysOfDevOps #DevOpsKaJosh #TrainWithShubham #Git #GitHub #VersionControl #DevOpsJourney

🚀 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