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.
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.
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.
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.
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?
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.
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
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.
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).
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.