At the Conf42 DevSecOps 2024 conference, I presented my approach to architecting for continuous delivery. After more than 21 years at Zühlke, working across industries on DevOps transformations, I keep seeing the same fundamental problem: value streams broken by walls of confusion. In this talk, I walk through how organizations can move from project thinking to product thinking, build in quality and security from the start, architect for operability, and use platform engineering to scale it all.
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.
Is DevOps really the reason why testing and quality assurance (QA) employees are being increasingly automated out of a job? Pia Wiedermayer, Head of QA, and Romano Roth, Head of DevOps, discuss different ways to incorporate the wealth of experience of testing and QA specialists into the agile team culture.
When we are talking about traditional testing, we are talking about the V-model which is used in waterfall projects. We do requirement engineering, we write down features for our software, then we break them down and then write stories which are then given to the developer to implement this story. The developer then codifies this and then writes unite tests and integration tests.
In traditional software development, software is merged and tested by all developers in one big single integration step that usually takes weeks or even months. Since this only happens every few months, this step is very time-consuming.
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.
