Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen Revision Vorhergehende Überarbeitung
Nächste Überarbeitung
Vorhergehende Überarbeitung
de:modul:ffit:3-jahr:cicd:learningunits:lu11:a [2026/05/12 00:38] apeterde:modul:ffit:3-jahr:cicd:learningunits:lu11:a [2026/05/19 11:38] (aktuell) apeter
Zeile 3: Zeile 3:
 ==== Umgebungen ==== ==== Umgebungen ====
 Bislang war es möglich nur auf dem Master/Main-Branch zu arbeiten und diesen Stand auch für das Deployment zu nutzen.  Bislang war es möglich nur auf dem Master/Main-Branch zu arbeiten und diesen Stand auch für das Deployment zu nutzen. 
-Bei grösseren Projekten nutzt man in der Regel verschiede Umgebungen. +Bei grösseren Projekten nutzt man in der Regel verschiedene Umgebungen. 
  
 Die genaue Benennung und Aufstellung variiert natürlich je nach Vorgehen, Team und Projekt. Die grundlegendsten Umgebungen sind jedoch Dev/Develop, Test/UAT/QA und Prod. Die genaue Benennung und Aufstellung variiert natürlich je nach Vorgehen, Team und Projekt. Die grundlegendsten Umgebungen sind jedoch Dev/Develop, Test/UAT/QA und Prod.
Zeile 20: Zeile 20:
 Darüber hinaus wird jedoch zusätzlich oft auch noch mit sogenannten Feature-Branches gearbeitet. Beim Beginn einer Story wird ein neuer Git-Branch abgezweigt und nach lokaler Implementation wieder in den Develop-Branch "gemerged" (beziehungsweise "gerebased"). Dadurch kann zum Beispiel sichergestellt werden, dass sich die einzelnen Entwickler sich nicht gegenseitig stören und dass nur syntaktisch korrekter und somit lauffähiger Code auf der Development-Umgebung landet. Darüber hinaus wird jedoch zusätzlich oft auch noch mit sogenannten Feature-Branches gearbeitet. Beim Beginn einer Story wird ein neuer Git-Branch abgezweigt und nach lokaler Implementation wieder in den Develop-Branch "gemerged" (beziehungsweise "gerebased"). Dadurch kann zum Beispiel sichergestellt werden, dass sich die einzelnen Entwickler sich nicht gegenseitig stören und dass nur syntaktisch korrekter und somit lauffähiger Code auf der Development-Umgebung landet.
  
-Hotfix-Branches werden jeweils bei einem Ausliefern eines Releases erstellt und dienen dazu, kleine Änderungen mit dem produktiven Codestand zu testen, ohne von den den neu entwickelten Features beeinflusst zu werden. An dieser Stelle möchte ich nochmals das Semantic Versioning in Erinnerung rufen.+Hotfix-Branches werden jeweils bei einem Ausliefern eines Releases erstellt und dienen dazu, kleine Änderungen mit dem produktiven Codestand zu testen, ohne von den den neu entwickelten Features beeinflusst zu werden.  
 + 
 +An dieser Stelle möchte ich nochmals das Semantic Versioning in Erinnerung rufen. Hotfixes erhöhen wie Bugfixes die Patch-Version und durchlaufen in der Regel nie die Development-Umgebung. Reguläre Änderungen wie neue Features durchlaufen diese Umgebungen und sorgen für eine Anpassungen der Minor- oder gar Major-Version. 
 + 
 +Nächtliche Builds oder (teils ungetestete) Pre-Release-Versionen werden mittels Suffix angegeben.
  
 {{:de:modul:ffit:3-jahr:cicd:learningunits:lu11:semantic_versioning.png?600|}} {{:de:modul:ffit:3-jahr:cicd:learningunits:lu11:semantic_versioning.png?600|}}
 +© [[https://www.baeldung.com/cs/semantic-versioning|Baeldung - A Guide to Semantic Versioning]]
 +
 +
  
-''TODO'' 
  • de/modul/ffit/3-jahr/cicd/learningunits/lu11/a.1778539090.txt.gz
  • Zuletzt geändert: 2026/05/12 00:38
  • von apeter