90DaysOfDevOps: Git & Docker Fundamentals to Industry Level

We cut our deployment time from 47 minutes to 9 minutes using GitHub Actions. Here is what actually moved the needle. Not the flashy stuff. The boring stuff. 1. We stopped running the full test suite on every commit. Using pytest -k with changed-file detection, we ran only relevant tests. Saved ~11 minutes immediately. 2. We parallelised Docker layer caching properly. We were using cache, but pulls were still sequential in our workflow. Fixing that shaved off another 6–7 minutes. 3. We removed a manual approval gate that had been sitting in our pipeline since a production incident in 2022. No one on the team of 5 engineers could explain why it still existed. 4. We built a shared base image for our microservices instead of each service installing the same ~350MB of dependencies separately. The bottleneck in your pipeline is almost never where you think it is. Profile it first. Then fix it. What is the biggest time sink in your current pipeline? #CICD #DevOps #PlatformEngineering #GitHubActions #Docker

Day 23 of learning and practicing DevOps 🔁 Explored some more concepts in Git — branching Worked on: • Creating and switching branches (feature-1, feature-2) • Making isolated commits without affecting main • Understanding git switch vs git checkout • Connecting local repo to GitHub and pushing branches • Learning git pull vs git fetch • Understanding clone vs fork and real workflows Important part: Git doesn’t just track files, it tracks versions across timelines. Learning today --> branching = safe development Here are my notes: https://lnkd.in/gxDM974h 📍 #DevOps #Git #VersionControl #GitHub #LearningInPublic #90DaysOfDevOps #TrainWithShubham 🚀

🚀 Learning Update | CI/CD, Security & DevOps Here’s what I worked on recently: 🔹 Test Coverage & Quality Added test coverage reporting and integrated a coverage badge into the project. 🔹 Deployment Automation Implemented a deployment step to push Docker images to Docker Hub. 🔹 Security First 🔐 Integrated dependency security scanning to detect vulnerabilities early. 🔹 Pipeline Testing Tested the CI/CD pipeline across: • Push events • Pull requests • Manual triggers 🔹 Knowledge Sharing 🎥 Recorded a video explaining GitHub Actions CI/CD workflows and best practices. 🔹 Code & Documentation Pushed updated .github/workflows/ configurations with proper documentation. 🔹 Communication Improvement Continued reading The Power of Subconscious Mind to enhance clarity 🧠 Focusing on building reliable, secure, and automated development workflows. #DevOps #CI_CD #GitHubActions #Docker #SoftwareEngineering #LearningInPublic #GrowthMindset https://lnkd.in/dCGEJKek

I set up a GitHub Actions pipeline! 🚀 Now, every time I push code to the main branch, my application automatically redeploys to my Hostinger VPS. No more manual SSHing or dragging files—just clean, automated CI/CD. If you’re looking to level up your deployment game, I highly recommend checking out the video I followed. I've linked it in the first comment below! #Docker #GithubActions #DevOps #MERNStack #Hostinger #LearningInPublic #WebDevelopment #CodingLife

#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

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

A team of twelve agreed in a retrospective to adopt GitHub Flow. No more long-lived feature branches. PRs against main. CI required before merge. They documented it in the team wiki. Two weeks later, a senior developer under pressure pushed directly to main. CI was skipped. A bug was introduced. A month later: a feature branch had been open for three weeks. Nobody had set a maximum lifetime expectation. By month's end: back to the old pattern. The wiki said one thing. The repository enforced nothing. The next sprint, the team enabled branch protection rules: ✔ Direct push to main: disabled for everyone ✔ CI must pass before merge ✔ Minimum 1 reviewer required Within two weeks: the agreed process was the actual process. The lesson: A branching strategy documented in a wiki is an aspiration. A branching strategy enforced by repository configuration is a standard. 15 minutes to configure branch protection. That is the difference between "we agreed to do this" and "we actually do this." Does your team enforce its Git standards in the configuration, or just in the documentation? Does your main branch have branch protection enabled? Y / N. If N, I will walk through setup. #Git #TechLeadership #EngineeringCulture #DevOps #SoftwareEngineering

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

I just built my first CI/CD pipeline from scratch. It broke 10+ times before it worked. Here's what happened. As part of my DevOps bootcamp (TechWorld with Nana), I set up a complete Jenkins pipeline for a NodeJS application. The goal: every code change should be automatically tested, built into a Docker image, pushed to Docker Hub, and versioned — no manual steps. The setup: • Ubuntu VM running on VirtualBox • Jenkins running as a Docker container with the host's Docker socket mounted • Jenkinsfile defining 5 pipeline stages: version bump, test, build, push, commit • GitLab for source code, Docker Hub for images What went wrong (and what I learned): First, GitLab authentication broke the pipeline. My password had special characters that mangled the git URL. The fix: use a Personal Access Token instead. Lesson — never use passwords with special characters in CI/CD URLs. Tokens are safer and cleaner. Then, Jenkins couldn't build Docker images. "Permission denied" on the Docker socket. Even though the socket was mounted, Jenkins runs as a non-root user. The fix: chmod 666 on the socket inside the container. Lesson — mounting a socket isn't enough, the permissions have to match. The result: a fully automated pipeline that increments the app version, runs tests (pipeline stops if tests fail), builds a Docker image with the new version tag, pushes it to Docker Hub, and commits the version bump back to GitLab. One command triggers all of this. That's CI/CD. Biggest takeaway: CI/CD isn't just about writing a Jenkinsfile. It's about understanding how Jenkins, Docker, Git, and your application all connect. You're the bridge between all these tools. Module 8 progressing. Still building, still breaking things, still learning. #DevOps #Jenkins #CICD #Docker #Pipeline #GitLab #Automation #LearningInPublic #CareerChange #TechWorldWithNana