Agile 2009 - integration

Removing Integration Delays with Collocated Whole Teams and Multi-stage CI

Damon Poole — Tue, 03 Feb 2009 14:51:46 +0000

As individuals we work in transient isolation to reduce the impact of work in progress on each other. Organizations isolate WIP by using only official versions of 3pty sources and by producing official releases for customers.

Multi-stage continuous integration (MSCI) scales CI to large distributed environments by isolating work in progress at the team level. Changes move from individual to team to mainline as fast as CI allows, but stop on failure.

MSCI is particularly important in a distributed environment where fixes to problems exposed by CI can be delayed by a full day.

Large scale continuous integration

hkokko — Sun, 01 Feb 2009 22:19:04 +0000

Increase Productivity With Large Scale Continuous Integration Iteratively: Reduce Feedback Cycle From Weeks To 100 Minutes

Using iterative development – create an continuous integration environment using open source and commercial tooling for hundreds of developers
From migration to new environment – the tools and process lessons learned
Effects seen in product development – real life experience after 18 months in production

Continuous Testing Evolved

bjrady — Fri, 30 Jan 2009 02:40:55 +0000

Continuous Testing (CT) is a developer practice that shortens the feedback loop established by Test Driven Development. It gives you near instant feedback about the correctness of your code, and helps you find bugs as quickly as syntax errors. This session will cover how CT has evolved in the last year, it’s current capabilities, and limitations. The presenters will also show several demos of the practice using freely available continuous testing tools, and examine how these tools can be integrated with existing infrastructure to bring the benefits of CT to a wider audience.

Integration Tests Are A Scam

jbrains — Thu, 29 Jan 2009 23:57:59 +0000

Integration tests are a scam, a self-replicating virus that takes over your project and burdens you with long-running, fragile, hard-to-understand test suites. You’re probably writing 2-5% of the integration tests you need to test thoroughly. You’re probably duplicating unit tests all over the place. Your integration tests probably duplicate each other all over the place. When an integration test fails, who knows what’s broken? When you refactor, you have to fix dozens of integration tests. Stop it. Learn the two-pronged attack that solves the problem: collaboration tests and contract tests.