Release Management

Andreas · 09.01.2012, 17:22

Hallo zusammen,

ich fange gerade damit an, mich mit Release Management zu beschäftigen. Jetzt bin ich auf der Suche nach einer geeigneten Strategie, um den vorhandenen Ablauf zu optimieren.

Erstmal die Voraussetzungen:
- Zur Code-Versionierung wird SVN verwendet
- Zum Deployment soll ANT verwendet werden (der alte Ablauf basiert darauf)
- Vor dem Deployment wird alles mit einem Encoder "verschlüsselt"
- Die Versionsnummer ist immer ein Major-Release + Service-Pack + Patchlevel (also beispielsweise 5.4.9)
- Die Versionsnummer, Service-Pack und Patchlevel sind immer vergeben (5.4.0, 5.4.1, etc.)
- Es existiert immer eine aktuell freigegebene Version (Stable) und hin und wieder soll eine BETA erstellt werden, damit sie getestet werden kann

Aktuell ist der Ablauf grob so:
- Für jedes Major-Release wird ein Branch erstellt (z.B. 5.4.0)
- Aktuelle Entwicklungen des Trunk werden in den Branch gemerged, sofern es sich nicht um komplette Neuentwicklungen handelt
- Merge wird getestet
- Nach dem erfolgreichen Test wird der Patchlevel wird erhöht (5.4.1)
- Release wird ersetzt

Um das ganze zu automatisieren, habe ich mir folgendes überlegt:
- Für jedes Release wird ein Branch mit Major-Release+Service-Pack erstellt (z.B. 5.4)
- Die stable-Revision wird mit 5.4_stable getagged
- Die zu testenden Änderungen werden gemerged
- Sobald die Tests erfolgreich waren, wird die entsprechende Revision nach dem Merge mit 5.4_stable getagged
- Gebaut wird immer der 5.4_stable Tag, es sei denn, ich gebe irgendwie mit, dass ich eine Beta brauche

Ist das eine sinnvolle Strategie? Und kann ich ALLE stable-Tags (*_stable) auslesen und immer den mit der höchsten Nummer bauen lassen?

rudygotya · 09.01.2012, 22:03

Hi,

im Prinzip (mit Ausnahme der Code-Verstümmelung) klingt das wie die Vorgehensweise bei uns im Team.

Im svn-Rootdir findest du ein hooks-Verzeichnis. Dort das post-commit.tmpl dementsprechend erweitern, ein paar Beispiele findest du hier:

http://stackoverflow.com/questions/4...-been-commited

Wenn das auf einem linux system läuft, kannst du den Verzeichnisnamen per regex bspw. auf "_stable" testen, a la

Code:

case $DIR in   
*_stable*) echo "stable version";   
*) echo "non stable version"

Wenns ein *nix system ist, würd ich (aber das ist meine persönliche Meinung) auf make umsteigen, gefühlt ist das um einiges schneller beim Projekte bauen.

Ansonsten wird bei uns auch Hudson verwendet, aber davon hab ich (noch) keine Ahnung.

Viele Grüße

Basti

dreamcatcher · 11.01.2012, 17:09

Kennt jemand von euch erfahrenen Usern ein gutes, professionelles Tutorial um sich in die SVN Geschichte einzulesen?

Wichtig ist, dass es mind. eine gute Basis ist und die Informationen daraus alle korrekt sind.
(Vgl. PHP Anfängertutorials, wo manchmal Schwachsinn geraten wird)

nikosch · 11.01.2012, 22:46

Ich würde Dir gleich zu Mercurial oder git raten.

http://hgbook.red-bean.com/read/

http://book.git-scm.com/index.html
http://de.whygitisbetterthanx.com/

Btw. Dein erster Anlaufpunkt sollte immer der Referenzteil der Wikipedia sein.

http://svnbook.red-bean.com/

notyyy · 12.01.2012, 09:55

wir nutzen im team mercurial, hat einfach den grund, dass die gui recht einfach ist und so unerfahrende entwickler schneller damit klar kommen. privat nutze ich git.

nikosch · 12.01.2012, 22:05

Du meinst dann vermutlich Tortoise Hg, oder? Für GIT gibts IMHO auch was von Tortoise. Und für SVN auch.

notyyy · 15.01.2012, 01:58

tortoisehg (für mercurial) ist brauchbar (besonders die alte version > 2), für git leider völlig unbenutzbar. die mir bekannten git gui's sind völlig unbrauchbar. gittower soll gut sein, existiert jedoch nur für den mac uns ist relativ teuer.

insbesondere wenn ihr relativ neu im umgang mit der materie seit, oder ein team habt, welches bis dato wenig erfahrung damit gemacht hat, würde ich euch mercurial wirklich empfehlen. ist sehr effektiv, intuitiv und nach git das mächtigste vcs welches ich kenne/nutze,

Themen-Optionen
Druckbare Version zeigen Jemanden per E-Mail auf dieses Thema hinweisen
Thema bewerten
Thema bewerten:

Ähnliche Themen
Thema	Autor	Forum	Antworten	Letzter Beitrag
jquery mobile theme zuweisung im release candidate	drsoong	JavaScript, Ajax und mehr	0	02.10.2011 21:45
Release 1.11 des Adventure PHP Framework (APF) veröffentlicht	dr.e.	Beitragsarchiv	14	11.02.2010 19:32
Release 1.10 des Adventure PHP Framework (APF) veröffentlicht	dr.e.	Beitragsarchiv	0	04.09.2009 16:26
Release 1.10-RC1 des Adventure PHP Framework (APF) veröffentlicht	dr.e.	Beitragsarchiv	5	19.07.2009 21:03
Release 1.9 (stable) des Adventure PHP Framework verfügbar!	dr.e.	Software-Design	2	29.04.2009 08:13
Release 1.9 (RC1) des Adventure PHP Framework verfügbar!	dr.e.	Beitragsarchiv	1	25.03.2009 00:16
Release 1.8 (stable) des Adventure PHP Framework verfügbar!	dr.e.	Software-Design	9	15.01.2009 22:12
Release 1.8 (RC1) des Adventure PHP Framework verfügbar!	dr.e.	Beitragsarchiv	4	11.12.2008 09:44
Release 1.7 (final) des Adventure PHP Framework verfügbar	dr.e.	Beitragsarchiv	0	08.11.2008 17:54
Release 1.7-RC2 des APF verfügbar!	dr.e.	Beitragsarchiv	2	15.09.2008 10:02
Release 1.6 final des Adventure PHP Framework verfügbar!	dr.e.	PHP-Fortgeschrittene	0	13.06.2008 22:55
Suche \| Content Management System		Beitragsarchiv	10	18.05.2005 09:59
[Erledigt] content management system gesucht		Off-Topic Diskussionen	2	12.07.2004 19:09

09.01.2012, 17:22
Andreas Erfahrener Benutzer Registriert seit: 22.04.2005 Beiträge: 391	Release Management Hallo zusammen, ich fange gerade damit an, mich mit Release Management zu beschäftigen. Jetzt bin ich auf der Suche nach einer geeigneten Strategie, um den vorhandenen Ablauf zu optimieren. Erstmal die Voraussetzungen: - Zur Code-Versionierung wird SVN verwendet - Zum Deployment soll ANT verwendet werden (der alte Ablauf basiert darauf) - Vor dem Deployment wird alles mit einem Encoder "verschlüsselt" - Die Versionsnummer ist immer ein Major-Release + Service-Pack + Patchlevel (also beispielsweise 5.4.9) - Die Versionsnummer, Service-Pack und Patchlevel sind immer vergeben (5.4.0, 5.4.1, etc.) - Es existiert immer eine aktuell freigegebene Version (Stable) und hin und wieder soll eine BETA erstellt werden, damit sie getestet werden kann Aktuell ist der Ablauf grob so: - Für jedes Major-Release wird ein Branch erstellt (z.B. 5.4.0) - Aktuelle Entwicklungen des Trunk werden in den Branch gemerged, sofern es sich nicht um komplette Neuentwicklungen handelt - Merge wird getestet - Nach dem erfolgreichen Test wird der Patchlevel wird erhöht (5.4.1) - Release wird ersetzt Um das ganze zu automatisieren, habe ich mir folgendes überlegt: - Für jedes Release wird ein Branch mit Major-Release+Service-Pack erstellt (z.B. 5.4) - Die stable-Revision wird mit 5.4_stable getagged - Die zu testenden Änderungen werden gemerged - Sobald die Tests erfolgreich waren, wird die entsprechende Revision nach dem Merge mit 5.4_stable getagged - Gebaut wird immer der 5.4_stable Tag, es sei denn, ich gebe irgendwie mit, dass ich eine Beta brauche Ist das eine sinnvolle Strategie? Und kann ich ALLE stable-Tags (_stable) auslesen und immer den mit der höchsten Nummer bauen lassen? Geändert von Andreas (09.01.2012 um 17:25 Uhr).*


Mister Ad PHP Code Flüsterer Registriert seit: 21.08.2005 Beiträge: 4682 PHP-Kenntnisse: Fortgeschritten

09.01.2012, 22:03
rudygotya Erfahrener Benutzer Registriert seit: 28.05.2008 Beiträge: 2.094 PHP-Kenntnisse: Fortgeschritten	Hi, im Prinzip (mit Ausnahme der Code-Verstümmelung) klingt das wie die Vorgehensweise bei uns im Team. Im svn-Rootdir findest du ein hooks-Verzeichnis. Dort das post-commit.tmpl dementsprechend erweitern, ein paar Beispiele findest du hier: http://stackoverflow.com/questions/4...-been-commited Wenn das auf einem linux system läuft, kannst du den Verzeichnisnamen per regex bspw. auf "_stable" testen, a la Code: case $DIR in _stable) echo "stable version"; ) echo "non stable version" Wenns ein nix system ist, würd ich (aber das ist meine persönliche Meinung) auf make umsteigen, gefühlt ist das um einiges schneller beim Projekte bauen. Ansonsten wird bei uns auch Hudson verwendet, aber davon hab ich (noch) keine Ahnung. Viele Grüße Basti __________________ ++++ Wieder einer ins Netz gegangen: Phishers Fritz zufrieden ++++ Blog

11.01.2012, 17:09
dreamcatcher Erfahrener Benutzer Registriert seit: 28.12.2010 Beiträge: 603 PHP-Kenntnisse: Anfänger	Kennt jemand von euch erfahrenen Usern ein gutes, professionelles Tutorial um sich in die SVN Geschichte einzulesen? Wichtig ist, dass es mind. eine gute Basis ist und die Informationen daraus alle korrekt sind. (Vgl. PHP Anfängertutorials, wo manchmal Schwachsinn geraten wird)

11.01.2012, 22:46
nikosch moderatives Dielektrikum Registriert seit: 21.05.2008 Beiträge: 35.994 PHP-Kenntnisse: Fortgeschritten	Ich würde Dir gleich zu Mercurial oder git raten. http://hgbook.red-bean.com/read/ http://book.git-scm.com/index.html http://de.whygitisbetterthanx.com/ Btw. Dein erster Anlaufpunkt sollte immer der Referenzteil der Wikipedia sein. http://svnbook.red-bean.com/ __________________ -- One pixel is still too big. Please make it smaller. ASAP. Initiative Mittelstand. Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers. --

12.01.2012, 09:55
notyyy Erfahrener Benutzer Registriert seit: 12.05.2005 Beiträge: 1.038 PHP-Kenntnisse: Fortgeschritten	wir nutzen im team mercurial, hat einfach den grund, dass die gui recht einfach ist und so unerfahrende entwickler schneller damit klar kommen. privat nutze ich git.

12.01.2012, 22:05
nikosch moderatives Dielektrikum Registriert seit: 21.05.2008 Beiträge: 35.994 PHP-Kenntnisse: Fortgeschritten	Du meinst dann vermutlich Tortoise Hg, oder? Für GIT gibts IMHO auch was von Tortoise. Und für SVN auch. __________________ -- One pixel is still too big. Please make it smaller. ASAP. Initiative Mittelstand. Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers. --

15.01.2012, 01:58
notyyy Erfahrener Benutzer Registriert seit: 12.05.2005 Beiträge: 1.038 PHP-Kenntnisse: Fortgeschritten	tortoisehg (für mercurial) ist brauchbar (besonders die alte version > 2), für git leider völlig unbenutzbar. die mir bekannten git gui's sind völlig unbrauchbar. gittower soll gut sein, existiert jedoch nur für den mac uns ist relativ teuer. insbesondere wenn ihr relativ neu im umgang mit der materie seit, oder ein team habt, welches bis dato wenig erfahrung damit gemacht hat, würde ich euch mercurial wirklich empfehlen. ist sehr effektiv, intuitiv und nach git das mächtigste vcs welches ich kenne/nutze,