Releaseablauf

OnDemand

OnDemand

Top Contributor
Hallo zusammen,

wir sind grad gut dabei uns stehen vor dem ersten Release unserer 1. Version. Für die Folgeversionen wollen wir wie folgt vorgehen:

Je Jira Issue einen Branch erstellen und da drin dieses Feature / Bug entwickeln.
Jeden zweiten Freitag wollen wir uns hinsetzen und die erledigten Jira Issues als Fertig markieren, diese werden Donnerstag in einen Testbranch gemerged und auf das Testsyste mdeployed. Also eine Art Qualitätskontrolle am Freitag.

Wenn ein Jira Issue Erledigt ist, soll dessen Branch in den Master gehen und released werden (jeden zweiten Samstag nach dem "Quality Friday")

1. Haltet ihr das für ein sinnvolles Vorgehen? Wir sind nur 3 Leute, daher übersichtlicher Haufen
2. Das kann man doch sicherlich irgendwie automatisieren mit dem Branch mergen oder?

Wie handhabt ihr das?
 
NicoDeluxe hat gesagt.:
Haltet ihr das für ein sinnvolles Vorgehen?
Zum Vergrößern anklicken....
Nein. Alle Branches zwei Wochen lang laufen lassen und dann alle auf einmal mergen wird vermutlich nur in einem riesigen Merge-Konflikt und endlosen Probleme enden 🙂 Gleiches gilt für die Issues, nur alle zwei Wochen Issues als erledigt markieren hat dann nur zur Folge, dass Issues zwei Wochen lang fertig sind, aber nicht als fertig erkennbar sind.

Potentiell kann Scrum zusammen mit Feature-Branchen eine Orientierung für euch sein (auch wenn richtiges Scrum bei drei Leuten nicht immer sinnvoll ist), vor allem da euer "Prozess" schon gewisse Ähnlichkeiten hat. Grob in etwa:
  • Zwei-Wochen Sprints
    • Wenn als sinnvoll erachtet: richtige Sprint-Planung am Anfang des Sprints, um Ziele festzustecken
  • Je "Feature" (welches je nach Jira-Prozess einem Issue entspricht) ein Branch
  • Wenn das Feature fertig ist (im Idealfall wenige(!) Tage) Pull-Request dafür erstellen, sobald möglich dann Review und Mergen auf den Master, zugehörige Issues werden dann direkt geschlossen. Master enthält damit immer einen review'ten und getestete Stand
  • am Ende des Sprints "Sprint-Review" (was in dem Fall mehr ein Qualitätscheck ist) des aktuellen Masters. Alles, was dann nicht gemerged ist, wird ignoriert. Danach wird dann veröffentlicht, solange nicht irgendwas aufgefallen ist

NicoDeluxe hat gesagt.:
-Das kann man doch sicherlich irgendwie automatisieren mit dem Branch mergen oder?
Zum Vergrößern anklicken....
Ja, das bietet eigentlich jeder Repository-Hoster und zur Not auch quasi jedes CI-System. Wie dass dann konkret geht, hängt vom konkreten System ab 🙂
 
Ah ok vielen Dank!
Sprints machen wir auch um einfach ein Ziel zu haben auf das man hinarbeitet.

Ok also je neuem FEATURE ein Branch.
Hier würde ich ein wenig umbauen: Test statt Master nehmen:

Dann den Issue auf "Qualitätskontrolle" setzen (ist ein interener Jira Status bei uns) da kann ich auch gleich einen Pull Request machen über JIRA automatisch. Würde hier allerdings in den Test-Branch mergen und nicht in den Master. Der Master ist eine immer auslieferbare, stabiler Branch (oder nicht?) Oder wo liegt der "saubere" Branch mit dem Releasefähigen Programm?

Wenn Spring (2 Wochen) rum sind checken wir den Testbranch ob alle funktionen machen was sie sollen und mergen in den Master. Bauen und haben ein neues Release.
 
NicoDeluxe hat gesagt.:
Ah ok vielen Dank!
Sprints machen wir auch um einfach ein Ziel zu haben auf das man hinarbeitet.

Ok also je neuem FEATURE ein Branch.
Hier würde ich ein wenig umbauen: Test statt Master nehmen:

Dann den Issue auf "Qualitätskontrolle" setzen (ist ein interener Jira Status bei uns) da kann ich auch gleich einen Pull Request machen über JIRA automatisch. Würde hier allerdings in den Test-Branch mergen und nicht in den Master. Der Master ist eine immer auslieferbare, stabiler Branch (oder nicht?) Oder wo liegt der "saubere" Branch mit dem Releasefähigen Programm?

Wenn Spring (2 Wochen) rum sind checken wir den Testbranch ob alle funktionen machen was sie sollen und mergen in den Master. Bauen und haben ein neues Release.
Zum Vergrößern anklicken....
So kann man es auch machen (und so läuft es quasi auch bei uns im Projekt, außer das der branch nicht test heißt, sondern develop).

Sinnvoll ist dabei zweierlei:
* QS im Rahmen des Pull-Requests vornehmehmen, also nur Dinge mergen, die auch durch eine Qualitätssicherung gelaufen ist
* Niemand darf direkt in den test oder master mergen. Insbesondere in den master würde ich es explizit verbieten
 
Perfekt 🙂 Und was, wenn ich einen Bug fixen muss? Irgendwas, das nicht warten kann?
Hotfix-Branch machen > in Test mergen und Funktion testen, wenn iO in den Master und ausliefern? Dann halt nicht erst zum Sprint-Ende

Ihr macht also die Qualitätssicherung, wenn sich jemand den Pull Request vornimmt? Wenn iO nehmt ihr das aus dem Develop in den Master?
Macht ihr dann keine extra Branches pro Bug/Feature/Issue?
 
NicoDeluxe hat gesagt.:
Ok also je neuem FEATURE ein Branch.
Zum Vergrößern anklicken....
Kommt natürlich auch ein bisschen drauf an, welche Ticket-Typen es gibt und wie man Features schneidet und auf Tickets verteilt. Eine feste Regel gibt es da nicht – aber ein Branch sollte im Idealfall schon eine in sich geschlossene Einheit bilden.

Wenn man Features noch mal in Tickets unterteilt kann man auch die Unterteilung als Grundlage für Branches nutzen, oder trotz der Unterteilung weiterhin Branch per Feature.


NicoDeluxe hat gesagt.:
Dann den Issue auf "Qualitätskontrolle" setzen (ist ein interener Jira Status bei uns) da kann ich auch gleich einen Pull Request machen über JIRA automatisch.
Zum Vergrößern anklicken....
Ja stimmt, ein Status zwischen "In Bearbeitung" und "Fertig" ist sinnvoll, dass hatte ich oben nicht erwähnt 🙂

NicoDeluxe hat gesagt.:
Hier würde ich ein wenig umbauen: Test statt Master nehmen
[...]
Würde hier allerdings in den Test-Branch mergen und nicht in den Master. Der Master ist eine immer auslieferbare, stabiler Branch (oder nicht?) Oder wo liegt der "saubere" Branch mit dem Releasefähigen Programm?
Zum Vergrößern anklicken....
Um das etwas abstrakter zu behandeln:

Kenntlich machen würde ich:
1. das letzte Release (bzw, jedes Release)
2. den aktuellen, baubaren Stand
3. jedes aktuell in Entwicklung befindliche Feature

1: würde ich mit Tags abbilden, und wenn nötig (zB für Bugfixes innerhalb der zwei Wochen) ein Branch für das letzten Release, da kommen aber dann nur Bigfixes innerhalb der zwei Wochen drauf, nichts anderes.
2: ein Haupt-Branch, was immer der aktuellste Stand ist. Innerhalb der zwei Wochen ist das alles, was schon gemerged wurde, direkt nach Release ist das identisch zum letzten Release (bis wieder irgendwas gemacht wurde). Jeder Feature-Branch geht davon ab.
3: Feature-Branches, die gehen jeweils nur vom Haupt-Branch ab


In deiner Struktur wäre "master" das letzte Release, und "test" der aktuelle, baubare Stand. In meiner wäre "release" das letzte Release (wenn nötig, eher nur als Tag vorhanden), und "main"/"master" der aktuelle, baubare Stand der zum Entwicklen genutzt wird.

Je nachdem wie du deins konkret meintest, ist das nur ein Unterschied in der Benennung, und da muss man im wesentlichen was finden, was jeder versteht 🙂
 
NicoDeluxe hat gesagt.:
Perfekt 🙂 Und was, wenn ich einen Bug fixen muss? Irgendwas, das nicht warten kann?
Hotfix-Branch machen > in Test mergen und Funktion testen, wenn iO in den Master und ausliefern? Dann halt nicht erst zum Sprint-Ende

Ihr macht also die Qualitätssicherung, wenn sich jemand den Pull Request vornimmt? Wenn iO nehmt ihr das aus dem Develop in den Master?
Macht ihr dann keine extra Branches pro Bug/Feature/Issue?
Zum Vergrößern anklicken....

Um mit den Namen nicht weiter zu verwirren bleibe ich mal bei "Release-Branch", "Haupt-Branch" (aktueller Stand) und "Feature-Branch"/"Bugfix-Branch":

Beim Entwickeln:
  1. Feature-Branch wird von Haupt-Branch abgezweigt
  2. Auf dem Feature-Branch wird entwickelt
  3. Wenn Feature fertig: Pull Request
  4. Wenn Pull Request angenommen: Merge Feature-Branch in Haupt-Branch
  5. Wenn PR abgelehnt: weiter mit 2

Beim Release:
  1. Merge Haupt-Branch in Relase-Branch/Kennzeichnen mit Tag

Bug-Fix für aktuelles Release:
  1. Bugfix-Branch abzweigen von Release-Branch
  2. Auf dem Bugfix-Branch wird entwickelt
  3. Wenn Bugfix fertig: Pull Request auf Release-Branch
  4. Wenn Pull Request angenommen: Merge Bugfix-Branch in Release-Branch, Taggen des neuen Standes
  5. Portieren des Bugfixes auf den Haupt-Branch, wie genau hängt von den Umständen ab, möglich ist z.B. Cherry Pick, das ganze aber wieder mit Pull Request

Jeder Pull Request ist dabei Qualitätskontrolle, die findet also dauerhaft und nicht nur am Ende statt.
 
Super das klingt ja ganz wunderbar danke schon mal🙂 Da setzen wir uns mal zusammen und gehen den Git Flow durch.

Was ich aber noch nicht kapiere: was ist mit taggen gemeint?
Und wenn der Master neu gebaut wurde, wir könnte man am besten die Benutzer updaten? Kann der Client irgendwo beim Start anfragen ob es eine neue Version gibt? Oder welche best pratice gibts da?

Einen Updatezwang wollen wir eigentlich nicht, aber es wäre uns schon lieber, wenn immer alle auf dem neuesten Stand sind.
 
Taggen ist ein Konzept aus GIT.

Du setzt ein Tag auf einen Versionsstand und kannst dann diesen Stand z.B. auschecken. In Regel taggt man jede releaste Version. Wenn dann ein Fehler in Version 2.7.19 gemeldet wird, kann man git checkout 2.7.19 machen und hat genau den Versionsstand. (Oder wie auch immer man die Tags exakt benennt).
 
Man wird nicht umher kommen sich mit GIT auch außerhalb von Jira und Bitbucket zu beschäftigen. 80% gehen damit, für die restlichen 20% braucht man entweder die Kommandozeile oder entsprechende Tools wie Sourcetree oder TortoiseGit (oder den in Eclipse integrierten GIT-Client)
 
Eine Alternative zu Branching könnte für euch auch "trunk-based" Development mit Feature-Toggles sein. Beim letzten Projekt/Kunden war dies das Modell der Wahl. Dort gab es ca. 30 Teams mit durchschnittlich 7 Personen pro Team und alle haben nach diesem Modell gearbeitet. Hier wurde dann auch wirklich ca. 2-5 Mal mit einem Service amselben Tag Live gegangen.

Das Modell sieht so aus:
- Es gibt keine Feature-Branches mehr, sondern nur noch persönliche "Staging"-Branches, die kurzzeitig hinter dem master liegen, wenn Unit- und Integrationstests auf den eingecheckten Änderungen laufen
- Nach Build- und Test-Erfolg wird der Stand auch sofort in den master Branch übernommen und danach automatisch auf Testsysteme/-deployments ausgerollt

Pro
- frühe Integration des Codes führt zu schnelleren Entwicklungszyklen und früher Fehlerbehebung
- Es werden immer integrierte Stände deployt, es gibt daher kein gegenseitiges Überspielen von Testständen auf Abnahmesystemen
- Entkopplung von fachlichem und technischem Livegang führt in beiden Fällen zu beschleunigter Auslieferung von Features
- Rollback-Prozesse, beim Integrieren von nicht funktionierenden Ständen, werden nahezu überflüssig
- Grundlage für A/B-Tests u.ä. (meistens direkt Unterstützt durch entsprechende Libraries oder Services)

Kontra
- Code wird komplexer (weil mit Feature-Toggles gearbeitet wird)
- Es werden mehr Tests benötigt, um alternierende Togglestände abzudecken
- Code enthält häufig ungenutzte Zweige, wenn Toggles nicht konsequent ausgebaut werden, oder es langalufende Experimente gibt
- Serviceüberspannende Features sind ggf. kompliziert umzusetzen
- Es wird zusätzlich eine Toggle-Library oder ein Toggle-Service benötigt

Feature-Toggles dienen hier nun generell dazu, den technischen Livegang (Code ist schonmal deployed) von einem fachlichen Livegang (User kann das Feature auch nutzen) zu trennen. Hierdurch können sehr schnell (Schalter umlegen) Änderungen getestet und wieder zurückgeschaltert werden.

Nach den eineinhalb Jahren, die ich da war, bin ich aktuell wieder in einem Projekt nach GitHub-Flow-Modell und es fühlt sich so uuuuuuunglaublich träge an.

EDIT: Und da ist dann ein "Release" immer eine riesengrosse Sache, wo sich alle zusammenfinden, mühsam über die JIRA Tickets gehen, die als für dieses "Release" abgeschlossen markiert wurden, und gucken, ob alles so gut ist. Das dauert manchmal wirklich den halben Tag, weil sich einfach über zwei oder drei Wochen sooo viel aufakkumuliert hat, dass nach der Zeit kaum noch jemand weiss, was da eigentlich gemacht wurde und ob sich das mit anderen Features/Fixes noch verträgt.
Beim trunk-based Ansatz mit mehreren Livegängen/Releasen pro Tag hatten zumindest wir im anderen Projekt diese Probleme nicht. Es gab dort einfach kein "zeremonielles" Release, wo man sich zusammenfindet und dann voller Erwartung auf einen Knopf drückt. 🙂
Stattdessen wurde halt einfach ständig released und es gab keine Release-Versionen. Weil zu jedem Zeitpunkt, wo man eine Änderung live stellt, waren die einzelnen Änderungen an sich immer sehr sehr klein.
Um sowas zu können, braucht man natürlich auch ein funktionierendes Continuous Deployment Modell. In unserem Falle damals war es ein Rolling Deployment, bei dem alte Instanzen batch-weise durch neue Serviceversionen ersetzt wurden und es niemals eine Downtime gab.
Das hätte auch sehr viel Geld gekostet, wenn es anders wäre (war der grösste deutsche Versandhändler).
 
Zuletzt bearbeitet:
Das von @httpdigest beschriebene würde ich auch immer als Ziel sehen. Also nicht z.B. das oben von @LimDul und mir beschreiben umsetzen und dann ist man fertig, sondern den aktuellen Zustand immer als Grundlage für Verbesserungen nutzen, um dann im Idealfall wirklich bei "jeder Push kann Deployed werden" zu landen.

Das größte Problem dabei, was ich besonders auch bei @NicoDeluxe sehen würde, ist, dass das Team entsprechende Mentalität und besonders auch Können mitbringen und auch eine technische Basis dafür schaffen muss.
Wenn der aktuelle Stand gar kein Prozess ist, und schon ein "alle zwei Wochen wird alles gemerged" als Verbesserung durchgeht, würde ich das noch sehr weit davon entfernt sehen.

Das oben beschriebene kann dann ein sinnvoller Zwischenschritt sein, der ein paar der Vorteile aufgreift. Insbesondere möglichst kurzlebige Branches, schnelles Mergen und ein zentraler Branch, der immer lauffähig ist, ist da meist schon ein großer Schritt in die richtige Richtung – ist aber gleichzeitig durch explizite Pull Requests und Releases mit vorherigen Review deutlich fehlertoleranter und auch für unerfahrenere Teams einfacher umsetzbar.
Meistens werden mit mehr Zeit und mehr Erfahrung die Features kleiner und die Feature-Branches kurzlebiger, gleichzeitig steigt die Qualität des Projekts und die Automatisierung der Prozesses – im Zweifel mit etwas "Druck" von "Außen" – und man nähert sich dem Trunk Based Development an.
 
Trunk based klingt echt sehr sagen wir überprofessionell für uns. Wir sind froh wenn wir überhaupt einen Prozess installiert bekommen der Struktur hat. Reicht uns auch fürs erste aus glaube 🙂
 
Hab hier noch ne Frage zu.

Ein Teammitglied ist kein Entwickler, kann also nicht entscheiden ob der Code io ist für den ein PR erstellt wurde. Seine Aufgabe ist es, die Features im Testsystem zu testen.

Simples Beispiel:
Issue "Issue 123 - Neues Feauture: PDF drucken"

Branch wird erstellt, entwickelt und der Branch "Issue 123" wird in den "Develop" Branch gemerged.
Entwickler macht einen Pullrequest

Der Developbranch wird jede Nacht gebaut (oder direkt nach dem Commit auch iO) und die neuere Versoin geht auf den Testserver. Der besagte Kollege schaut dann ob die PDF wie erwartet gedruckt wird und bestätigt den PullRequest damit geht das in den Master.

Wäre das auch ein mögliches Vorgehen? Wir brauchen nämlich die Chance, das der Nicht-Entwickelnde Kollege die neuen Feautures, behobenen Bugs usw testen kann
 
NicoDeluxe hat gesagt.:
Branch wird erstellt, entwickelt und der Branch "Issue 123" wird in den "Develop" Branch gemerged.
Entwickler macht einen Pullrequest

Der Developbranch wird jede Nacht gebaut (oder direkt nach dem Commit auch iO) und die neuere Versoin geht auf den Testserver. Der besagte Kollege schaut dann ob die PDF wie erwartet gedruckt wird und bestätigt den PullRequest damit geht das in den Master.
Zum Vergrößern anklicken....
Wenn ihr mit Pull Requests arbeitet, sollte das eher genau andersrum sein: erst der Pull Request, wenn der i.O. ist wird in den Develop-Branch gemerged. Die Trennung von Develop und Master dient dann eigentlich nur noch dazu, das eigentliche Release unabhängiger zu machen.

Aber Ja: das jeder Feature-Branch testbar ist, und auch in einer extra Umgebung zum Testen deployed wird, ist durchaus das Ziel des ganzen Prozesses 🙂
 
Ich würde auch vorschlagen, dass ihr erstmal einfach startet. Ein passender Entwicklungs-/Test-/Deployment-/Release-prozess ist niemals so, wie man ihn haben will und man muss _immer_ reflektieren (z.B. in Retrospektiven-Terminen), was man daran noch verbessern könnte und warum. Insbesondere, wenn man gerade anfängt, stellt sich der "Pace" und das Gefühl des Prozesses erst nach einer Weile bei den Teammitgliedern ein. Einige wünschen sich dann vielleicht mehr in Richtung "Flexibilität" und Geschwindigkeit, und andere wünschen sich eventuell mehr "Prozess" und stringenteres "Korsett".
So muss man den Prozess immer reflektiert betrachten und für alle Teammitglieder in Richtung Verbesserung entwickeln.
Den richtigen Prozess zu finden, ist also eigentlich ein nicht-erreichbares Ziel, weil sich ständig die Anforderungen und die Rahmenbedingungen für den Prozess ändern. Man kann nur reflektieren und gegensteuern.
 
Ok Danke. Erstes Ziel wäre mal: Wenn xx Issues erledigt wurden, muss der Test-Verantwortlich (oder alle zusammen je nach Umfang) das ganze System in einer Testumgebung haben um die xx Issues "abzunehmen".

Wie könnte man das erreichen? Sonst hab ich die den Entwicklungsbranch des Issues in den Develop (Test) Branch gemerged und den aufs Testsystem gespielt. Wenn alles iO war, wurde es in den Master gegeben.

Dann machen die Pull Requests in dem Fall ja keinen Sinn, richtig? Gibts ja keinen "über uns" der die genehmigen könnte
 
Aktuell verwenden wir zumindest gerade zwei Pull Requests für ein Feature. Der erste Pull Request (bzw. in GitLab CI/CD = "Merge Request" genannt) geht in den "develop" Branch, aus dem dann die Testsysteme deployed werden.
Und der zweite Pull/Merge Request geht auf "master". Der wird dann erst gemerged, wenn der auf develop okay ist.
Und das dann natürlich entsprechend automatisiert. Also, niemand legt mehr "manuell" einen Merge/Pull Request an, sondern die CI Pipeline macht das.

Aber generell gilt: Macht euch gerne selber Gedanken, welche konkreten Probleme ihr habt und wie man diese lösen könnte. Dieser Erkenntnis/Entwicklungsprozess ist meiner Meinung nach wertvoller als das Ergebnis an sich. Denn es befähigt dich dann immer mehr, solche "DevOps Engineer"-Rolle (würde man wohl heute dazu sagen) in anderen Projekten einzunehmen.
 
Merge Request? Heißt das nur so bei gitlab oder ist das wieder was anderes 😀

Wir werden morgen mal beginnen erstmal das wir ein für uns passendes System fürs Testen finden. Das war bisher immer Chaos. Oder es wurde verworfen und kleine Sachen im Master gebaut, die dann oh wen wunderts, Probleme verursacht haben. Da muss jetzt Struktur her
 
Hey, ich muss das Thema nochmal raus holen.

Folgender Ablauf ist momentan gegeben, aber irgendwie muss ich andauernd hin und her zwischen Jira und IntelliJ. Gibt es in IntelliJ vielleicht einen besseren Workflow?

1. Jira Issue wird angelegt
2. Jira Issue wird dem Sprint zugewiesen
3. Sprint wird begonne

4. Der Issue 123 ist dran, ich erstelle in Jira einen Branch und schiebe den Issue zu "in Arbeit"
4.1 ich checke den Branch lokal aus und verschlimmbessere den Fehler
4.2 ich bin lokal fertig und pushe den Branch zurück
Nun muss der Branch mit dem Namen Issue 123 in den "Dev" branch damit es gebaut wird. Dazu muss ich nun wieder zurück zu Jira, einen Pullrequest erstellen, genehmigen und in dev mergen.
Dann wieder zurück zu IntelliJ, Pull auf Dev, den alten Issue123-Branch löschen

5. ich schiebe den Issue auf "Qualitätsprüfung", Kollege bekommt eine Info
6. Dev-Branch triggered einen Build und updated das Testsystem damit die Tester testen können

Das fettgeschriebene ist nervig. Ich könnte zwar auch in Intellij den Branch123 in Dev mergen, aber dann bleibt der Branch in Jira und Bitbucket. offen.

7. wenn Kollege sein OK gibt, wird ein Pullrequest in den Master erstellt und gemerged

Jemand ne Idee wie man das vereinfach könnte, ohne dass ich immer im Dev arbeite?

Edit: eigentlich reicht es doch wenn ich in der IDE einen neuen Branch erzeuge, mit dem Issue-Namen. Da drin baue und wenn es fertig ist in den Dev branch merge und dann pushe. Eigentlich brauchen wir in Jira die Branches gar nicht, da wir da ohnehin nur den DEV Branch bauen
 
Zuletzt bearbeitet:
Man kann Jira und Bitbucket verbinden, sodass Jira automatisch Änderungen im Repo mitbekommt (Sichwort web hook). Dann kannst Du den Branch über gitflow entweder über CMD oder über das git-flow plugin für Intellij anlegen. Wenn Du z.B. einen feature branch erstellst, der mit der Ticket ID (NN-123) beginnt, verbindet Jira den branch automatisch mit dem Ticket.
Wenn Du jetzt das feature abgeschlossen hast, kannst Du (sofern Smart commits in Jira konfiguriert sind) einfach eine commit message wie folgt schreiben "NN-123 #newjirastaus adds feature xyz" Jira verschiebt dann das Ticket automatisch in den Status den Du angegeben hast.

Wenn der PR entsprechend approved wurde, kannst Du über gitflow einfach das feature beenden und der merge sowie der cleanup passiert automatisch. Das geht aber nur, wenn Ihr in Bitbucket keine Restriktion zum Pushen in den develop gesetzt habt.
Wenn Ihr das gemacht habt, kannst Du in Bitbucket beim erstellen des PR angeben, dass der branch nach dem mergen automatisch gelöscht wird. Dann musst Du nur noch den localen branch aufräumen.
 
Ich habe auch das Plugin Bitbucket Linky noch installiert. Dann muss ich mir die Links zu den Repos nicht merken und bin mit einem Kick im Repo in Bitbucket.
 
Ich muss hier nochmal nachfragen sorry 😀
HAb es jetzt so, dass wenn in DEV gepushed wird, jednkins baut und auf das Testsystem deployed.

Wenn wir dann einen Sprint beenden, releasen wir auch eine neue Version. sagen wir 1.0.2
Dann dachte ich, splitte ich von DEV (der ja release candidate ist weil alles getestet usw), erstelle ein neuen Job in Jenkins und einen neuen Branch namens 1.0.2.

Jenkins baut dann und die Version ist für immer verfügbar, sollte man mal zurück müssen, das selbe wird dann in den Master gemerged (oder ist der Master dann nicht mehr nötig?)

Macht das Sinn?
 
Danke! Der wichtigste Satz ist wohl "Es ist zudem üblich, alle Commits im master-Branch mit einer Versionsnummer zu taggen."

Verstehe ich es richtig, dass ich dann anhand des Tags einen bestimmt Versions-Stand auschecken kann? Wo genau setzte ich den Tag, wenn ich aus dev in den master merge in Bitbucket?
 
NicoDeluxe hat gesagt.:
Verstehe ich es richtig, dass ich dann anhand des Tags einen bestimmt Versions-Stand auschecken kann?
Zum Vergrößern anklicken....
Ja, ein Tag ist eigentlich nichts anderes als ein Zeiger auf einen bestimmten commit. Damit muss man sich dann aber nicht die commit id merken.

Wenn du git-flow nutzt, macht git das automatisch. Ansonsten kannst Du das auch mit Bitbucket nach dem merge in den master, oder jedem beliebigen Git client machen. Das ganze kannst Du auch rückwirkend bei jedem beliebigen commit machen.
 

Aktuelle Jobs

Neue Themen


Zurück
Oben