Automate CI/CD with Jenkins, Maven, Docker, and GitLab

🔧 Lab Title: 6 - Docker in Jenkins 🐳 Project Steps PDF Your Easy-to-Follow Guide:https://lnkd.in/gBSpd7uc 🔗 GitLab Repo Code:https:https://lnkd.in/gm7-QuWM 🔗 DevsecOps Portfolio:https://lnkd.in/g6AP-FNQ 💼 DevOps Portfolio: https://lnkd.in/gT-YQE5U 🔗 Kubernetes Portfolio:https://lnkd.in/gUqZrdYh 🔗 GitLab CI/CD Portfolio:https://lnkd.in/g2jhKsts Summary:  Today, I worked on 6 - Docker in Jenkins, where I integrated Docker with Jenkins to automate building and pushing Docker images to Docker Hub and Nexus repositories. I explored key concepts such as Docker containerization, Jenkins pipeline automation, Docker Hub and Nexus registry management, and secure Docker credential handling. This lab involved setting up Docker inside the Jenkins container, building Docker images from Java JAR files, and automating the push of these images to public and private registries, ensuring a consistent and portable CI/CD pipeline. 🚀🐳 Tools Used: Jenkins: Orchestrated CI/CD pipelines and managed Docker container builds inside Jenkins jobs. Docker: Built, managed, and pushed container images from Java applications. Docker Hub: Hosted and shared Docker images publicly. Nexus Repository: Served as a private Docker registry for secure internal image storage. Skills Gained: Docker & Jenkins Integration: Enabled Jenkins to access Docker daemon for container management. Docker Image Creation: Wrote Dockerfiles and built images for Java apps for containerized deployment. Docker Registry Management: Learned to push images securely to Docker Hub and Nexus, handling credentials properly. Challenges Faced: Permissions on Docker Socket: Adjusted socket permissions (chmod 666) inside Jenkins container to enable Docker commands. Insecure Registry Configuration: Configured Docker daemon to trust Nexus as an insecure registry for image pushes. Why It Matters:  This lab is critical for modern DevOps workflows as it teaches how to containerize applications and automate their build and deployment through Jenkins. By integrating Docker and Jenkins, I ensure consistent, repeatable builds and seamless deployment of containerized applications across environments. These skills enable scalable, reliable CI/CD pipelines essential for cloud-native and microservices architectures. 🧱⚙️ 📌 hashtag#DevOps hashtag#Jenkins hashtag#Docker hashtag#CI_CD hashtag#Containerization hashtag#Automation hashtag#TechLearning hashtag#DevOpsJourney 🚀 Stay tuned!  The next project 8 - Intro to Pipeline Job is coming soon. 🔥

🔧 Lab Title: 14 - Jenkins Shared Library 🚀🐳 Project Steps PDF Your Easy-to-Follow Guide :https://lnkd.in/gC8QP5-B 🔗 GitLab Repo Code:https:https://lnkd.in/gms5D4YC 🔗 DevsecOps Portfolio:https://lnkd.in/g6AP-FNQ 💼 DevOps Portfolio: https://lnkd.in/gT-YQE5U 🔗 Kubernetes Portfolio:https://lnkd.in/gUqZrdYh 🔗 GitLab CI/CD Portfolio:https://lnkd.in/g2jhKsts Summary:  Today, I worked on building a scalable CI/CD pipeline using Jenkins Shared Libraries for a microservice-payment project. I created pipeline jobs integrated with reusable Groovy scripts to automate build, Docker image creation, and deployment. Key concepts included Jenkins Shared Libraries, Docker automation, secure credential injection, and modular pipeline design—leveraging GitLab for version control and Jenkins for orchestration. This setup streamlines microservice pipelines, improving maintainability and security. Tools Used: Jenkins: Pipeline orchestration and shared library management 🧱 GitLab: Source control and shared library repo 🗃️ IntelliJ IDEA: Groovy scripting and library development 💻 Docker: Automated container image build and push 🐳 Groovy: Writing reusable pipeline logic scripts ✍️ Skills Gained: Shared Libraries: Modularized pipeline logic for reuse across microservices ♻️ Secure Credential Management: Injected Docker Hub credentials safely in pipelines 🔐 Docker Automation: Automated image build, login, and push processes 🐋 SCM & Collaboration: Managed Jenkins libraries and pipeline code in GitLab 🌐 Pipeline Modularization: Made maintainable and scalable CI/CD pipelines ⚙️ Challenges Faced: Configuring explicit shared library loading after removing global trusted libraries 🔧 Securing Docker credentials to avoid leaks during CI runs 🛡️ Structuring reusable Groovy functions and classes for clean pipeline code 📦 Why It Matters:  This lab sharpened my ability to create secure, scalable CI/CD pipelines with reusable components, critical for efficient microservice delivery. Mastering Jenkins Shared Libraries and Docker automation empowers faster, safer deployments—key for modern DevOps roles. 📌 hashtag#DevOps hashtag#Jenkins hashtag#SharedLibraries hashtag#CI_CD hashtag#Docker hashtag#Groovy hashtag#Automation hashtag#SecureCredentials hashtag#Microservices hashtag#DevOpsJourney 🚀 Stay tuned!  The next project  15 - Webhooks - Trigger Pipeline Jobs automatically is coming soon. 🔥

🚀 Day 8 of #100DaysOfDevOps — Jenkins Pipeline Job Type. Freestyle got us started. Pipeline takes everything to production level. Here's everything you need to know. 👇 🔷 What is a Jenkins Pipeline? 1. Automates the entire journey of code from developer to production 2. Written as code in a file called Jenkinsfile 3. Stored inside your GitHub repo — versioned like any other code 4. Survives Jenkins restarts — Freestyle jobs do not 5. Industry standard for CI/CD in every serious DevOps team 🔷 How It Works — Simple Flow Code pushed to GitHub ↓ Webhook triggers Jenkins ↓ Jenkins reads Jenkinsfile ↓ Stages run one by one ↓ Artifacts stored · Team notified ✅ 🔷 Two Types of Syntax 1. Declarative → cleaner · structured · recommended for beginners and most teams 2. Scripted → full Groovy code · more flexible · used for complex logic only 👉 Start with Declarative. Always. 🔷 Basic Declarative Pipeline pipeline { agent any stages { stage('Checkout') { steps { git 'https://lnkd.in/gTJ5x5Xi' } } stage('Build') { steps { sh 'mvn clean package' } } stage('Test') { steps { sh 'mvn test' } } stage('Deploy') { steps { sh './deploy.sh' } } } post { success { echo 'Pipeline passed ✅' } failure { mail to: 'team@company.com', subject: 'Build Failed ❌' } } } 🔷 Key Sections — What Each One Does 1. agent → where the pipeline runs 2. environment → variables shared across all stages 3. stages → container for all your stages 4. stage → one phase of the pipeline → Build / Test / Deploy 5. steps → the actual commands that run 6. post → what happens after → success / failure / always 🔷 Agent Types agent any → run on any available node agent { label 'linux-slave' } → run on a specific slave agent { docker 'maven:3.8' } → run inside a Docker container 🔷 Parallel Stages — Run Multiple Jobs at Once -> Run Unit Tests · Integration Tests · Code Quality at the same time -> Cuts total testing time by up to 60% -> Not possible in Freestyle — Pipeline only ✅ 🔷 Where Should Jenkinsfile Live? ✅ Always store in GitHub repo root → Pipeline script from SCM ❌ Never write directly in Jenkins UI → not version controlled Every change tracked in Git history → full audit trail 🔷 3 Things That Clicked for Me 1. post { always } → cleanup after every build 2. when { branch 'main' } → deploy from main only 3. input → manual approval before production 🔷 Real-World in my Organisation Jenkinsfile lived inside every microservice repo Push code → pipeline runs automatically Manual approval before every production deploy Full pipeline done in under 8 minutes ✅ 📄 Want this as a ready-to-use template? DM me. Still using Freestyle or already on Pipeline as Code? Drop it below 👇 #100DaysOfDevOps #Jenkins #JenkinsPipeline #Jenkinsfile #CICD #DevOps #Automation #AWS #CloudEngineering #LTIMindtree #PipelineAsCode #BuildAutomation

🔧 Lab Title: 5 - Jenkins Basics Demo - Freestyle Job 🚀 Project Steps PDF Your Easy-to-Follow Guide:https://lnkd.in/g4xg4uBg 🔗 GitLab Repo Code:https://lnkd.in/g5Xt4HQz 🔗 DevsecOps Portfolio:https://lnkd.in/g6AP-FNQ 💼 DevOps Portfolio: https://lnkd.in/gT-YQE5U 🔗 Kubernetes Portfolio:https://lnkd.in/gUqZrdYh 🔗 GitLab CI/CD Portfolio:https://lnkd.in/g2jhKsts Summary:  Today, I worked on 5 - Jenkins Basics Demo - Freestyle Job, where I created and configured Jenkins freestyle and Maven jobs to verify tool installations, integrate GitLab repositories, and automate Java application builds. I explored concepts such as Jenkins job configuration, NodeJS plugin setup, Git SCM integration, and Maven build lifecycle. I applied these to automate build verification and run unit tests through CI/CD pipelines. This lab also involved setting up Jenkins with plugins and shell scripts to automate testing and packaging processes, focusing on creating a reliable and efficient continuous integration environment. 🔧🧪 Tools Used: Jenkins: Created freestyle and Maven jobs for CI/CD automation. NodeJS Plugin: Installed and configured for Node.js integration in Jenkins. Git: Managed source code and linked GitLab repositories to Jenkins jobs. Maven: Automated Java unit testing and packaging inside Jenkins. Skills Gained: Jenkins Job Configuration: Built and managed freestyle and Maven jobs with build steps and plugins. CI/CD Pipeline Setup: Linked SCM branches, ran build scripts, automated tests and packaging. Tool Integration: Connected Jenkins with NodeJS, Git, and Maven for seamless automation. Challenges Faced: NodeJS Plugin Setup: Added and removed build steps for NodeJS to keep the job clean. Branch-Specific Builds: Configured Jenkins to pull the exact GitLab branch using proper specifiers. Why It Matters:  This lab provides hands-on experience in automating software builds and tests using Jenkins and related tools. It shows how integration with source control and build automation enhances software delivery efficiency and reliability. Mastering Jenkins freestyle and Maven jobs helps me streamline CI/CD workflows, reduce manual steps, and improve software quality — critical skills for any modern DevOps or Cloud infrastructure role. ⚙️💡 📌 hashtag#DevOps hashtag#Jenkins hashtag#FreestyleJob hashtag#CI_CD hashtag#Automation hashtag#TechLearning hashtag#DevOpsJourney 🚀 Stay tuned!  The next project 6 - Docker in Jenkins is coming soon. 🔥

🗓️ Day 34/100 — 100 Days of AWS & DevOps Challenge Today crossed into automation territory. Git hooks — scripts that fire automatically on Git events. The task: Merge feature into master, create a post-update hook that auto-generates a release tag every time master is pushed, test it, and confirm the tag exists. The hook itself is 8 lines: #!/bin/bash for ref in "$@"; do   if [ "$ref" = "refs/heads/master" ]; then     TAG_NAME="release-$(date +%Y-%m-%d)"     git tag "$TAG_NAME"     echo "Created release tag: $TAG_NAME"   fi done Drop this in /path/to/git/hooks/post-update, make it executable, push to master — and every push to master from that point creates a dated release tag automatically. Three things that must be right for hooks to work: 1. Location matters — bare repo, not working clone - The post-update hook goes in /path/to/git/hooks/ — the bare server-side repo. Not in /path/to/git/.git/hooks/. Client-side hooks in the working clone run on the developer's machine. Server-side hooks in the bare repo run when a push arrives at the server. Completely different contexts. 2. Executable permission is not optional $ chmod +x /path/to/git/hooks/post-update - Git silently skips hooks that aren't executable. No error, no warning, nothing fires. Always verify with ls -la before testing. 3. Check the right ref - The hook receives every updated ref as an argument. Without the [ "$ref" = "refs/heads/master" ] check, the hook fires on every branch push. With it, release tags only get created when master specifically is updated. Why this matters beyond the lab: - Before GitHub Actions, Jenkins, and GitLab CI became the standard — post-receive and post-update hooks were how many teams deployed applications. Push to master, hook fires, code gets pulled to the server. Simple, fast, zero external dependencies. Even today, many small teams use exactly this pattern for internal tooling and staging deployments. Full hook guide + deployable script on GitHub 👇 https://lnkd.in/gtc-KHG4 #DevOps #Git #GitHooks #Automation #CICD #Linux #100DaysOfDevOps #KodeKloud #LearningInPublic #CloudEngineering #GitOps #ReleaseManagement

🔧 Lab Title: 9 - Jenkinsfile Syntax 🔥 🔗 GitLab Repo Code:https:https://lnkd.in/gM_f6kDc Project Steps PDF Your Easy-to-Follow Guide:https://lnkd.in/gYtrRNtt 🔗 DevsecOps Portfolio:https://lnkd.in/g6AP-FNQ 💼 DevOps Portfolio: https://lnkd.in/gT-YQE5U 🔗 Kubernetes Portfolio:https://lnkd.in/gUqZrdYh 🔗 GitLab CI/CD Portfolio:https://lnkd.in/g2jhKsts Summary:  Today, I worked on Jenkinsfile Syntax, where I created and refined Jenkins pipeline jobs integrating with GitLab SCM and Groovy scripting. I explored concepts such as multi-stage pipeline automation 🚀, parameterization 🎛️, conditional stage execution ⚙️, external script loading 📜, manual approvals ✋, and multi-environment deployment prompts 🌐. I applied these concepts to automate builds and deployments, improving maintainability and control over CI/CD workflows by leveraging pipeline-as-code and user input features. Tools Used:  Jenkins: ⚙️ Configured and managed pipelines with declarative Jenkinsfile scripts.  GitLab SCM: 🗃️ Source repository hosting Jenkinsfiles and Groovy helper scripts.  Groovy: 🖋️ Externalized pipeline logic into reusable scripts to improve maintainability. Skills Gained:  Pipeline as Code: 💻 Defined and linked Jenkins pipelines directly from GitLab SCM.  Parameterized Pipelines: 🎛️ Built dynamic pipelines with user inputs to control versions and test execution.  Manual Approval Gates: ✋ Implemented input steps for deployment environment selection and manual approval.  Pipeline Modularization: 🧩 Learned to separate pipeline logic using external Groovy scripts for cleaner Jenkinsfiles.  Multi-environment Deployment: 🌐 Configured pipelines to deploy to multiple environments based on runtime input. Challenges Faced:  Conditional Stage Execution: 🛠️ Overcame by using when directive with parameter-based expressions.  User Input Handling: 🔄 Managed complex input parameters for single and multiple environment selections in deployment stages. Why It Matters:  This lab builds critical expertise in Jenkins pipeline syntax and CI/CD automation. By mastering parameterized pipelines, input-driven deployment controls, and external script integration, I gained the ability to craft flexible, maintainable, and safe DevOps workflows essential for modern software delivery and cloud-native applications. 📌 hashtag#DevOps hashtag#Jenkins hashtag#FreestyleJob hashtag#CI_CD hashtag#Automation hashtag#TechLearning hashtag#DevOpsJourney 🚀 Stay tuned!  The next project 10 - Create complete Pipeline is coming soon. 🔥

Your Kubernetes cluster is a mess. And you do not even know it yet. Someone changed a config manually last week. A deployment broke yesterday but nobody knows why. Your cluster does not match your code anymore. This is the reality without GitOps. Here is what GitOps actually solves: Traditional deployments are chaotic. You run kubectl commands. Make manual changes. Fix things on the fly. Everything works until it does not. Then you have no idea what changed. No way to roll back cleanly. No source of truth. GitOps flips this completely. It makes Git the single source of truth for everything. Not just your code. Everything. Deployments. Services. ConfigMaps. Secrets. Policies. All written as YAML. Stored in Git. Automatically applied to your cluster. If it is not in Git, it does not exist. Here is how it works: You do not push changes to Kubernetes anymore. Kubernetes pulls changes from Git. You update a YAML file in Git. Commit it. Push it. A GitOps tool like Argo CD or Flux sees the change. It compares what is in Git to what is running in your cluster. Finds the difference. Fixes it automatically. No SSH. No manual kubectl commands. No emergency hotfixes that nobody documents. This solves five huge problems: Problem one is configuration drift. Your cluster changes over time. Manual tweaks here. Emergency fixes there. Debug commands someone ran at 2 AM. Now production is different from what you thought it was. GitOps constantly syncs everything back to Git. Drift gets fixed automatically. Problem two is no audit trail. Who changed what? When? Why? Traditional deployments? You guess. GitOps? Every change is a Git commit. Full history. Clear accountability. Easy rollback. Problem three is broken deployments causing panic. Bad update hits production. Now what? Manually roll back? Try to remember the old config? Hope for the best? GitOps gives you one-click rollback. Just revert the Git commit. Done. Problem four is human error with kubectl. Even experts mess up. Wrong file. Wrong cluster. Typo in the command. Production goes down. GitOps removes direct cluster access. No risky manual commands. Everything goes through Git. Problem five is inconsistent environments. Dev looks different from staging. Staging looks different from prod. Nobody knows why anymore. GitOps enforces the same config everywhere. Same process. Same reliability. The core idea is simple: Git is your desired state. Your cluster is the actual state. GitOps tools compare both constantly. Fix any differences automatically. This is called continuous reconciliation. The tool runs a loop. Does the cluster match Git? If not, fix it. Always watching. Always correcting. This is why top teams use GitOps: Faster deployments. Better security. Full audit trail. Easy rollbacks. Automation at scale. #GitOps #Kubernetes #ArgoCD #DevOps #CICD #K8s #CloudNative #Infrastructure #Automation #DevSecOps

Day 40: Reusing Code with GitLab CI Templates - Stop Copy-Pasting Your Pipeline! Friends, yesterday we talked about Conditional Jobs. Today, let's discuss something that will save you SO much time every week. Think about it - you have 5-10 projects, and each one needs the same build, test, deploy steps. What do we usually do? We copy-paste the .gitlab-ci.yml file again and again. And when something changes, you have to update all those files. So much work, na? This is exactly where GitLab CI Templates come in handy. What are GitLab CI Templates? Simply put, templates are like a saved recipe. You write your pipeline steps ONCE, and then you can use that same recipe in any project. No copy-pasting at all! Simple Example: Instead of writing the same test job in every project: test:  stage: test  script:   - npm install   - npm test You create a template file and just include it: include:  - local: '.gitlab-ci-templates/test.yml' Now your .gitlab-ci.yml is short and clean! Types of Templates in GitLab: 1. Local Templates   - Stored in your own project   - Best for common jobs within a project   - Easy to use and manage 2. Project Templates   - Stored in a separate GitLab project   - Any project can include it   - Perfect for company-wide standards 3. Remote Templates   - Stored on any Git server (GitHub, GitLab, etc.)   - Good for open-source or multiple organizations 4. Built-in Templates   - GitLab gives you some ready-made templates   - Useful for common frameworks like Node.js, Python, Java Real-World Example: Let's say your company has a standard security scan that must run on EVERY project. Old way (copy-paste): You write the security scan job in 20 different .gitlab-ci.yml files. When the scan tool changes, you update 20 files. So painful! New way (template): You create ONE template file with the security scan. All 20 projects just include that one template. When the scan tool changes, you update just ONE file. So easy! How to Create and Use Templates: Step 1: Create a template file .gitlab-ci-templates/common-build.yml: build_job:  stage: build  script:   - echo "Building application"   - npm install   - npm run build Step 2: Include it in your pipeline .gitlab-ci.yml: include:  - local: '.gitlab-ci-templates/common-build.yml' deploy:  stage: deploy  script:   - echo "Deploying to production" Done! Your build job now comes from the template. Pro Tips: 1. Keep templates small - one job per file 2. Name them clearly - like build-node.yml, test-python.yml 3. Use project templates for company standards 4. Version your templates just like your code 5. Always test template changes in a non-production project first So friends, remember - templates help you write less code and make it easier to maintain. No more copy-pasting pipelines everywhere! That's it for Day 40! Tomorrow we will learn about GitLab CI Environments and Deployments. #GitLab #CICD #DevOps #Templates

JENKINS: 🚀 Understanding CI/CD & Jenkins – 🔹 What is CI (Continuous Integration)? >CI means integrating code changes frequently into a shared repository. 👉 Every time a developer pushes code: Code is integrated Build is triggered Tests are executed 💡 Simple meaning: CI = All steps involved in integrating code changes automatically 🔹 What is CD (Continuous Delivery vs Continuous Deployment)? CD has two meanings 👇 1️⃣ Continuous Delivery Code is automatically built & tested Ready for deployment But manual approval required for production 👉 Used when: You need control before release Production deployments must be reviewed 2️⃣ Continuous Deployment Code is automatically deployed to production No manual intervention 👉 Used when: Fully automated pipelines High confidence in testing Fast product releases 🔥 Key Difference Delivery → Manual approval before production Deployment → Fully automatic release 🔹 CI/CD Pipeline Flow A typical CI/CD pipeline looks like this 👇 1️⃣ Version Control (Git) 2️⃣ Build Application 3️⃣ Unit Testing 4️⃣ Code Quality Checks 5️⃣ Security Scanning 6️⃣ Package / Artifact Creation 7️⃣ Deploy to Dev/QA 8️⃣ Deploy to Production 💡 Goal: 👉 Automate everything from code commit → deployment 🔹 Introduction to Jenkins Jenkins is an open-source automation server used to implement CI/CD pipelines. 👉 It helps: Automate build Run tests Deploy applications 💡 In simple terms: Jenkins = Tool that automates your CI/CD pipeline 🔹 Jenkins Architecture (Basic) Master (Controller) → Manages jobs Agent (Node) → Executes jobs 🔹 Jenkins Installation (Step-by-Step) Here’s how I installed Jenkins on a Linux system 👇 1️⃣ Install Java (Prerequisite) yum install java-17-amazon-corretto 2️⃣ Add Jenkins Repository sudo wget -O /etc/yum.repos.d/jenkins.repo \ https://lnkd.in/g3D6sWk8 3️⃣ Install Jenkins yum install jenkins -y 4️⃣ Start Jenkins Service systemctl start jenkins 5️⃣ Check Status systemctl status jenkins 6️⃣ Unlock Jenkins Open browser: http://<server-ip>:8080 Get initial password from: /var/lib/jenkins/secrets/initialAdminPassword 7️⃣ Install Plugins Install Suggested Plugins 8️⃣ Create Admin User Set username & password ✅ Now Jenkins is ready to use 🎉 🔹 Real-Time Flow Developer → Push Code → Git → Jenkins → Build → Test → Deploy 💡 Final Thoughts CI/CD helps automate software delivery Jenkins is one of the most powerful tools to implement it Understanding CI vs CD is crucial for real-world projects 🎯 Key Takeaway 👉 CI/CD = Faster, reliable, and automated software delivery 👉 Jenkins = Backbone of CI/CD pipelines

Production-Style CI/CD Pipeline for Python Application using GitHub Actions and Kubernetes (Minikube) Act as a Senior DevOps Engineer, Kubernetes Expert, and Trainer. Create a complete real-world DevOps hands-on project demonstrating an end-to-end CI/CD pipeline using GitHub Actions for a Python Flask application, containerized with Docker and deployed to Kubernetes using Minikube (local cluster). The tutorial must be practical, beginner-friendly, and step-by-step, with clear explanations and real code examples. Include the following sections: Project Architecture Explain the overall DevOps workflow. Show a simple architecture diagram like: Developer → GitHub → GitHub Actions → Build & Test → Docker Image → Push to Docker Hub → Deploy to Kubernetes → Run on Minikube Create Python Flask Application Build a simple API with endpoints: / → returns "Hello DevOps" /health → returns health status Provide full code for: app.py requirements.txt Project Directory Structure python-devops-project/ ├── app.py ├── requirements.txt ├── Dockerfile ├── tests/ │ └── test_app.py ├── k8s/ │ ├── deployment.yaml │ └── service.yaml ├── helm/ │ └── python-app-chart/ └── .github/ └── workflows/ └── ci-cd.yml Git and GitHub Setup Provide commands to: Initialize git Commit code Push to GitHub repository Docker Containerization Create a production-ready Dockerfile. Explain each Docker instruction. Show commands: docker build -t python-devops-app . docker run -p 5000:5000 python-devops-app Minikube Setup Explain installation and usage of: Docker Kubectl Minikube Commands: minikube start kubectl get nodes Kubernetes Deployment Provide complete Kubernetes manifests: deployment.yaml service.yaml Show commands: kubectl apply -f k8s/ kubectl get pods kubectl get services Access Application minikube service python-service Helm Chart Deployment Create a basic Helm chart for the application. Explain how Helm simplifies Kubernetes deployments. GitHub Actions CI/CD Pipeline Create .github/workflows/ci-cd.yml including stages: Checkout repository Setup Python Install dependencies Run unit tests using pytest Build Docker image Login to Docker Hub Push Docker image Update Kubernetes deployment Secrets Management Explain how to store: Docker Hub username Docker Hub password using GitHub Secrets. End-to-End Pipeline Flow Show complete CI/CD flow: Developer Push Code ↓ GitHub Repository ↓ GitHub Actions Triggered ↓ Install Dependencies ↓ Run Tests ↓ Build Docker Image ↓ Push Image to Docker Hub ↓ Update Kubernetes Deployment Application Running on Minikube Ensure the tutorial is hands-on, practical, and easy for beginners learning DevOps and Kubernetes. https://lnkd.in/gWCksXaN