How Everfaz uses Git to ship faster and safer

🔧 𝗚𝗶𝘁𝗢𝗽𝘀 𝗶𝘀 𝗻𝗼𝘁 𝗳𝘂𝘁𝘂𝗿𝗲 — 𝗶𝘁’𝘀 𝗻𝗼𝘄. In 2025, Kubernetes teams are shifting from manual pipelines to declarative, Git-centric operations. According to analysts, over 90% of Kubernetes deployments will be managed via GitOps by year-end. 🔍 𝗪𝗵𝘆 𝗶𝘁 𝗺𝗮𝘁𝘁𝗲𝗿𝘀: ✅ Version control for infra and apps → every change is auditable. ✅ Self-healing and automated rollback become native. ✅ Developer productivity gets a boost because ops becomes declarative. ✅ Strong alignment with Kubernetes’ desired state model. 💡 𝗢𝘂𝗿 𝗰𝗮𝗹𝗹 𝗮𝘁 𝗜𝗻𝗳𝗿𝗮𝗦𝗵𝗶𝗳𝘁: We believe that adopting GitOps isn’t just a tooling change—it’s a cultural shift. It demands: • A single source of truth (Git backbone) • Infra & application teams working in sync • Automation rules baked in from day one 👉 𝗥𝗲𝗮𝗱𝘆 𝘁𝗼 𝗲𝘀𝗰𝗮𝗹𝗮𝘁𝗲 𝘆𝗼𝘂𝗿 𝗞𝘂𝗯𝗲𝗿𝗻𝗲𝘁𝗲𝘀 operations? Let’s talk about building your GitOps-powered, resilient deployment platform. #DevOps #GitOps #Kubernetes #CloudNative #InfraShift #PlatformEngineering

𝗦𝘁𝗶𝗹𝗹 𝗱𝗲𝗽𝗹𝗼𝘆𝗶𝗻𝗴 𝘄𝗶𝘁𝗵 𝗽𝗶𝗽𝗲𝗹𝗶𝗻𝗲𝘀 𝘁𝗵𝗮𝘁 𝗽𝘂𝘀𝗵 𝘁𝗼 𝗽𝗿𝗼𝗱𝘂𝗰𝘁𝗶𝗼𝗻? 𝗧𝗵𝗲𝗻 𝘆𝗼𝘂'𝗿𝗲 𝗮𝗹𝗿𝗲𝗮𝗱𝘆 𝗯𝗲𝗵𝗶𝗻𝗱. Over the last few years, cloud-native teams have moved incredibly fast, but the same operational pain points keep showing up: non-reproducible environments, unpredictable rollbacks, manual drift fixes, and deployments that behave differently across clusters.  DevOps gave us automated pipelines and broke down the walls between dev and ops, but as our systems have become more distributed, containerized, and environment-sensitive, the limitations of “pipeline-push deployments” have started to show.  That’s where GitOps has become a practical evolution rather than just another buzzword.  In most real-world Kubernetes projects I've seen, whether it’s spinning up multi-tenant environments on EKS, managing dozens of microservices across markets, or maintaining consistent infra for integration platforms, the biggest challenge isn’t deployment. It’s consistency and repeatability. 𝗗𝗲𝘃𝗢𝗽𝘀 𝘁𝗿𝗮𝗻𝘀𝗳𝗼𝗿𝗺𝗲𝗱 𝘀𝗼𝗳𝘁𝘄𝗮𝗿𝗲 𝗲𝗻𝗴𝗶𝗻𝗲𝗲𝗿𝗶𝗻𝗴 𝘄𝗶𝘁𝗵: ➟ Continuous Integration ➟ Continuous Delivery  ➟ Breaking down silos  ➟ Automated deployments ➟ Shared responsibility But these mechanisms still rely on pipelines that push artifacts and manifests into environments. 𝗚𝗶𝘁𝗢𝗽𝘀 𝗶𝗻𝘁𝗿𝗼𝗱𝘂𝗰𝗲𝘀 𝗮 𝗻𝗲𝘄 𝗼𝗽𝗲𝗿𝗮𝘁𝗶𝗼𝗻𝗮𝗹 𝗺𝗼𝗱𝗲𝗹 𝗱𝗲𝗳𝗶𝗻𝗲𝗱 𝗯𝘆 𝗼𝗻𝗲 𝘀𝗶𝗺𝗽𝗹𝗲 𝗿𝘂𝗹𝗲: Git is the single source of truth for everything — infrastructure, app config, and deployment state. Instead of pipelines pushing changes, 𝗚𝗶𝘁𝗢𝗽𝘀 𝗰𝗼𝗻𝘁𝗿𝗼𝗹𝗹𝗲𝗿𝘀 (𝗔𝗿𝗴𝗼𝗖𝗗, 𝗙𝗹𝘂𝘅𝗖𝗗) continuously: 1️⃣ Watch Git for the 𝗱𝗲𝘀𝗶𝗿𝗲𝗱 𝘀𝘁𝗮𝘁𝗲 2️⃣ Watch the cluster for the 𝗮𝗰𝘁𝘂𝗮𝗹 𝘀𝘁𝗮𝘁𝗲 3️⃣ 𝗥𝗲𝗰𝗼𝗻𝗰𝗶𝗹𝗲 any drift automatically In one of our recent EKS-based integration programmes, we had multiple clusters per environment across regions. After adopting GitOps, we saw immediate improvements: ✔️ Drift detection became instant (ArgoCD highlighted mismatches)  ✔️ Rollbacks were literally a Git revert ✔️ Hotfixes stopped disappearing ✔️ Multi-cluster consistency dramatically improved  ✔️ Security strengthened because Git became the only entry point  ✔️ Developers focused on code, not environment firefighting 𝗚𝗶𝘁𝗢𝗽𝘀 𝗱𝗼𝗲𝘀𝗻’𝘁 𝗿𝗲𝗽𝗹𝗮𝗰𝗲 𝗗𝗲𝘃𝗢𝗽𝘀. 𝗜𝘁 𝗲𝘅𝘁𝗲𝗻𝗱𝘀 𝗶𝘁 𝘄𝗶𝘁𝗵 𝗽𝗿𝗲𝗱𝗶𝗰𝘁𝗮𝗯𝗶𝗹𝗶𝘁𝘆, 𝗴𝗼𝘃𝗲𝗿𝗻𝗮𝗻𝗰𝗲, 𝗮𝗻𝗱 𝗼𝗽𝗲𝗿𝗮𝘁𝗶𝗼𝗻𝗮𝗹 𝗱𝗶𝘀𝗰𝗶𝗽𝗹𝗶𝗻𝗲. CI remains the same. But CD becomes 𝗰𝗼𝗻𝘁𝗶𝗻𝘂𝗼𝘂𝘀 𝗿𝗲𝗰𝗼𝗻𝗰𝗶𝗹𝗶𝗮𝘁𝗶𝗼𝗻, not continuous push. #DevOps #GitOps #Kubernetes #PlatformEngineering #CICD #CloudComputing #SRE #CloudArchitecture #ArgoCD #FluxCD

🚀 Day 31 of #100DaysOfDevOps – Git Stash Today’s focus was on mastering Git Stash, a powerful feature for managing in-progress work without losing context. The Nautilus development team had previously stashed some unfinished changes in their repository located at /usr/src/kodekloudrepos/news. My task: restore the stashed changes identified as stash@{1} and push them to the remote repository. Steps followed: Checked all stashes using git stash list Applied the required stash with git stash apply stash@{1} Verified the recovered file welcome.txt Committed the change with the message “Added stash 1” Pushed the update to the origin branch Key takeaway: Git Stash acts as a temporary workspace buffer, allowing developers to context-switch effortlessly without losing progress — an essential skill in real-world DevOps environments. "Efficiency is doing things right; effectiveness is doing the right things." – Peter Drucker #Git #DevOps #GitCommands #VersionControl #DevOpsJourney #100DaysOfDevOps #LearningInPublic #CloudOps #ContinuousIntegration #SoftwareDevelopment #GitTips

GitOps isn’t just about automation — it’s a disciplined way to manage infrastructure and applications through Git as the single source of truth. Every change is traceable, reviewable, and recoverable. The process relies on four key principles: Declarative – Define your desired state as code. Versioned – Store everything in Git for history and rollback. Automated – Controllers detect and apply changes automatically. Continuous – The system constantly reconciles actual vs desired state. Here’s a simple visual that summarizes the GitOps principles #GitOps #DevOps #ArgoCD #FluxCD #Kubernetes #InfrastructureAsCode #Automation #SRE #CloudEngineering

I'm excited to share this visual that clearly breaks down the difference between a traditional 𝗗𝗲𝘃𝗢𝗽𝘀 𝗖𝗜/𝗖𝗗 𝗽𝗶𝗽𝗲𝗹𝗶𝗻𝗲 𝗮𝗻𝗱 𝗮 𝗺𝗼𝗱𝗲𝗿𝗻 𝗚𝗶𝘁𝗢𝗽𝘀 𝗖𝗜/𝗖𝗗 𝗽𝗶𝗽𝗲𝗹𝗶𝗻𝗲! While both share the 𝗖𝗼𝗻𝘁𝗶𝗻𝘂𝗼𝘂𝘀 𝗜𝗻𝘁𝗲𝗴𝗿𝗮𝘁𝗶𝗼𝗻 (𝗖𝗜) steps from Source Code to Unit Test, Artifact Build, Image Build, and finally Image Registry the 𝗖𝗼𝗻𝘁𝗶𝗻𝘂𝗼𝘂𝘀 𝗗𝗲𝗽𝗹𝗼𝘆𝗺𝗲𝗻𝘁 (𝗖𝗗) stage is where GitOps truly changes the game. 𝗞𝗲𝘆 𝗗𝗶𝗳𝗳𝗲𝗿𝗲𝗻𝗰𝗲𝘀 𝗶𝗻 𝗗𝗲𝗽𝗹𝗼𝘆𝗺𝗲𝗻𝘁: 𝗗𝗲𝘃𝗢𝗽𝘀 𝗖𝗜/𝗖𝗗: The deployment is typically push-based. After the image is built, a tool (like Jenkins, GitLab CI, etc.) pushes the new image to the Kubernetes Cluster. 𝗚𝗶𝘁𝗢𝗽𝘀 𝗖𝗜/𝗖𝗗: The deployment is pull-based and Git-centric.  • The deployment configuration (𝗠𝗮𝗻𝗶𝗳𝗲𝘀𝘁𝘀 𝗮𝗻𝗱 𝗖𝗵𝗮𝗿𝘁𝘀) is 𝘀𝘁𝗼𝗿𝗲𝗱 𝗶𝗻 𝗮 𝗚𝗶𝘁 𝗿𝗲𝗽𝗼𝘀𝗶𝘁𝗼𝗿𝘆.  • The Container Version 𝗨𝗽𝗱𝗮𝘁𝗲 𝘁𝗿𝗶𝗴𝗴𝗲𝗿𝘀 𝗮 𝗣𝘂𝗹𝗹 𝗥𝗲𝗾𝘂𝗲𝘀𝘁 𝘁𝗼 𝘂𝗽𝗱𝗮𝘁𝗲 𝘁𝗵𝗲 𝗺𝗮𝗻𝗶𝗳𝗲𝘀𝘁𝘀 𝗶𝗻 𝗚𝗶𝘁.  • A 𝗚𝗶𝘁𝗢𝗽𝘀 𝗧𝗼𝗼𝗹 (𝗹𝗶𝗸𝗲 𝗔𝗿𝗴𝗼𝗖𝗗 𝗼𝗿 𝗙𝗹𝘂𝘅) 𝗿𝘂𝗻𝘀 𝗶𝗻𝘀𝗶𝗱𝗲 𝘁𝗵𝗲 𝗰𝗹𝘂𝘀𝘁𝗲𝗿 𝗮𝗻𝗱 𝗽𝘂𝗹𝗹𝘀 the desired state from Git, syncing the cluster with the repository's source of truth. 𝗪𝗵𝘆 𝗚𝗶𝘁𝗢𝗽𝘀? 𝗦𝗶𝗻𝗴𝗹𝗲 𝗦𝗼𝘂𝗿𝗰𝗲 𝗼𝗳 𝗧𝗿𝘂𝘁𝗵: Git becomes the single, declarative source for your application and infrastructure state. 𝗔𝘂𝗱𝗶𝘁𝗮𝗯𝗶𝗹𝗶𝘁𝘆 & 𝗥𝗼𝗹𝗹𝗯𝗮𝗰𝗸: Every change is a committed version in Git, making auditing easier and rollbacks as simple as reverting a commit. 𝗦𝗲𝗰𝘂𝗿𝗶𝘁𝘆: Clusters only need read access to the repo, avoiding the need for CI tools to hold sensitive cluster credentials. GitOps is the future of declarative infrastructure and Kubernetes management! 𝗪𝗵𝗮𝘁 𝗮𝗿𝗲 𝘆𝗼𝘂𝗿 𝗳𝗮𝘃𝗼𝗿𝗶𝘁𝗲 𝗚𝗶𝘁𝗢𝗽𝘀 𝘁𝗼𝗼𝗹𝘀? 𝗟𝗲𝘁 𝗺𝗲 𝗸𝗻𝗼𝘄 𝗶𝗻 𝘁𝗵𝗲 𝗰𝗼𝗺𝗺𝗲𝗻𝘁𝘀! 👇 #DevOps #GitOps #CI/CD #Kubernetes #CloudNative #ContinuousDeployment

🌍 𝗘𝗻𝘃𝗶𝗿𝗼𝗻𝗺𝗲𝗻𝘁 𝗣𝗮𝗿𝗶𝘁𝘆 — 𝗧𝗵𝗲 𝗠𝗶𝘀𝘀𝗶𝗻𝗴 𝗟𝗶𝗻𝗸 𝗶𝗻 𝗗𝗲𝘃𝗢𝗽𝘀 𝗥𝗲𝗹𝗶𝗮𝗯𝗶𝗹𝗶𝘁𝘆 🌍 Every successful release shares one hidden trait — consistency. Not just in code, but across environments. When your Dev, QA, Staging, and Prod behave differently — your CI/CD loses predictability, your debugging slows, and your team loses trust in automation. 💡 𝗜𝗻𝘀𝗶𝗱𝗲 𝘁𝗵𝗶𝘀 𝗴𝘂𝗶𝗱𝗲: 1. How to eliminate environment drift using Docker, IaC, and GitOps 2. Why “Promote, Don’t Rebuild” should be your CI/CD mantra 3. Proven workflows with Jenkins, Terraform, and Argo CD 4. How big players like Netflix and Google maintain consistency at scale 5. Practical templates, configs, and parity validation techniques When parity becomes your culture Deployments turn predictable, debugging gets faster, and Dev + Ops truly align. #DevOps #DevSecOps #CloudEngineering #CICDPipeline #GitOps #Kubernetes #Docker #Terraform #Jenkins #InfrastructureAsCode

🚀 𝟏𝟎𝟎 𝐃𝐚𝐲𝐬 𝐨𝐟 𝐃𝐞𝐯𝐎ps – 𝐌𝐲 𝐉𝐨𝐮𝐫𝐧𝐞𝐲 (𝐃𝐚𝐲 𝟐𝟑) 🚀 Day 23 of my 100 Days of DevOps challenge on KodeKloud is complete! Today's task shifted from the command line to the web UI to perform a core collaborative action: forking a Git repository. This is a fundamental step in the fork-and-pull-request workflow, which is central to modern development. 🔹 Today's Challenge: Fork a Git Repository Goal: As a new developer ('jon'), log in to the Gitea UI, locate a team repository, and create a personal fork to begin work without affecting the main codebase. • Log in to the Gitea server as user jon. • Find the existing repository named sarah/story-blog. • Fork this repository under the jon user account. 🧭 My Approach • Navigated to the Gitea UI and signed in with the jon user credentials. • Used the search bar to locate the sarah/story-blog repository. • Clicked the "Fork" button on the repository's main page. • Selected jon as the owner for the new forked repository. • Verified that I was redirected to jon/story-blog, confirming the fork was successful. ⚙️ Challenges Faced • This was a UI-driven task, so the main check was ensuring I was logged in as the correct user (jon) before initiating the fork. 🧩 Resolutions • The Gitea UI clearly prompts for which user/organization to fork to, making it easy to confirm the correct destination (jon). 💡 Key Takeaways • Forking vs. Cloning: A clone copies the repo, but a fork creates a new, separate server-side copy linked to the original (upstream). • Safe Development: Forking is the essential first step for contributing to a project you don't have direct push access to. You push changes to your fork, then open a Pull Request. • Foundation of Collaboration: This fork-and-PR model is the standard for open-source projects and many internal teams, as it protects the main branch and enables code review. This task was a great practical demonstration of the standard developer workflow in a shared code environment. On to Day 24! 💪 #100DaysOfDevOps #KodeKloud #DevOps #Git #Gitea #VersionControl #Collaboration #LearningJourney #KeepLearning #CI CD

🔄 Day 27 of #100DaysOfDevOps — Reverting Commits in Git “Failure is simply the opportunity to begin again, this time more intelligently.” – Henry Ford Today’s task was all about damage control in Git — something every DevOps engineer eventually faces. Here’s the scenario: The Nautilus application development team encountered an issue with the latest changes pushed to the repository located at: 📍 /usr/src/kodekloudrepos/demo on the Storage server in Stratos DC. The development team needed the repository rolled back to the previous stable commit. As part of the DevOps team, it was my job to: Identify the latest commit (HEAD) that introduced issues. Revert the repository to the previous commit, which contained the initial stable codebase. Create a new revert commit with the message revert demo message to document the rollback cleanly. This exercise reinforced why version control isn’t just about committing code, but also about managing mistakes gracefully. A well-structured revert ensures that the project history stays intact while swiftly neutralizing any bad changes. In real-world CI/CD pipelines, knowing how to revert without disrupting collaborators is a critical operational skill. It maintains velocity while preserving integrity. #100DaysOfDevOps #Day27 #Git #VersionControl #GitRevert #DevOpsJourney #ContinuousLearning #TechCommunity #SoftwareEngineering #InfrastructureManagement #GitOps #CodingJourney #ProfessionalGrowth #EngineeringExcellence #CommandLine #DevOpsCulture #ErrorRecovery #Teamwork #OpenSource #CloudComputing #TechGrowth

GitLab Epic and PLS in London is over - and one thing got stuck in my head. Besides all the effort and innovation around Agentic AI and how it embeds into the whole GitLab platform, it is worth to remember, what GitLab was built for. I'd really like to say "thank you!" to Scott Brightwell who emphasized once again, that GitLab was built to "ship secure software faster". And to ship such software, faster and more secure, there is lots that the platform brings to the table, that will boost the software development of many many companies already. Automate as much as you can through your SDLC, run automated tests (and please don't stop with unit tests), integrate security into your pipeline early enough, so vulnerabilities don't hit you hard just before you release to production.. achieve a "deployable state" at any time, verify and develop in small chunks, each tested, verified and approved. And of course, Agentic AI helps to achieve all of that. But, and that's what I'm afraid of, who will benefit of thousands of lines of written code within a day, if that code is tested poorly, not scanned for vulernabilities, packed into enormous releases and - worse of all - not understood by the developers anymore. So, with my little Wednesday morning babble coming to an end .. keep an eye on the whole SDLC, improve the processes, remove manually interaction and increase automation. The Duo Agent Platform, which GitLab is currently building, is impressive and again a step further than others - by not just focussing on the code creation aspect but by keeping the overall SDLC in mind. Many little agents, experts in their specific area, customized to your domain - together with anything I said above, an incredible efficiency boost. So, what to do next? The starting point is fairly easy. Obviously not the only option, but a little advertisement will be allowed, you can get a fully Managed GitLab from codecentric AG - and, by attaching a fully managed k8s cluster, we make sure you can run review apps and more sophisticated tests (integration test, API or DAST) out of the box without setting up any kind of infrastructure. So, everything there you need to setup proper testing and automation routines! Reach out if you want to learn more about that! Now, of to Paris! 🇫🇷 #gitlab #devsecops #agenticai #sdlc #duoagentplatform