Frequently Integrate Your Application with the Work of Other Developers

Frequently Integrate Your Application with the Work of Other Developers

Frequent integration of your application is a core principle when doing iterative development. When you integrate an application you create a build, which is an operational version of the system or part of the system that demonstrates a subset of the capabilities to be provided in the final product.

A build is not, however, the same as a release, which is the end result of an iteration. If you have a month-long iteration, you may produce daily builds, where each build is a small step closer to the release planned for the end of the iteration. Frequent builds ensure engineering progress by allowing you to validate that the code implemented since the last build works properly with other code. A build may be somewhat unstable, providing limited or no additional user functionality. A release, on the other hand, should be stable and offer new user functionality and mitigation of technical risks, all according to the iteration plan.

You typically want to minimize the time between builds to enable rapid feedback, especially in late Construction and Transition, but there is a cost associated with each build. The larger the size of your system, and the larger and more distributed your team is, the more expensive it is to do frequent builds. A good Configuration Management system with support for automated build management can significantly reduce the cost of doing frequent builds. Also note that the longer the time between builds, the more expensive the build will be because there will be more integration issues to resolve.

A team of three co-located developers with very primitive Configuration Management tool support may find that they can do daily builds, while a 100-person team distributed over several locations may accomplish only weekly builds in Inception and Elaboration, biweekly builds in Construction, and daily builds in Transition. The same 100-person team distributed over several locations, but without an effective Configuration Management system, may be able to do only monthly builds, in practice making it very difficult to do iterative development. As an example of what can be achieved with good automation and a good Configuration and Change Management process, Rational products are typically built using daily builds for at least the last 100 days of each major product release. These builds integrate the work of several hundred developers (who are distributed over many sites on three continents) building the various editions of Rational Suite.

Configuration Management Workspaces

As projects grow in size, it is increasingly important to set up private workspaces. A workspace provides each project member with an environment that selects and presents the appropriate version of each file. The workspace provides control over both sharing and isolation so the developers can stay isolated from changes made by others, but at the same time, they are able to unit-test their changes with changes made by certain other developers. A workspace also works as a "time capsule ," allowing a developer, analyst, tester, or other team members to see older versions of binaries, documents, tests, tools, and other objects. This is of great help when maintaining the system.

When a developer has implemented and tested a component or a set of components so they are stable, the developer moves them into a common workspace, often called an integration workspace. The person responsible for producing builds does so from the components in the integration workspace. This ensures that builds are created only from components that have been validated by the developer.

Note that Configuration Management tools are valuable to all team members, not only developers, ensuring that you keep track of all project artifacts.

Integration Planning

When doing iterative development, it becomes increasingly complex to plan builds and integration testing. For each iteration, you need to do an Integration Build Plan, specifying what capabilities should be testable in each build, and which components you need to integrate to produce the build with required capabilities, such as use cases, parts of use cases, or other functionality that can be tested.

Integration planning is essential since components are often dependent on each other in some way. To get a certain capability, you may find from the use-case realizations that you need Component A. But Component A may require the existence of Components B and C to be compilable. Component C may require the existence of Component D, and so on. In many cases, it is sufficient just to do a very shallow implementation of Components B, C, and D, allowing you to save a lot of time by focusing on the most essential functionality, while still being able to integrate your system. The Integration Build Plan specifies which components need to be developed, and allows you to improve your iteration plan and understand which stubs need to be developed.

You also need to decide which version of each component should be included in the build. It is not always the latest version, since a developer may be working on future capabilities of the component, temporarily putting it in an unstable state. As a developer, you need to review the Integration Build Plan to ensure you are developing the right components in the right order and moving them into the integration workspace.

Produce a Build

When producing a build, the developer is responsible for delivering and integrating the components in the integration workspace according to the Integration Build Plan. Depending on the complexity and number of components to be integrated, it is often more efficient to produce the target build in a number of steps, adding more components with each step and producing a series of intermediate "mini" builds. These are subjected to a minimal integration test (usually a subset of the tests described in the Integration Build Plan for the target build) to ensure that what is added is compatible with what already exists in the system integration workspace. It is easier to isolate and diagnose problems using this approach.

Once the build has been produced, all developers must rebase their workspace to update it with the developments of the others. The build is also made available for testing, so it can be tested while development continues working on the next build. With frequent builds, you need to automate regression testing to keep testing costs down. In this way, hundreds or thousands of regression tests can be run daily or weekly, ensuring that newly introduced defects are rapidly found.



The Rational Unified Process Made Easy(c) A Practitioner's Guide to Rational Unified Process
Programming Microsoft Visual C++
ISBN: N/A
EAN: 2147483647
Year: 2005
Pages: 173

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net