| <?xml version="1.0" encoding="UTF-8"?> |
| <org.eclipse.epf.uma:ContentDescription xmi:version="2.0" |
| xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.5/uma.ecore" |
| xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.0" xmi:id="_Dfmk8MPiEdmbOvqy4O0adg" |
| name="workspace,_0cEmAMlgEdmt3adZL5Dmdw" guid="_Dfmk8MPiEdmbOvqy4O0adg" changeDate="2006-09-21T12:22:51.449-0700" |
| version="1.0.0"> |
| <mainDescription><p align="left">
 |
| On small teams, shared workspaces may work fine, but you must coordinate activities between team members to avoid
 |
| conflicts.
 |
| </p>
 |
| <p align="left">
 |
| A better approach is for each developer to have a reasonably private area for the development and testing of their work
 |
| products. This workspace should be insulated&nbsp;so that destabilizing or conflicting changes made by others do not
 |
| interfere with&nbsp;progress. However, it should&nbsp;not be isolated to the extent that&nbsp;the developer's work is
 |
| unavailable to the team.
 |
| </p>
 |
| <p align="left">
 |
| In addition, insulated&nbsp;workspaces can be created for each test phase, such as integration testing and system
 |
| testing. This approach to workspaces provides several benefits <a class="elementLinkWithUserText" href="./../../../openup/guidances/supportingmaterials/references_6CCF393.html#WIB04" guid="_9ToeIB83Edqsvps02rpOOg">[WIB04]</a>:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| <p>
 |
| Developers can develop, test, and debug software changes without being affected by others team
 |
| members'&nbsp;changes until they are ready. When ready, developers can update their insulated environments to
 |
| test the latest changes from other developers.
 |
| </p>
 |
| </li>
 |
| <li>
 |
| <p>
 |
| With separate workspaces for integration and system testing, a team could use a methodology that ensures
 |
| changes have passed integration testing before other developers get them, thereby minimizing the time spent
 |
| solving integration problems.&nbsp; For example, if two team members check in incompatible changes without
 |
| realizing it, and both changes are immediately available to everyone on the team, all team members&nbsp;might
 |
| waste time trying to resolve the broken build. Conversely, if both changes must pass integration testing before
 |
| being distributed to others, the problem could be found and fixed by one person with minimal disruption to the
 |
| team.
 |
| </p>
 |
| </li>
 |
| <li>
 |
| <p>
 |
| By setting up an integration area to collect and build the latest changes, the team can integrate early and
 |
| often. That is a well-known best practice for reducing overall cost and time to deliver software projects.
 |
| </p>
 |
| </li>
 |
| <li>
 |
| <p>
 |
| The system test area, which is used for preparing releases, is insulated from developers' ongoing changes and
 |
| contains only configurations that have passed integration testing. This lets you control the content of the
 |
| release while still enabling developers to continue working.
 |
| </p>
 |
| </li>
 |
| </ul></mainDescription> |
| </org.eclipse.epf.uma:ContentDescription> |
