Nischal koirala’s Post

What happens after you push your code to Git? 🤔 Day 16 of my DevOps Journey Today I started learning Jenkins and understood the backbone of DevOps — CI/CD ⚙️🚀 Until now, I was just pushing code… But what happens after that? That’s where CI/CD comes in. CI/CD explained simply: Continuous Integration (CI) → Combination of build + test Whenever a developer commits code to Git: • Code is automatically fetched • Build process starts • Unit tests are executed This helps us quickly know whether new code works with existing code or breaks it Continuous Delivery vs Continuous Deployment: • Continuous Delivery → Code is ready for deployment (manual approval needed) • Continuous Deployment → Code is automatically deployed to production after build & test CI/CD Pipeline stages: Version Control • Code is pushed using tools like Git Build • Code is compiled and prepared for execution Unit Testing • Code is tested to validate functionality Deploy • Application is deployed to environments (Dev/Test/Prod) After deployment, we can see the actual output of the application Tools used for CI/CD pipelines: Jenkins, GitHub Actions, GitLab CI, Azure Pipelines, AWS Pipelines, Travis CI, CircleCI, Harness Day 16 realization💡 Writing code is just the beginning. The real power lies in what happens after the commit. CI/CD makes sure: ✔ Code is tested instantly ✔ Issues are caught early ✔ Deployment becomes fast and reliable Now imagine: The moment code is committed It automatically builds → tests → deploys That’s CI/CD. That’s automation replacing manual effort. This is where DevOps actually begins⚡ Next — I’ll go deeper into Jenkins pipelines🔥 See you on Day 17 with Jenkins Installation and Access🚀 #DevOps #Jenkins #CICD #Automation #LearningInPublic #100DaysOfDevOps #Day16 #Git #Linux

Git Series Finale: From Commands to Architecture — The Full 10-Day Roadmap 🏆 Today marks the end of my 10-Day Git Mastery Series. What started as learning basic commands evolved into understanding the high-level architecture required for enterprise-grade DevOps. Here is the complete blueprint of everything I’ve mastered: Phase 1: The Foundation (Days 1–3) Version Control Philosophy: Understanding why Git is the backbone of modern software reliability. The Three States: Mastering the flow between the Working Directory, Staging Area, and Local Repository. Branching Strategy: Implementing isolated feature branches to protect the production codebase. Phase 2: Collaboration & Conflict (Days 4–6) 3-Way Merges: Moving beyond simple linear updates to complex team integrations. Conflict Resolution: Developing the surgical precision needed to manually fix code collisions using editors like vi or nano. Recursive (ORT) Strategy: Understanding how Git logically determines the "Ostensibly Recursive Twin" during merges. Phase 3: The Safety Net (Days 7–8) Reset vs. Revert: Choosing between "destructive" history wiping and "auditable" professional reversals. Git Rebase: Rewriting history to maintain a perfectly linear, clean project timeline—the gold standard for senior engineers. Phase 4: Optimization & Release (Days 9–10) Squashing Commits: Consolidating messy development logs into single, high-impact feature commits. Git Stash: Mastering the "pause button" to switch priorities without losing uncommitted work. Annotated Tags: Creating official production release markers (v1.0, v2.0) for deployment audit trails. Engineering Reflection This series wasn't just about syntax; it was about System Integrity. In DevOps, Git is the source of truth. Mastering it means ensuring that every line of code is tracked, every mistake is reversible, and every release is documented. #GitMastery #DevOpsEngineer #100DaysOfCode #SoftwareArchitecture #VersionControl #GitWorkflow #CareerGrowth #TechCommunity

30 Days DevOps Revision Challenge – Day 2 Day 2 of my DevOps revision challenge — and today was all about going deeper into Jenkins and organizing everything I’ve learned so far. Yesterday was more about getting started and building a real pipeline. But today, I focused on strengthening almost all important Jenkins concepts in a more structured and practical way. 📌 Day 2 Focus: Advanced Jenkins Concepts Today I worked on multiple key areas to understand how Jenkins is actually used in real-world environments: 🔐 User-Based Authentication Explored how to manage users and roles Understood access control and security basics in Jenkins 📦 Shared Library (Deep Dive) Practiced creating and structuring shared libraries Improved reusability and organization of pipeline code 🔑 Credentials Management Learned how to securely store and use credentials Integrated credentials into pipelines safely 🔄 Build via SCM (GitHub Integration) Created jobs directly connected to GitHub repositories Automated build process using source code changes ⚡ Trigger Builds Without Opening Jenkins UI Configured builds to trigger directly from GitHub Used webhooks effectively for automation 🧑💻 Agent Setup Created and configured Jenkins agents Understood distributed builds and scalability 🔗 Webhook Optimization Used webhooks more efficiently Ensured proper trigger flow and debugging 💡 Key Takeaway Today felt like I connected all the scattered pieces of Jenkins into a complete system. From authentication → credentials → pipelines → agents → automation Everything now feels more organized and production-oriented. 🎯 Progress So Far Day 1: Pipeline + Django App + Shared Library basics Day 2: Advanced Jenkins concepts + full ecosystem understanding Slowly moving from just knowing tools → to actually understanding how everything fits together in production. I’ll continue sharing my journey daily. Consistency is the main goal 💯 If you’re also learning DevOps, let’s connect and grow together #DevOps #30DaysChallenge #Jenkins #CICD #Automation #Webhooks #LearningInPublic #Consistency #TechJourney

🚀 Day 7 of #100DaysOfDevOps Challenge Consistency is slowly turning into confidence! 💪 Today, I deepened my understanding of Git, one of the most essential tools in the DevOps ecosystem. Here’s what I explored: 🔹 Staging Changes with git add Learned how to stage specific files, multiple files, and entire directories before committing changes. 🔹 Staging vs Unstaging Understood how to move changes between the staging area and working directory using commands like git restore --staged. 🔹 Committing Changes Explored how to write meaningful commits and why good commit messages matter for collaboration and version tracking. 🔹 Best Practices for Commit Messages ✔️ Use imperative tone (e.g., “add”, “fix”) ✔️ Keep it short and descriptive ✔️ Focus on what and why, not how 🔹 Working with Remote Repositories git push to upload changes git pull to sync updates git clone to copy repositories 🔹 Branching in Git Learned how to create, switch, merge, and delete branches — a key concept for parallel development and team workflows. 💡 Git is not just about commands — it's about tracking progress, collaborating efficiently, and maintaining code integrity. Every command I learn is another step closer to becoming a better DevOps Engineer. 🌱 🔥 Keep learning. Keep building. Keep growing. #100DaysOfDevOps #DevOpsJourney #Git #VersionControl #LearnInPublic #TechLearning #CloudComputing #SoftwareEngineering #Linux #Automation #flm #ContinuousLearning #CareerGrowth #DevOpsEngineer #CodingJourney #BuildInPublic #TechCommunity #repost #DevSecOps #AIOps #MLOps #MultiCloud

🚀 Day 4/30: Git 101 – Version Control Mastery If you don’t understand Git, you don’t understand DevOps. Let’s simplify it 👇 Git = Version Control System It tracks every change in your code — who changed it, when, and why. ❌ Without Git: No clear history Difficult to rollback Code conflicts everywhere “Who broke this?” becomes a daily question ✅ With Git: Full change tracking (complete history) Easy rollback (seconds, not hours) Branching → work safely without affecting main code Code reviews → better quality before production 💡 Real scenario: A bug reaches production. With Git → identify the exact commit and rollback instantly. Without Git → hours of manual debugging. 🎯 Key Takeaway: Git is the foundation of DevOps. Master it. 💬 How does your team handle branching and rollbacks today? 👉 Stay tuned… Day 5 coming next! #Git #VersionControl #DevOps #AzureDevOps #CICD #SoftwareEngineering #LearningInPublic #DebugToDeploy

🚀 Day 6 of #100DaysOfDevOps Challenge Today I explored one of the most fundamental pillars of modern software development — Version Control Systems (VCS) and Git 🔥 📌 Here’s what I learned today: 🔹 What is Version Control System (VCS)? A system that tracks changes in code over time, enabling collaboration, history tracking, and easy rollback when needed. 🔹 Why is it important? ✔️ Maintains complete history of changes ✔️ Enables team collaboration ✔️ Supports branching & experimentation ✔️ Ensures code safety and integrity 🔹 What is Git & Why Git? Git is a distributed VCS known for its speed, flexibility, and powerful branching capabilities. It’s widely used in DevOps and CI/CD pipelines. 🔹 Git Stages Explained: 📂 Working Directory – Where you create/modify files 📌 Staging Area – Where changes are prepared (git add) 📦 Repository – Where changes are permanently stored (git commit) 🔹 Git Lifecycle: Modify ➝ Stage ➝ Commit ➝ Push ➝ Pull 🔹 Linux Commands to Install Git: sudo apt install git -y sudo yum install git -y sudo dnf install git -y 🔹 Git Logs: Tracking history using commands like: git log git log --oneline git log --graph 💡 Key Takeaway: Mastering Git is not optional — it’s a must-have skill for every DevOps Engineer to manage code efficiently and collaborate seamlessly. 📈 Every commit you make is a step closer to becoming a better engineer! 🔥 What’s next? Diving deeper into branching strategies and Git workflows! #DevOps #100DaysOfDevOps #Git #VersionControl #Linux #CloudComputing #SoftwareDevelopment #DevOpsJourney #LearningInPublic #TechGrowth #CI_CD #Automation #Programming #Developers #flm #Engineering #CareerGrowth #OpenSource #TechCommunity #BuildInPublic 🚀

Day 9 of my DevSecOps journey 🚀 Today I started learning Git — a version control system used to track changes in files and manage different versions of a project. 🔧 What I learned: • Git helps maintain multiple versions of the same file and track changes efficiently • It is open-source, platform-independent, and widely used in real-world projects 📂 Git workflow: • Working Directory → Where files are created/modified • Staging Area → Where files are prepared for commit • Repository → Stores committed files along with version history ⚙️ Basic commands I practiced: • git init – Initialize a repository (creates .git folder) • git status – Check file status • git add – Add files to staging area • git commit -m "message" – Save changes 📜 Other useful commands: • git log – View commit history • git log --oneline – Compact history view • git show – View commit details ⚙️ Configuration: • git config user.name – Set username • git config user.email – Set email This session helped me understand how version control works and how developers manage project history efficiently. Step by step, moving closer to real DevOps practices 🚀 #DevSecOps #Git #VersionControl #DevOps #CloudComputing #HandsOnLearning #LearningInPublic #TechJourney

☁️ Today’s DevOps Concept: Version Control in Infrastructure (Git + IaC) Continuing my 60‑day DevOps learning journey, today I built on yesterday’s Infrastructure as Code (IaC) concept by exploring how version control integrates with IaC. This connection is what truly transforms infrastructure into software. ✨ What I learned today: With IaC, every infrastructure change becomes a Git commit, and that unlocks some powerful advantages: 🔹 Traceability → Every change has a clear history 🔹 Collaboration → Multiple engineers can work on infrastructure safely 🔹 Review Process → Infra changes go through pull requests, just like code 🔹 Rollback Capabilities → Reverting infra becomes as easy as reverting a commit 🔹 Standardization → The entire organization follows the same templates & modules I practiced making small changes to a Terraform file, pushing it to Git, and watching how version control gives a complete picture of when and why each infrastructure change happened. Today’s biggest takeaway for me: “When your infrastructure is in Git, you gain control, visibility, and confidence.” Excited to dive into modules, state files, and automation next! #DevOps #IaC #Terraform #Git #CloudComputing #Automation #TechLearning

🚀 Day 38 – Git Branching & Merging 🌿🔀 Today I learned about Git Branching, one of the most powerful features in Git that helps teams work on multiple features without affecting the main code 💻 🌿 What is Git Branching? Branching allows us to create separate versions of code to work independently. 👉 Default branch: main / master 👉 Example: Create a new feature branch Work without disturbing main code ⚙️ Important Git Branch Commands 👉 Create branch: git branch feature1 👉 Switch branch: git checkout feature1 👉 Create + switch: git checkout -b feature1 👉 View branches: git branch 👉 Delete branch: git branch -d feature1 🔀 What is Merging? Merging is the process of combining one branch into another. 👉 Command: git merge feature1 ⚠️ Merge Conflicts Sometimes conflicts happen when: Two people edit the same file Changes overlap 👉 Solution: Manually fix the code Add and commit again 💡 Why Branching is Important? ✔ Safe development environment ✔ Multiple features can be developed simultaneously ✔ Easy collaboration in teams ✔ Keeps main code stable 📌 My Learning Today Git branching helped me understand how real-time projects are managed by teams without breaking the main application. This is a key concept in DevOps workflows 🚀 #Git #GitBranching #DevOps #VersionControl #CloudComputing #LearningJourney #TechSkills #WomenInTech #CloudEngineer

If you are working with Git in DevOps, you need to understand Git LFS. Here is why 👇 There are use cases where you might need to push a large file to git. For example, - ML models - Datasets etc. But Git was designed for text files, not binaries. Every change stores the entire file again, which bloats your repository fast. GitHub also has a hard limit of 100MB per file. Also, large files make git clone slow and git pull heavy. This directly impacts your CI pipeline performance. This is exactly where Git Large File Storage (LFS) helps you. It is an open source Git extension for versioning large files. Instead of storing large files directly in your repo, Git LFS replaces them with a small pointer file. That pointer file contains the LFS version, a SHA-256 hash of the actual file, and the file size. The real file is stored separately in Git LFS storage, not inside your Git repository. So where does it actually store the file? If you are using GitHub, the large file is stored in GitHub’s managed storage, separate from your Git objects. If you're self-hosting, it can be stored in your own LFS server or object storage like S3. Tools like DVC use similar workflow for versioning data in MLOPS use cases. --- 19000+ engineers read our DevOps/MLOPS newsletter. 𝗦𝘂𝗯𝘀𝗰𝗿𝗶𝗯𝗲 𝗵𝗲𝗿𝗲 (𝗶𝘁’𝘀 𝗳𝗿𝗲𝗲): https://lnkd.in/guFma5_V #mlops