#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

🚀 CI/CD with Jenkins vs GitHub Actions — what should you actually use? I’ve been exploring CI/CD while working on backend projects, and one thing became clear — both Jenkins and GitHub Actions solve the same problem, but in very different ways. Here’s how I see it: 🔧 Jenkins Feels like the “full control” option. You can customize almost everything, build complex pipelines, and manage it exactly the way you want. But… you also have to set it up, maintain it, and deal with plugins and servers. ⚡ GitHub Actions Much simpler to start with. If your code is already on GitHub, you just write a workflow file and you’re good to go. No server setup, no extra headache. 🧠 The real difference (in simple terms): Jenkins → more control, more responsibility GitHub Actions → less setup, faster to start 🔥 One important thing I misunderstood earlier: Docker helps you run your app consistently, but tools like Jenkins or GitHub Actions decide: 👉 when to build 👉 when to test 👉 when to deploy 💡 So what should you use? If you’re working on large or complex systems → Jenkins makes sense If you want quick setup and clean workflow → GitHub Actions is a great choice At the end of the day, both are powerful. It just depends on your use case. #cicd #devops #jenkins #githubactions #docker

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

#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

🚀 Automate Code Sync Across Repositories with GitHub Actions! Ever needed to push your code to another repository automatically? Whether it's for maintaining a mirror repo, deployment, or syncing across teams — GitHub Actions makes it seamless! 💡 Here’s a quick overview of how you can achieve this: 🔹 Step 1: Create a Personal Access Token (PAT) Generate a token with repo access from your GitHub account. 🔹 Step 2: Add Token as Secret Go to your source repository → Settings → Secrets → Add your PAT (e.g., TARGET_REPO_TOKEN). 🔹 Step 3: Configure GitHub Action Workflow name: Sync to Another Repo on: push: branches: - main <branch name> jobs: sync: runs-on: ubuntu-latest steps: - name: Checkout Source Repo uses: actions/checkout@v3 - name: Push to Target Repo run: | git config --global user.name "GitHub Actions" git config --global user.email "actions@github.com" git clone https://<TOKEN>@https://lnkd.in/djBb7BHB rsync -av --delete ./ target-repo/ cd target-repo git add . git commit -m "Sync from source repo" git push origin main ⚡ Use Cases: Maintain backup repositories Sync code between private & public repos Automate deployments #GitHubActions #DevOps #Automation #CI_CD #SoftwareDevelopment

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

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

🚀 What is GitHub Actions & Why Should Developers Use It? Most developers push code to GitHub… But the real power lies in automating everything ⚡ ⚙️ What is GitHub Actions? It’s a built-in CI/CD tool that helps you automate your workflows directly inside your repository 👉 No need for external tools like Jenkins for basic setups 🧠 How it works (Simple): 1️⃣ You push code 2️⃣ Workflow triggers automatically 3️⃣ It builds your project 4️⃣ Runs tests 5️⃣ Deploys your app 🚀 📦 Real Example: Every time you push to main: Code builds automatically Tests run App gets deployed to server 👉 No manual effort 😎 🔥 Why should you use it? 🚀 Automation No more manual build & deploy ⏱️ Saves Time Everything runs in seconds 🐞 Early Bug Detection Tests run on every commit 📈 Industry Standard CI/CD is a must-have skill 🔗 Seamless Integration Works perfectly with GitHub repos ⚡ Bonus: You can also: Run jobs on PRs Schedule tasks Deploy specific services (Monorepo setup) 💡 Simple thought: “If your deployment is manual… you’re doing extra work.” Are you using GitHub Actions or still doing manual deployments? 🤔 #GitHub #DevOps #CICD #SoftwareEngineering #Automation

Day 26 – GitHub CLI (gh): Manage GitHub from Your Terminal Today I explored how to use the GitHub CLI to manage everything without leaving the terminal — from creating repos to handling PRs and issues. 💡 Key Learnings: Installed & authenticated gh Created and managed repositories directly from terminal Worked with issues (create, view, close) Created & merged pull requests without browser Explored GitHub Actions workflows using CLI Discovered powerful commands like gh api, gh alias, and gh search Biggest takeaway: No more context switching between terminal and browser — everything can be automated and managed efficiently using gh. #90DaysOfDevOps #DevOpsKaJosh #TrainWithShubham #GitHubCLI #DevOps #Automation #CLI #Git #LearningInPublic #CloudComputing #Scripting #DeveloperJourney

Pipeline diagram to visualize the flow.It captures the whole lifecycle at a glance: Code → Build → Dockerize → Push → Deploy On the left: Jenkins pipeline stages. On the right: GitHub Actions workflow stages. Both converge at Docker Hub, then deploy into Kubernetes. This way you can revise visually: Blue side = Jenkins (Checkout → Build/Test → Docker → Deploy). Gray side = GitHub Actions (Checkout → Build/Test → Docker → Deploy). Both end in Kubernetes cluster pods + service exposure. It’s the perfect one‑shot view for CI/CD journey. #devops #cicd #githubactions #jenkins