Agile 2009 - continuous integration

Killing the gatekeeper: introducing a continuous integration system

flacoste — Wed, 04 Mar 2009 03:17:01 +0000

This is the story of how the Launchpad (https://launchpad.net) development team switched to a continuous integration system to increase several flows in their development process:

flow of changes on trunk;
flow of changes requiring database schema upgrade;
flow of deployed changes to end users.

To switch to a buildbot (http://buildbot.net) based system meant violating a very old company taboo: risking a trunk that doesn’t pass its test suite. The risk of a broken trunk was offset by allowing each developer to run the full test suite in the Amazon EC2 cloud.

Build and Test in the Cloud – CI and Cloud Provisioning for Agile Teams

ngulrajani — Tue, 03 Mar 2009 19:51:51 +0000

Today’s developers are quick to adopt leading-edge technologies that can accommodate project peaks and valleys, evolve and change, and support agile principles. Using the CollabNet platform, this session will demonstrate the agile best practice of continuous integration (CI) using cloud provisioning capabilities and the Hudson open source CI engine. Attendees will learn a framework that can be used in their environment, including an understanding of the components, tools, set up, and generalized use cases for development in both virtual private clouds and public clouds, like Amazon EC2.

Agile Source Code Management using Stories, Agile Workflow, and CI

Damon Poole — Mon, 02 Mar 2009 18:08:31 +0000

You create iterations from a backlog of user stories managed via a taskboard with a simple “workflow” from “todo” to “done.” You use Continuous Integration. But in your source control system you’ve just got files and branches. You could create a branch for every story, but that’s a lot of branches to manage! How can you ask the source control system which versions/files correspond to the stories that are done in order to build the “done” version and do exploratory testing? This session will show how to manage changes using stories and how to use branches to represent your workflow.

How to run 4.5 Million tests per day ... and why!

mstriebeck — Fri, 13 Feb 2009 09:15:34 +0000

Given the size and scope of Google’s code base, and speed of development, typical off-the-shelf continuous integration are unable to meet our needs. So, we decided to create a continuous integration and testing system as a centralized service on an unprecedented scale. When fully completed and operational, it will probably be the world’s largest continuous integration and testing system, running millions of tests every single day.

In this talk, we will report on our experience running such a program in an agile manner and will also describe the basic design and features of the CI system.

Continuous Integration of the World

jedi4ever — Fri, 06 Feb 2009 15:36:54 +0000

Ok, maybe we exaggerated a bit. CI deployments focus on the testing and deployment of the application. The ‘world’ (OS, Application & DB server) within a CI doesn’t change that much. But what if you could define your applications environment from a kind of ‘source’ and build and unit test it? f.i. Test security patches by using unit tests of your application?

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

CI vendor cage-fight!

tomsulston — Tue, 27 Jan 2009 11:12:18 +0000

In this session, we invite CI tool vendors to give a short demonstration of the best features of their tool. Each vendor will be given 10min to show off the best features of their software, with a further 5min of questions.

This will allow CI users to quickly get a good grasp on the plethora of CI tools on the market, to help them find out about useful features of various tools that may help their CI implementation, and to learn about the practices that each tool encourages.

It also helps CI tool vendors gauge the market, and improve the standards and features of all CI products.

Applying Agile Development Practices to Atypical Technologies

sdillman — Fri, 23 Jan 2009 15:10:22 +0000

This talk discusses techniques that can be used to apply Agile practices to atypical technologies, and presents case studies on how to apply Agile practices to projects built with technologies including Teradata (Database), and MicroStrategy (BI).

Top ten secret weapons for performance testing in an agile environment

alistair.jones — Wed, 21 Jan 2009 17:52:05 +0000

In the battle of YAGNI and the performance testers, who wins out on an agile project? Join us as we walk through a historical account of what happens when you need to meet heavy performance targets on an agile project. Find out what was at stake, and the dire consequences if either side annihilated the other. We’ll focus on technical detail, planning and management techniques that led to the only outcome, collaborative success! Finally, discover the impact this battle had in the war agile wages to align the needs of end customers, the business, and IT, to see how it all worked out.