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]).

Content Disclaimer

Informasi ini disarikan dari Wikipedia dan disajikan kembali untuk tujuan edukasi. Konten tersedia di bawah lisensi CC BY-SA 3.0. Kami tidak bertanggung jawab atas ketidakakuratan data yang bersumber dari kontribusi publik tersebut.

  1. The information displayed on this website is sourced in part or in whole from Wikipedia and has been adapted for the purpose of restating it. We strive to provide accurate and relevant information, however:
  2. There is no guarantee of absolute accuracy. Wikipedia is an open, collaborative project that can be edited by anyone, so information is subject to change.
  3. It is not intended to constitute professional advice. The content displayed is for informational and educational purposes only. For important decisions (e.g., medical, legal, or financial), please consult a professional.
  4. Content copyright. Wikipedia is licensed under the Creative Commons Attribution-ShareAlike License (CC BY-SA). This means that content may be reused with appropriate attribution and shared under a similar license.
  5. Responsible use. Any risk arising from the use of information from this website is entirely the responsibility of the user.