program selection system

Distributed operations, open source tools, mashups, and SaaS are breaking down the traditional boundaries between vendor-supplied and custom-developed software. It’s now possible – if not necessary – to integrate development and run-time activities onto a seamless distributed platform. During this vendor talk, Charlie Rudd, President and CEO of SolutionsIQ, will demonstrate key elements of SolutionsIQ’s Agile development platform: • Mashups of SaaS and open source tools for development and continuous integration

See a live demonstration of AccuRev software in an Agile development environment. Multiple processes, continuous integration, advanced multi-stage continuous integration, test and release cycles will be shown to demonstrate how they can optimize your Agile processes and reduce the cost of software development.

While smaller teams may start Agile projects without any software tools, most would agree that utilizing tools designed for today’s Agile software development provides a significantly better framework for scaling these projects.

Getting a build system right can set the tone of development for years, and yet teams constantly re-invent wheel over and over. The application of a few key tools, such as Maven and Continuum in a sane ecosystem can provide a solid base for project growth and developer sanity, and can encourage the mature use of Agile practices and processes. Well designed automation of building, testing, and reporting can provide invaluable developer ease and fast feedback to developers and and other stakeholders.

Continuous Integration is at the heart of every Agile project. However, the status of the build process is only one source of information about the health of a project. Project velocity, bug counts, system performance, code metrics, and production uptime all provide valuable information about project health. But these bits of information are generally locked away in different systems and are not easily accessed or leveraged by the software team. Continuous monitoring is about pulling all of these sources of information together in a way that is visible and empowering for the entire team.

Agile developers love — and some actually need — to be in a state of flow. For them fast feedback from unit tests and continuous integration tools is not an option. In practice, fast unit tests often lack in coverage and many valuable tests run slow. This may be due to legacy code or the nature of the tests or just the sheer size of the application. Whatever the reason, getting feedback many hours after they submitted the code and the mental model has been blurred is a major impediment to developer’s productivity. To mitigate these issues a variety of strategies and tools have emerged.

With Continuous Integration, the chances rise exponentially with team size that as you fix a build or test problem, the integration of somebody else’s work creates a new build or test problem. Multi Stage CI addresses this problem by extending the practice of temporary individual isolation to features, teams, staging, QA, and release. This demonstration will show how Multi-Stage Continuous Integration works in the real world by drawing on the experiences of three large distributed teams. See changes by hundreds of simulated developers make their way through the system.

In May 2007, our DISA customer asked Pragmatics to support the requirements definition and development of a new web application for the Joint Forces Command (JFCOM) Joint Staff (JS). JFCOM needed to have the application built, delivered and fielded in a tight, six-week time frame.

If short build times (< 10 minutes) are good and longer build times (> 20 minutes) are bad how do we achieve shorter build times without massive hardware investment and parallelization? What are the effects on a team/project as the build time goes up and how can we keep it under control.

This presentation/discussion is in two parts.

• Comparison of two project teams (1 with longer build times and one with <2 minute build times)
• Technical review of the how the short build times were achieved and maintained.

Description for Program Guide

Many agile teams use Continuous Integration (CI). It’s one of the XP practices that has been broadly adopted. How effective is it? Does the effort of maintaining the CI server save time over a lengthier process that attempts to never break the build? While much anecdotal evidence exists to the benefits of CI there is little supporting data. How do you convince teams that it’s worth adopting and how best to do it? This report covers experiences with CI in a distributed team environment and attempts to answer these questions.