Raimondas Rimkevičius’ Post

Our Docker builds took 70 minutes and we thought that was normal. We had a recurring issue in our deployment process. Everyone felt it. No one wanted to deal with it. The flow was simple: A developer opens a PR It gets merged A Docker image builds Then it gets deployed Sounds normal. Until you hit the wait. The image was ~4 GB. Build time was 70+ minutes. Every. Single. Time. That meant: Testers sitting idle, waiting Feedback arriving late Context already lost by the time results came back Developers switching tasks just to stay productive Momentum kept breaking. You fix something → wait an hour You improve something → wait again You just want feedback → wait It adds up faster than you think. Then something changed. One of our teammates decided to dig into the image. After optimization: ~700 MB ~8 minutes Same workflow. Completely different pace. Feedback came back while the work was still fresh. Iteration stopped feeling like friction. Waiting stopped being part of the job. This wasn’t just about reducing image size. It was about removing a constant, invisible drag on the team. Because 70+ minutes per merge across features, fixes, and improvements isn’t just time lost. It’s momentum lost. And most teams don’t notice it until it’s gone. In our case, the fix wasn’t easy to figure out but AI helped make it approachable enough to execute Pro tip: Use multi-stage builds and only ship what was actually needed. If you’ve seen something similar, I’m curious how others are handling it #Docker #DockerImageOptimization #CICD #SofwareEngineering

🚀 CI/CD Design Deep Dive: Trunk-Based vs GitFlow environment pipelines Here’s the clearer, more technical picture I’ve built 👇 🔹 Trunk-Based CI/CD (Environment Promotions) Single long-lived branch: main (source of truth) Short-lived feature branches → PR → main CI runs on PR → validates the merge result (main + feature) After merge: - Build once - Produce immutable artifact (Docker image + digest) - Publish manifest.json (image, digest, commit_sha, version) - CD promotes the same artifact across environments: Dev → Stage → Prod (no rebuilds) 👉 Key principle: Artifact immutability + promotion by digest 👉 Strengths: Eliminates branch drift Faster feedback cycles Simpler merge model Strong alignment with microservices & continuous delivery 👉 Trade-offs: Demands strong test coverage Requires small PRs + disciplined teams Often needs feature flags for safe releases 🔹 GitFlow-Based CI/CD (Environment Branches) Multiple long-lived branches: dev → stage → prod Feature branches merge into dev Promotions happen via PRs: dev → stage → prod CI runs at every promotion step to gate merges Ideally: Build once (at dev) Promote the same artifact across branches 👉 Key principle: Controlled promotion via branch transitions 👉 Strengths: Strong governance & auditability Clear release boundaries Fits regulated / enterprise workflows 👉 Trade-offs: Higher merge overhead Risk of environment drift between branches Slower iteration cycles 💡 The insight that clicked for me: Both models should follow: 👉 Build once → promote many The real difference is: Trunk-Based → promotes artifacts across environments GitFlow → promotes code across branches 🧠 What I’m taking away: CI/CD is not just pipelines — it’s system design for delivery Branching strategy directly affects: - deployment safety - feedback speed - operational complexity Modern systems tend toward Trunk-Based + environment promotion GitFlow still has a strong place where control > speed Next step: 👉 Build a full pipeline implementing this with: Jenkins Docker (image + digest strategy) Cloud deployment + environment promotion Curious to hear from engineers in production systems: 👉 Do you rely more on trunk-based workflows or GitFlow — and what trade-offs have you experienced? #DevOps #CICD #Jenkins #Docker #SoftwareArchitecture #CloudEngineering #Git #PlatformEngineering #SRE #LearningInPublic

🚀 Code Quality is No Longer a Pipeline Responsibility — It’s a Developer Habit One key shift I’m driving within my team: 👉 Code quality checks happening locally — before the PR is even raised. This isn’t just a tooling change. It’s a culture shift ⬆️ at scale. 🧠 WHY THIS MATTERS AT AN ORG LEVEL 🔹 Reduces review fatigue PRs focus on architecture and business logic — not lint errors. 🔹 Accelerates delivery velocity Cleaner first-time commits = fewer iterations = faster releases. 🔹 Strengthens engineering ownership Quality is owned from the first line of code — not handed to CI/CD. 🔹 Improves pipeline efficiency CI becomes a validation layer, not a debugging tool. ⚙️ WHAT WE’R STANDARDIZING ✔️ Pre-commit hooks for linting & security checks ✔️ IDE-integrated static analysis aligned with CI rules ✔️ Local-first validation before code leaves the machine ✔️ Clear, trusted quality gates 🤖 IN THE AGE OF AI-ASSISTED CODING Faster code generation demands stronger validation. 👉 Local scans act as real-time guardrails—helping teams move fast without compromising quality. 💡LEADERSHIP TAKEAWAY Scaling engineering excellence isn’t about adding more checks in CI. ✅ It’s about shifting quality ownership left into the hands of every developer. Because the fastest PR is the one that doesn’t come back with comments 😉 #EngineeringLeadership #SoftwareEngineering #ShiftLeft #CodeQuality #TechLeader #SonarQube #Veracode

Read this! It is a great example of what AI can do FOR us and help eliminate other factors that are AGAINST us. Beautifully and expertly summarised by my ex-colleague Ralph Karliczek

Supercharging Software Delivery with Harness CI Over the past few months, I’ve spent a lot of time working with teams who are trying to balance speed, reliability, and developer happiness in their delivery pipelines. One thing has become clear to me: traditional CI tools just aren’t keeping up with the complexity of modern engineering. That’s why I’ve been genuinely excited about what Harness CI brings to the table. Harness CI isn’t just another CI platform I talk about — it’s one I’ve seen make a real difference for teams struggling with slow builds, flaky tests, and painful pipeline maintenance. Watching developers go from frustration to confidence because their pipelines “just work” has been incredibly rewarding. Here’s what stands out to me: Faster builds thanks to a container‑native, highly optimized engine AI‑powered test intelligence that cuts down flakiness and wasted time. A developer‑first experience with clean YAML, visual pipelines, and GitOps‑friendly workflows. Effortless scalability across microservices, monorepos, and hybrid environments. Smarter cost control with on‑demand infrastructure and resource orchestration. For me, the most exciting part is seeing teams reclaim time — time they can reinvest into innovation instead of babysitting pipelines. If you’re exploring ways to modernize your CI strategy or simply want to reduce the friction in your build and test workflows, Harness CI is absolutely worth a look. Always happy to share what I’ve learned along the way. #DevOps #CICD #PlatformEngineering #Harness #SoftwareEngineering #Automation

CI/CD is not just theory. It’s the difference between “it works on my machine”… and “it works in production.” I used to deploy like this: Upload files Run a few commands Hope nothing breaks 😅 And every deployment felt like a risk. Until I took CI/CD seriously. Now? Every push triggers a process 👇 ✔️ Automated tests ✔️ Build & checks ✔️ Clean deployment ✔️ Rollback ready No guessing. No stress. No last-minute fixes. Because CI/CD is not about tools… It’s about confidence. Confidence that: → Your code won’t break production → Your team can move faster → Your system is reliable And once you experience that… Manual deployments feel outdated. — If you’re still deploying manually 👇 You’re not saving time… you’re risking it. — Curious 👇 Are you using CI/CD… or still pushing code manually? #DevOps #CICD #WebDevelopment #SoftwareDevelopment #Developers #Automation #Tech #Programming #DeveloperLife

In real projects, we often push new changes again and again—fixing bugs, adding features, improving performance. Without CI/CD, every update feels manual and risky. Sometimes small mistakes can break the whole system, and it takes extra time to fix and redeploy. But when we use a CI/CD pipeline, things become much smoother. Every time we push code to Git, the system automatically runs tests, checks for issues, and deploys the update if everything is fine. We don’t have to do everything manually anymore. It not only saves time but also reduces human error and keeps the project more stable. As a result, we can focus more on building features instead of worrying about deployment problems. For me, CI/CD is not just a tool—it’s a smart way of working that makes development faster, safer, and more reliable. #CICD #DevOps #SoftwareDevelopment #Automation #WebDevelopment #Programming #CodingLife #Tech #ContinuousIntegration #ContinuousDeployment

Your code didn’t fail in production. Your process did. Everyone talks about writing clean code. Almost no one talks about how that code actually ships. And that’s where most systems break. In theory, the pipeline looks perfect: → Plan the rollout → Write the code and add tests → Build the artifact → Run every test from unit to e2e → Deploy to production and relax Looks solid, right? Then reality hits. → AI writes a big chunk of your code. → One tiny change breaks production for half your users. → And absolutely no one knows which PR started the fire 💀 Then the real panic starts. Debugging for hours. Slower releases. Everyone staring at their screens with maximum production stress. That’s when it hit me. Shipping code is not a developer problem. It is a system design problem. Because if your pipeline is chaos… even perfect code doesn't stand a chance. #SystemDesign #DevOps #SoftwareEngineering #BackendEngineering #Microservices #TechRealities

Before: chaotic TDD attempts lead to frustration. After: streamlined test-driven development success. 1. Embrace the "Red, Green, Refactor" cycle religiously. Start with failing tests, then write the minimum code to pass, and finally refactor for maintainability. 2. Use test doubles wisely. Mocks and stubs can help isolate unit tests, but avoid overusing them as it can lead to brittle tests. 3. Build tests that tell a story. Each test should clearly explain the feature it covers, making your test suite a living documentation. 4. Try vibe coding for quick prototyping. It lets you keep the creative flow, then solidify with tests that lock down your design. 5. Avoid testing implementation details. Focus on behavior and outcomes to ensure your tests remain relevant through refactoring. 6. Continuously review and update your test suite. Tests are only as good as they are current, so iterate to keep them aligned with the evolving codebase. 7. Leverage AI-assisted development to optimize your TDD workflow. I've found it speeds up the generation of boilerplate test cases, letting me focus on complex scenarios. Which TDD pattern has been the most impactful in your workflow? Let's share experiences! #SoftwareEngineering #CodingLife #TechLeadership

The Heartbeat of Modern Software: Why CI/CD is a Game Changer? In the old days of software development, "Release Day" was a high-stress event. Teams would spend weeks merging code, manually testing, and crossing their fingers that nothing broke. Today, we use CI/CD—the engine that keeps innovation moving without the manual headache. 🧩 Continuous Integration (CI): The "Safety Net" CI is all about frequent collaboration. Instead of working in isolation for a month, developers merge their code into a shared repository multiple times a day. 🪄 The Magic: Every time code is pushed, an automated build and test sequence triggers. The Result: Bugs are caught in minutes, not weeks. 📍 Continuous Deployment (CD): The "Fast Track" If CI is the safety check, CD is the delivery vehicle. Once the code passes all tests, it is automatically deployed to the production environment. The Magic: Features reach the end-user as soon as they are ready. The Result: No more "Big Bang" releases; just a steady stream of improvements. 💡 Why does it matter? ✔ Faster Delivery: Turn ideas into reality in hours. ✔ Fewer Bugs: Automation catches what human eyes might miss. ✔ Better Collaboration: Teams stay aligned through a "Single Source of Truth." The Bottom Line: CI/CD isn't just a set of tools like Jenkins, GitHub Actions, or GitLab; it’s a mindset of quality and speed. When you automate the boring stuff, you free up your team to focus on what actually matters: Building great products. How is your team leveraging automation this year? Let’s discuss in the comments! 👇 #DevOps #CICD #SoftwareEngineering #CI #CloudNative #Automation #TechTrends2026