Wir markieren das Einchecken der Quellcodeverwaltung mit der festgestellten Fehlernummer oder der Erweiterungsnummer, die implementiert wurde.
Durch Abrufen des Check-in-Protokolls zwischen zwei Builds können Sie bestimmen, was implementiert oder behoben wurde.
Wie beantworten Sie die folgenden Fragen von Managern, Testern und anderen Personen in Ihrem Team:
In welchem Build ist der Bug # 829 behoben? Welche Aufgaben wurden in unserem aktuellen Test Build abgeschlossen?
So einfach ausgedrückt: Wie erreichen Sie die Rückverfolgbarkeit Ihrer Anforderungen, Aufgaben und Fehler, von der Berichterstattung bis zur Bereitstellung? Welche Prozesse, Werkzeuge und Techniken verwenden Sie, um dies zu erreichen?
Wir verwenden TFS in Verbindung mit JetBrains TeamCity für CI.
Beim Zuordnen von Check-ins zu Aufgaben werden die zugehörigen Aufgaben und Fehler mit der benutzerdefinierten Check-in-Richtlinie den Eincheckkommentaren mit ihren IDs und Titeln vorangestellt.
Diese Kommentare werden dann verwendet, um die Versionshinweise zu generieren, die automatisch für jeden Build generiert werden.
Wir verwenden einen verwalteten SVN-Dienst namens Beanstalk ( Ссылка ), mit dem Sie sich leicht an eine Reihe von Bug- / Feature-Management-Funktionen binden können Systeme. In unserem Fall verwenden wir Fog Creeks FogBugz für dieses Ende der Dinge. SVN / Beanstalk erlaubt Ihnen, sich Notizen zu machen, wenn Sie einen Build einchecken, der wiederum den Status von einem oder mehreren FogBugz beeinflusst > Fälle.
Auf Client-Seite verwenden wir Tortoise SVN und Visual SVN, um die Interaktion zwischen dem lokalen Client und dem Beanstalk SVN Server zu verwalten (Tortoise bietet den eigentlichen Dienst, Visual SVN bietet die Integration zwischen Tortoise SVN und MS Visual Studio) / p>
Ich empfehle beide Dienste und den Tortoise / Visual SVN-Client.
Wir verwenden Fogbugz, das eingebaute Subversion-Integration hat. Grundsätzlich gibt es ein Plugin für Fogbugz welches im Hintergrund nach SVN Check-ins sucht. Wenn Sie also beim Check-In eine Fogbugz-Case-ID angeben, wird diese automatisch mit diesem Check-in verknüpft.
Soweit ich weiß, brauchen Sie keine spezielle Anwendung (wie zB Beanstalk).
Der umgekehrte Weg ist wenig schwierig. In unserer Firma gibt es eine Konvention, dass es für jeden (zukünftigen oder vergangenen) Build eine "Veröffentlichung" in Fogbugz gibt. Wenn Sie einen Fehler beheben oder eine Funktion implementieren, ordnen Sie den Fall der richtigen Version zu.
Dann ist es ziemlich einfach, eine Liste aller implementierten Features von Build X zu erhalten.
Wir verwenden TRAC mit SVN in unserer Firma und führen täglich rollende Builds zu DEV / STAGING & amp; STABLE-Umgebungen mit regelmäßigen geplanten Bereitstellungen (einmal im Monat ... ish) für eine PRODUCTION-Umgebung.
Wenn ein Fehler gemeldet wird, wird er in TRAC eingegeben und erhält eine Ticketnummer (z. B. # 1001)
Wenn der Fehler behoben ist, wird der Code mit der Ticketnummer (# 1001) in den SVN-Eincheck-Notizen wieder in SVN eingecheckt.
Der Entwickler notiert die Nummer des SVN-Änderungssatzes (z. B. [5000]) und öffnet das TRAC-Web-Interface. Beim Schließen des Tickets geben sie die Änderungssatznummer in die Notizen des Tickets ein.
Auf diese Weise referenziert das SVN-Einchecken das Ticket ... und das Ticket verweist auf das SVN-Einchecken.
Unsere täglichen Builds werden dann gegen einen SVN Changeset ausgeführt (z. B. heutiger Build ist alles bis changeset [5050]) und eine Anmerkung dazu wird in unserer Bereitstellungsanzeige gemacht.
%Vor%Auf diese Weise wissen die Tester beim Überprüfen von Fixes zum Testen durch den Changeset in den Ticketkommentaren, ob der Build, den sie betrachten, das Update enthält.