| <?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.3/uma.ecore" epf:version="1.0.0" xmi:id="_Dfmk8MPiEdmbOvqy4O0adg" name="workspace,_0cEmAMlgEdmt3adZL5Dmdw" guid="_Dfmk8MPiEdmbOvqy4O0adg" changeDate="2006-09-21T15:22:51.449-0400" 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_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html" 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> |