Code-Freeze

Der Code-Freeze bezeichnet innerhalb eines Software-Projekts den Zeitpunkt, ab dem sich der Quellcode der Software bis zur endgültigen Veröffentlichung der aktuellen Version nicht mehr ändern soll. Erlaubt sind allerdings noch Änderungen zur Behebung von im Test der Software entdeckten Fehlern von größerer Relevanz.

In der Praxis der Software-Entwicklung wird der Code-Freeze in der Regel am Beginn der Systemtestphase[1] festgelegt, d. h. mehrere Wochen, u. U. auch Monate vor der geplanten Veröffentlichung einer Software-Version, damit noch ausreichend Zeit für den Test der endgültigen Version der Software ist. Das Ziel ist, die Zahl der Fehler in der veröffentlichten Software zu minimieren.

Allgemeines

In einem Software-Projekt werden während der Implementierungsphase, das heißt während der Erstellung des Quellcodes, regelmäßig Änderungen am bestehenden Code vorgenommen, zum Hinzufügen neuer Features und zum Beheben von aufgetretenen Fehlern. Nach dem Code-Freeze-Zeitpunkt dürfen Änderungen zum Hinzufügen neuer Features nicht mehr vorgenommen werden; die Software wurde praktisch auf ihrem aktuellen Stand eingefroren.[2] Änderungen zur Behebung von im Test entdeckten Fehlern dürfen im Allgemeinen noch vorgenommen werden, solange der Nutzen, der durch das Beheben des Fehlers entsteht, in einem vernünftigen Verhältnis steht zum Risiko, das durch die erneute Änderung des Quellcodes und der damit verbundenen Möglichkeit des Einfügens neuer Fehler in die Software unvermeidbar entsteht. In der Regel werden hier spezielle Anforderungen an jede Änderung gestellt. So ist es üblich, dass ein Software-Entwickler die Entscheidung zur Änderung des Codes nach dem Code-Freeze nicht selbst treffen kann. Die Entscheidung wird stattdessen meistens durch ein mehrköpfiges Gremium gefällt.

Praktische Umsetzung

Da sich der Quellcode in Software-Projekten in der Regel in einem System zur Versionsverwaltung befindet, ist ab dem Code-Freeze ein Einbringen einer neuen Version von Quellcode-Dateien durch „einchecken“ (check in) oder „mergen“ (bei der Verwendung von Branches) für den einzelnen Entwickler nicht oder nur noch nach Erfüllen bestimmter Bedingungen möglich.

Einzelnachweise

  1. ↑ Johannes Siedersleben: Softwaretechnik: Praxiswissen für Softwareingenieure. Hanser Verlag, 2003, ISBN 978-3-446-21843-7, S. 298 (google.de [abgerufen am 25. August 2011]).
  2. ↑ Ronald Mascitelli: The Lean Product Development Guidebook: Everything Your Design Team Needs to Improve Efficiency and Slash Time-to-market. Technology Perspectives, 2007, ISBN 978-0-9662697-3-4 (google.de [abgerufen am 20. August 2024]).