blob: f7fc0d27962f37c26e846aace8d1e9e8abab9fd5 [file] [log] [blame]
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
<!-- VERSION rmc:7.1.0 -->
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
<!-- START NON-TRANSLATABLE -->
<title>\openup_basic\guidances\concepts\workspace.xmi</title>
</head>
<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
<body>
Element Name: workspace.xmi<br/><br/>
<!-- END NON-TRANSLATABLE -->
<br/><br/><br/>
<!-- START NON-TRANSLATABLE -->
Attribute: presentationName<br/><br/>
<!-- END NON-TRANSLATABLE -->
<!-- START:presentationName,_0cEmAMlgEdmt3adZL5Dmdw CRC: 258310842 -->Workspace<!-- END:presentationName,_0cEmAMlgEdmt3adZL5Dmdw -->
<br/><br/><br/>
<!-- START NON-TRANSLATABLE -->
Attribute: briefDescription<br/><br/>
<!-- END NON-TRANSLATABLE -->
<!-- START:briefDescription,_0cEmAMlgEdmt3adZL5Dmdw CRC: 1586362847 -->Workspace refers to storage areas where developers can implement and test code in accordance with the project's adopted standards in relative isolation from other developers.<!-- END:briefDescription,_0cEmAMlgEdmt3adZL5Dmdw -->
<br/><br/><br/>
<!-- START NON-TRANSLATABLE -->
Attribute: mainDescription<br/><br/>
<!-- END NON-TRANSLATABLE -->
<!-- START:mainDescription,_Dfmk8MPiEdmbOvqy4O0adg CRC: 2689502876 --><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><!-- END:mainDescription,_Dfmk8MPiEdmbOvqy4O0adg -->
</body>
</html>