Was ist der beste Weg, um ein genaues Release-Änderungsprotokoll zu erstellen?

Ich arbeite an einigen Projekten, bei denen ich mit jeder Version ein genaues Änderungsprotokoll bereitstellen möchte, aber ich habe keine Methode zum Sammeln des Änderungsprotokolls gefunden, die problemlos funktionieren würde. Das Problem ist meistens, wenn die Zeit zwischen den Versionen lang ist und jede Version mit vielen Funktionen und Fehlerkorrekturen geliefert wird und wenn die Software mehrere Zweige gleichzeitig entwickelt.

Einige Optionen, die ich in Betracht gezogen habe:

1. Erstellen Sie das Änderungsprotokoll aus Festschreibungsnachrichten und fordern Sie die Entwickler auf, die Nachrichten so zu schreiben, als würden sie eine Zeile für das Änderungsprotokoll schreiben (was sie effektiv tun würden).
   • Funktioniert möglicherweise nicht, wenn mehrere Zweige vorhanden sind und zwischen Zweigen zusammengeführt werden (möglicherweise ist es schwierig zu wissen, welche Commits letztendlich in der Version enthalten sind).
2. Fordern Sie, dass für jede Änderung des Codes ein entsprechendes Ticket im Bug-Tracking-System vorhanden sein muss. Das Changelog könnte basierend auf den Tickets geschrieben werden.
   • Die Entwickler finden es möglicherweise frustrierend, ein Ticket für selbst geringfügige Änderungen zu erstellen, insbesondere wenn das Erstellen des Tickets länger dauert als das Beheben des Fehlers.
3. Fordern Sie die Entwickler auf, das Änderungsprotokoll (als Textdatei im Projektstamm) immer zur gleichen Zeit zu aktualisieren, wenn sie Änderungen am Code vornehmen.
   • Fühlt sich an wie Handarbeit, die automatisiert werden könnte.
4. Lassen Sie den Projektmanager den Unterschied zwischen der aktuellen und der vorherigen Version nehmen und das Änderungsprotokoll an diesem Punkt basierend auf den Änderungen schreiben.
   • Zusätzliche Arbeit für die Person, die für die Veröffentlichung verantwortlich ist, und es ist möglicherweise nicht offensichtlich, wie sich eine Änderung in der Praxis auswirkt, wenn Sie sich nur den Code ansehen.
5. Versenden Sie nur die Funktionen, die für die Veröffentlichung geplant wurden. Sie können das Änderungsprotokoll schreiben, noch bevor Sie mit dem Codieren beginnen.
   • Keine echte Option, es sei denn, Sie verwenden das Wasserfallmodell.

Ich habe jedes davon oder eine Variation davon in der Vergangenheit verwendet, aber sie waren zu unzuverlässig, mühsam oder starr. Hat jemand eine magische Kugel oder gute Ideen, wie man das Problem löst?

Wenn Sie nicht bereits die Anforderung eines Tickets für jede Änderung haben, erscheint es sinnvoll, Entwickler zu veranlassen, für jede Änderung ein Ticket zu erstellen, das wichtig genug ist, um im Änderungsprotokoll zu landen.

Wenn die Änderung signifikant genug ist, um Benutzer darüber zu informieren, möchten Sie diese Änderung wahrscheinlich trotzdem unter einem Ticket vornehmen, und das Schreiben beschreibender Tickets ist eine gute Praxis. Außerdem können Sie dies mit der Release-Versionierung und der Roadmap-Unterstützung Ihres Bug-Trackers verknüpfen.

Fühlt sich an wie Handarbeit, die automatisiert werden könnte.

Wie könnte es automatisiert werden? Das Änderungsprotokoll muss nicht bei jedem Commit bearbeitet werden, sondern nur, wenn eine erwähnenswerte Funktion hinzugefügt wird. Kommt das in Ihrer Software so oft vor, dass es mühsam ist, jedes Mal eine Zeile zum Änderungsprotokoll hinzuzufügen?

Sie könnten sagen, dass dies die Pflicht der Qualitätssicherung ist, das Änderungsprotokoll auf dem neuesten Stand zu halten, aber einige Softwarekonfigurationsmanagementsysteme oder Issue-Tracker können das Änderungsprotokoll automatisch für Sie generieren, was in einer Umgebung mit mehreren Entwicklern nützlich ist. Dies setzt voraus, dass Sie die Funktion / Problemverfolgung so verwenden, wie sie beabsichtigt ist.

Beispielsweise verfügt der Open-Source-Issue-Tracker Trac über ein ChangeLogMacro .

Andere Issue-Tracker verfügen möglicherweise über ein Makro oder ein Plug-In, mit dem das Änderungsprotokoll für Sie erstellt werden kann. Es ist normalerweise eine einfache Abfrage, alle Tickets / Probleme auszuwählen, die zwischen der letzten Version und der aktuellen Version geschlossen wurden.