Borland® StarTeam® 2006 - Borland Technical Publications
Borland® StarTeam® 2006 - Borland Technical Publications Borland® StarTeam® 2006 - Borland Technical Publications
Beheben Build ■ Er stellt die Änderungsanforderung für die spätere Bearbeitung zurück, z. B. für die nächste Version des Produkts. ■ Er weist der Änderungsanforderung den Status Wie vorgesehen zu und gibt so an, dass sie nicht bearbeitet werden muss. Wenn die Änderungsanforderung den Status Offen hat, werden keine automatischen Änderungen vorgenommen. Wenn die Änderungsanforderung den Status Zurückgestellt oder Wie vorgesehen hat, wird Adressiert in Build deaktiviert und die Zuständigkeit wird dem Benutzer zugewiesen, der die Änderungsanforderung erstellt hat. Vorgehensweise: Benutzer rufen die ihnen zugewiesenen Änderungsanforderungen mit dem Status Offen oder Wird verarbeitet ab und führen pro Anforderung einen der folgenden Schritte aus: ■ Sie beheben das Problem im System und aktualisieren die Eigenschaften der jeweiligen Änderungsanforderung. (Bearbeitete Änderungsanforderungen können die Statuswerte Nicht reproduzierbar, Wie vorgesehen, Repariert, Dokumentiert oder Doppelt zugewiesen werden.) ■ Sie stellen die Änderungsanforderung für eine spätere Bearbeitung zurück, z. B. für die nächste Version des Produkts. Wenn der Änderungsanforderung der Status Repariert oder Dokumentiert zugewiesen ist, ändert sich die Eigenschaft Adressiert in Build in Nächster Build. Hat die Anforderung einen anderen Lösungsstatus, ist die Eigenschaft deaktiviert. Standardmäßig ist der Benutzer, der die Änderungsanforderung gesendet hat, dann für das Testen der Lösung zuständig. Wenn die Änderungsanforderung den Status Zurückgestellt hat, wird Adressiert in Build deaktiviert und die Zuständigkeit wird in der Regel dem Benutzer zugewiesen, der die Änderungsanforderung erstellt hat. Wer erstellt ein Projekt-Build? Der Build-Prozess in der Projektansicht kann formell oder informell sein. An einem bestimmten Punkt wird allen aktuell in der Ansicht befindlichen Dateien usw. das Build-Label zugewiesen. In der Regel wird es zunächst den compilierten Quellcode-Dateien usw. zugewiesen (und muss ggf. geändert werden) und nicht den beim Build-Vorgang erzeugten ausführbaren Dateien. Auswirkungen auf Änderungsanforderungen: Der Wert Nächster Build für die Eigenschaft Adressiert in Build gelöster Änderungsanforderungen wird durch das Label des nächsten Builds ersetzt. Hinweis: Wenn ein neues Build-Label auf einer alten Konfiguration und nicht auf der aktuellen Konfiguration basiert, hat es keine Auswirkungen auf die Eigenschaft Adressiert in Build. Wenn eine Änderungsanforderung an ihrer aktuellen Position nicht verzweigt ist, kann Nächster Builddurch ein Build-Label einer anderen Ansicht ersetzt werden. Angenommen, Sie erstellen eine verzweigte untergeordnete Ansicht oder geben einen Ordner aus einer Ansicht in einer anderen zur gemeinsamen Nutzung frei. Nächster Buildist der Wert für die Eigenschaft Adressiert in Build einer Änderungsanforderung, die nicht verzweigt ist. Wenn in der Quellansicht ein Build-Label erstellt wird, wird der Wert Nächster Builddurch den Namen des Build- Labels unabhängig von dessen Position ersetzt. Verifizieren* Die Person, die die Änderungsanforderung eingereicht hat, verifiziert den geänderten Code (in der Regel ein Tester oder ein Mitarbeiter der Qualitätssicherung). Schließen* Vorgehensweise: Installieren Sie den Build, in dem die Lösung verifiziert werden soll, und überprüfen Sie, ob die Änderungsanforderung erfolgreich behoben wurde. Führen Sie einen der folgenden Schritte aus: ■ Verifizieren Sie die Änderungsanforderung und kennzeichnen Sie sie als Verifiziert - Nicht reproduzierbar, Verifiziert - Wie vorgesehen, Verifiziert - Repariert, Verifiziert - Dokumentiert oder Verifiziert - Doppelt. ■ Öffnen Sie die Änderungsanforderung neu und aktualisieren Sie die Einstellung für Letzter getesteter Build. Wenn die Änderungsanforderung den Status Verifiziert hat, werden keine automatischen Änderungen vorgenommen. Wenn die Änderungsanforderung den Status Offen hat, ist das Feld Adressiert in Build leer. Wenn sich der Status einer Änderungsanforderung von Behoben in Offen ändert, fällt sie in die Zuständigkeit des Benutzers, der ihr den Status Repariert oder Dokumentiert zugewiesen hat. In der Regel werden Änderungsanforderungen vom Teamleiter geschlossen. Vorgehensweise: Der Teamleiter führt einen der folgenden Schritte aus: Er überprüft und schließt die verifizierte Änderungsanforderung. 152
Er öffnet die Änderungsanforderung neu. Wenn die Änderungsanforderung den Status Geschlossen hat, werden keine automatischen Änderungen vorgenommen. Wenn die Änderungsanforderung den Status Offen hat, ist das Feld Adressiert in Build leer. Wenn sich der Status einer Änderungsanforderung von Behoben in Offen ändert, fällt sie in die Zuständigkeit des Benutzers, der ihr den Status Repariert oder Dokumentiert zugewiesen hat. Wenn der Status einer Änderungsanforderung sich von Verifiziert in Offen ändert, fällt sie in die Zuständigkeit des Benutzers, der ihr den Status Repariert oder Dokumentiert zugewiesen hat, und das Feld Adressiert in Build ist leer. *Statusänderungen können zur automatischen Änderung anderer Eigenschaften führen. Verwandte Verfahrensweisen Mit Änderungsanforderungen arbeiten 153
- Seite 101 und 102: Varianzansicht Schreibgeschützte R
- Seite 103 und 104: Ansichtstyp Referenz im Gegensatz z
- Seite 105 und 106: StarDraw (Beispiel-Serverkonfigurat
- Seite 107 und 108: Übersicht über die Projektadminis
- Seite 109 und 110: Übersicht über Projekte In einem
- Seite 111 und 112: Vergleichen und Zusammenführen von
- Seite 113 und 114: Ordner Dieses Thema bietet eine Üb
- Seite 115 und 116: Arbeitsordner für den Stammordner
- Seite 117 und 118: ♦ Sie können beim Einchecken and
- Seite 119 und 120: Verwandte Verfahrensweisen Anforder
- Seite 121 und 122: Themen Themen sind Konversationen m
- Seite 123 und 124: Labels In der Versionskontrolle wir
- Seite 125 und 126: Ein Label kann an einzelne Ordner o
- Seite 127 und 128: Übersicht über Referenzen Ordner
- Seite 129 und 130: In der aktuellen Ansicht gemeinsam
- Seite 131 und 132: Big Product::Big Product::Big Produ
- Seite 133 und 134: ♦ Big Product::Big Product::Big P
- Seite 135 und 136: Durch Hinzufügen von Elementen zu
- Seite 137 und 138: Angenommen, Sie fügen eine Datei z
- Seite 139 und 140: ♦ ...............Big Product::Big
- Seite 141 und 142: Angenommen, alle Ansichten außer d
- Seite 143 und 144: Auswahlversion In der Spalte "Eleme
- Seite 145 und 146: Testen und Berichtserstellung Die T
- Seite 147 und 148: Verwandte Konzepte Änderungsanford
- Seite 149 und 150: Modell für die Verfolgung von Änd
- Seite 151: Lebenszyklus für Änderungsanforde
- Seite 155 und 156: Berichte StarTeam bietet eine Vielz
- Seite 157 und 158: Diagramme Mit dem Cross-Platform Cl
- Seite 159 und 160: Felder StarTeamenthält sowohl allg
- Seite 161 und 162: Serverübergreifende Konfiguration/
- Seite 163 und 164: Serveradministrations-Tool Dieses T
- Seite 165 und 166: Anzeigefenster Wenn Sie über das M
- Seite 167 und 168: Cross-Platform-Client - Übersicht
- Seite 169 und 170: anzuzeigen, wählen Sie die Element
- Seite 171 und 172: ♦ Der Status von StarTeamMPX. Ein
- Seite 173 und 174: Diagrammlegende Die Diagrammlegende
- Seite 175 und 176: Der Layoutbereich des Formulars Der
- Seite 177 und 178: Ansichten vergleichen/zusammenführ
- Seite 179 und 180: ♦ Die Testperspektive enthält di
- Seite 181 und 182: Verwandte Konzepte Übersicht über
- Seite 183 und 184: Die Hauptversion von File Compare/M
- Seite 185 und 186: Ordner vergleichen/zusammenführen
- Seite 187 und 188: FCM-Menüs und -Symbolleiste Die ei
- Seite 189 und 190: Toolbar-Dienstprogramm Dieses Thema
- Seite 191 und 192: StarTeam Web Edition Dieser Abschni
- Seite 193 und 194: Komponentenregister Die Komponenten
- Seite 195 und 196: StarTeam Layout Designer-Benutzerob
- Seite 197 und 198: Borland Search Dieses Thema beschre
- Seite 199 und 200: Workflow Designer Dieses Thema besc
- Seite 201 und 202: Widerrufen Stellt eine zuvor rückg
Er öffnet die Änderungsanforderung neu.<br />
Wenn die Änderungsanforderung den Status Geschlossen hat, werden keine automatischen Änderungen<br />
vorgenommen.<br />
Wenn die Änderungsanforderung den Status Offen hat, ist das Feld Adressiert in Build leer. Wenn sich der<br />
Status einer Änderungsanforderung von Behoben in Offen ändert, fällt sie in die Zuständigkeit des Benutzers,<br />
der ihr den Status Repariert oder Dokumentiert zugewiesen hat.<br />
Wenn der Status einer Änderungsanforderung sich von Verifiziert in Offen ändert, fällt sie in die Zuständigkeit<br />
des Benutzers, der ihr den Status Repariert oder Dokumentiert zugewiesen hat, und das Feld Adressiert in<br />
Build ist leer.<br />
*Statusänderungen können zur automatischen Änderung anderer Eigenschaften führen.<br />
Verwandte Verfahrensweisen<br />
Mit Änderungsanforderungen arbeiten<br />
153
Change language