Romano Roth is Chief of DevOps at Zühlke. In this interview, he explains why DevOps is not bullshit, how transformation succeeds in companies, and what IT students really need to learn.
What defines high-quality work in software engineering? Is it Scrum? Clean Code? TDD? Functional programming? In this Expert Talks session, my colleague Milan and I present two complementary perspectives. Milan covers the pillars of high-quality engineering work, from team building and customer centricity to clean code and engineering culture. I then show how DevOps and continuous delivery help build great products by moving from a project mindset to a product mindset.
In this conference talk, I discuss one of the most fundamental topics in DevOps: thinking in systems and value streams. When I work with companies on their DevOps transformations, I consistently see the same patterns. The business has bright ideas. They write them into Word documents and Jira tickets. They throw them over a wall of confusion to development. Development builds something and throws it to testing. Testing compares what was specified with what was built (never quite the same), tests something, and throws it to operations. Operations asks “How can we operate that?” and somehow, with great effort, they get it running. Then the customer sees it and says: “What is that? That is not what we ordered.”
Have you ever wondered what “DevOps Engineers” actually do? What does “DevOps” even mean actually? This blog post aims to explain the concept of DevOps and the value that it
On February 1, 2002, I started my journey at Zühlke as a junior software engineer. Twenty years later, I am still here. In this post, I want to share what those 20 years looked like, what kept me going, and why I plan to stay for at least another 20.
Does test-driven development work with legacy applications? That is a question I get a lot, and the short answer is yes. In this video I take a big, ugly WinForms application and walk through how I use TDD to add a new feature without touching the messy parts of the existing code. The goal is simple: show that the test-first mindset works even when the surrounding codebase has no tests at all.
What exactly is TDD or Test-Driven Development, and why do so many experienced engineers swear by it? In this short video I explain where TDD comes from, how the red-green-refactor cycle works, and I walk through a simple C# calculator example that shows the process in action. TDD is not only a development technique, it is a mindset that shapes how you approach every line of code.
Continuous Deployment is the final, most aggressive step in the CI/CD progression. CI proves the code builds and the unit tests pass. Continuous Delivery proves the artifact works in a production-like environment. Continuous Deployment removes the last manual checkpoint: if every test along the way is green, the change goes straight to production. No “deploy” button, no Friday-afternoon release window, no human in the loop for the final step.
Continuous Integration ends with a tested artifact. That sounds great, but a green build does not mean the software actually works in a realistic environment. Unit tests run in isolation. Integration tests run against mocks. Until you put the software somewhere that looks like production and exercise it under real conditions, you have not really proven anything. Continuous Delivery is the step that closes that gap.
In traditional software development, integration was a single, painful event. Every developer worked in isolation for weeks or months, and at the end the team merged everything in one big bang. The integration step took weeks, sometimes months. Conflicts piled up, bugs hid in the seams between modules, and nobody could say with confidence whether the system actually worked. Continuous Integration was invented to make that pain disappear.
At first glance, a DevOps transformation seems to be a major undertaking for any company. But with the right approach, you can keep the process lean and agile.
Insight in brief # Start small with a small to medium sized project or product. Select the right people to ensure sufficient credibility and influence. Continuous improvement is key to success.
