-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hallo Team, ich werde die ruhigen Tage dafür nutzen das xres in ein GIT Repository umzuziehen. Wichtig: Alle Änderungen die im SVN nicht bis zum 02.01.2014 eingechecked sind, werden nicht mit in das GIT überführt. Bitte löscht eure lokalen SVN Arbeitskopien noch nicht. Falls ihr Unittest's oder anderen Sachen nur lokal habt müssen wir diese im Nachgang in das GIT mit übernehmen. Hintergrund: Ich möchte das Deployment etwas umstrukturieren um hier mehr Möglichkeiten zu haben und das ganze noch Stabiler zu gestalten. Zusätzlich haben wir auch zunehmende Probleme mit der SVN Historie und dem Branch Model in SVN. Außerdem möchte ich, mit der Abkapselung der einzelnen Entwicklungen in verschiedenen branches, mit Hilfe von automatisierten Tests die Code Qualität steigern. Was wird geändert: Der gesamte xres SourceCode wandert in das Stash (unser GIT Server). Es wird nur noch ein Repository für alles geben und nicht mehr aufgeteilt. Der Build Server reagiert auf jeden Commit und führt Tests + diverse Analysen aus. Ein deployment liefert ein vor packetiertes xres aus und wird nicht mehr wie aktuell jedes mal ein neues xres Paket schnüren. Änderungen am Worflow: Das alltägliche Arbeiten am xres Ändert sich natürlich auch etwas. Was aktuell unter dem Namen "trunk" bekannt ist, wird umbenannt in den branch "develop". Dieser branch spiegelt immer den aktuellsten Entwicklungsstand wieder. Der branch "master" ist der aktuell Stand der Software wie er Produktiv ausgeliefert ist. Schreibzugriffe auf den master werden unterbunden. Der Codestand auf dem "master" wird nur vom Deployment Team über merges abgeglichen. Jedes Feature das Entwickelt wird und jeder Bugfix muss in einem eigenen branch ausgelagert werden. Ist die Entwicklung eines Feature/bugfix abgeschlossen, muss dieser über einen Pull Request (grafisch per Stash) in den develop branch gemerged werden. Alternative kann das ganze auch per Kommandozeile gemerged werden. Sobald der Zeitpunkt x erreicht ist und eine neue Version des xres erzeugt werden soll, wird ein ein Release Candidat branch erstellt. In diesem RC Branch fließen ausschließlich Bugfixes ein! Ist eine Stable Version entstanden, wird der RC Branch in den master gemerged und getaggt. Von nun an bleibt der RC Branch nur noch bestehen um Support für dieses Version gewährleisten zu können. Hotfixe werden ebenfalls über separate branches gehandelt. Pro Hotfix wird ausgehend von der getaggten Version ein branch erstellt. Für den Hotfix branch gibt es einen Build Job. Ist die Arbeit am Hotfix abgeschlossen und alle Build erfolgreich, wird der Hotfix Branch in den RC Branch gemerged, ein neuer Tag erzeugt und der Hotfix branch gelöscht. Genauere Beschreibung der Workflows mit Beispielen und ein paar Bildern in einem späteren Workshop zu dem Thema. Regeln: Jeder Commit im GIT muss einen JIRA-KEY enthalten! Die Namen der branches sind Festgelegt. Weiterentwicklungen im xres werden mit "feature/JIRA-KEY" angelegt. Bugfixes für RC's etc. mit "bugfix/JIRA-KEY". Hotfixe branches werden mit "hotfix/JIRA-KEY" angelegt. RC branches werden vom Deployment Team angelegt. Tags werden ebenfalls vom Deployment Team angelegt. Pull Requests können von jedem Entwickler erzeugt werden. Wann und wie wird das ganze Umgestellt: Ich werde am 02.01.2014 den Umzug durchführen. Dafür werden ich aus dem SVN mir den aktuellen CodeStand ziehen. Der Tag 2.2.1 wird im GIT der master branch. Der SVN Branch 2.2.2 wird im GIT der develop branch. Das SVN wird vorerst parallel weiter laufen um gegeben falls noch mal nachschauen zu können oder vergessene Änderung zu übernehmen. Kurze Starthilfe: Eine Übersicht der wichtigsten git Commands im Vergleich zu SVN: Aktion SVN GIT Server-Stand herunterladen svn checkout http://domain.com/repo git clone http://domain.comrepo Änderungen hochladen svn commit file1 -m "Task123" git commit file1 -m "Task123" git push Änderungen vom Server holen svn update git pull Geänderter Dateien svn status git status Änderungsprotokoll svn log file1 git log file1 Ungesicherte Änderungen svn diff file1 git diff file1 Weitere wichtige GIT Commands: Command Beschreibung git branch listet alle branches auf git branch foobar erzeugt einen lokalen branch Namens foobar git checkout foobar wechselt lokal auf den branch foobar git push schiebt alle Änderung auf den RemoteServer git stash blubb speichert alle lokalen änderung zwischen in einem Stash Namens "blubb" und geht wieder auf den HEAD zurück git stash list zeigt alle zwischengespeicherten Änderungen git apply blubb Holt Änderungen aus dem Stash "blubb" und merged sie in den lokale Kopie Das waren die wesentlichen Punkte in Kurzform. Für den tieferen Einstieg finde ich dieses Tutorial sehr gelungen: http://rogerdudler.github.io/git-guide/index.de.html http://try.github.io/levels/1/challenges/1 Natürlich stehen für Fragen und Anregungen ich und Phillip zur Verfügung. - -- Mit freundlichen Grüßen Krisztian Springer - - Entwicklung - ___________________________________________________________________________ TraSo GmbH G.-Schumann-Str. 294 04159 Leipzig E-Mail: k.springer@traso.de Geschäftsführer: Haiko Gerdes Handelsregister: Amtsgericht Leipzig, HRB 21850 ___________________________________________________________________________ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBAgAGBQJSwYl9AAoJELGP1cO010ZnLFsIAJPexnt8ZzzvLlGrEQZD1Mp3 bm+mLvW0BPXGlY9JWLUsBTyezK9kXugCZb+jep5OmnpSD57J8vaWZKE2DZYVFEjV Z0iws1rOkJP+gvx89aO/cUJzV4kyC36X8p+Vp6DB4UvzztnljZ9d49m6yJ1zHOa+ r94X62hEcvpi5TUvxcTmGxyjHRubqwDfaBhAzGtyah1skc9LowTS0IfQJ0cu28wN NIroVihAvUYj85vEHpwl6VCAZYhmPGmNEsEko7i92VAI3j6eXMaodP3VrwUBgH2j j5LO5sabjoHRNYI5ecPL4B0ueAHGBAt2A7d8GB+C+Ke2YvHaAkaPUWgz7PVymyY= =w4n3 -----END PGP SIGNATURE-----