Jämförda versioner

Nyckel

  • Dessa rader lades till.
  • Denna rad togs bort.
  • Formateringen ändrades.

Innehållsförteckning

Processen

Processen övergripande

Tankar kring långlivade support-brancher och Git flow

http://www.syntevo.com/smartgit/documentation/6/show?page=git-flow#flow.support

https://groups.google.com/forum/#!topic/gitflow-users/I9sErOSzYzE

 

Git flow exempel hämtade från:

https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow

http://nvie.com/posts/a-successful-git-branching-model/

http://danielkummer.github.io/git-flow-cheatsheet/

 

Övergripande om processen

  • Branchen master innehåller endast taggade produktions-releaser.
  • Branchen develop är där ny funktionalitet införs (integration branch)

 

  • Varje feature utvecklas i en egen branch med develop som ursprunglig branch.
  • När en feature är klar mergas den tillbaka in i develop.
  • När branchen develop innehåller tillräckligt med features för en release, skapas en release-branch, och samtidigt startas utvecklingen för nästa release.
  • release-branch görs endast bug-fixar och dokumentationsuppdateringar.
  • När den release-branch är redo att skeppas, mergas den till master och taggas med version, efter det mergas ändringar till develop.
  • En support branch är en långlivad 'master-branch' för en viss version.

Namnkonventioner

develop-branch: develop

release-branch: release/v<version>, tex release/v2.3.0

feature-branch: feature/<JIRA nr>, tex feature/SKLTP-123

hotfix-branch: hotfix/<JIRA nr>, tex hotfix/SKLTP-123

support-branch: support/<version>, tex support/v.2.3.0

tag: <version>, tex v2.3.0

kommentar: ex SKLTP-123: Loggning av payload skall vara konfigurerbar av/på

Git flow processen och exempel med git-flow installerat

Nedan exempel med verktyget git-flow och motsvarande git kommandon om man inte har tillgång till verktyget

https://github.com/nvie/gitflow

Installera verktyget git-flow

Om du som utvecklare väljer att inte installera git-flow enligt ovan så kan man använda git kommandon för att uppnå samma resultat. Dessa beskrivs separat längs ner på sidan.

Kodblock
Brew on mac
$ brew install git-flow
 
Linux
$ apt-get install git-flow
 
Windows (Cygwin, wget, util-linux)
$ wget -q -O - --no-check-certificate https://github.com/nvie/gitflow/raw/develop/contrib/gitflow-installer.sh | bash

Införa ny funktionalitet (feature branch)

Starta en feature branch

Kodblock
─$ git-flow feature start SKLTP-123
Switched to a new branch 'feature/SKLTP-123'
Summary of actions:
- A new branch 'feature/SKLTP-123' was created, based on 'develop'
- You are now on branch 'feature/SKLTP-123'
Now, start committing on your feature. When done, use:
     git flow feature finish SKLTP-123

Dela en feature branch

Kodblock
╰─$ git-flow feature publish SKLTP-123
Total 0 (delta 0), reused 0 (delta 0)
To git@github.com:skltp-aggregerandetjanster/riv.clinicalprocess.healthcond.basic.GetAggregatedObservation.git
 * [new branch]      feature/SKLTP-123 -> feature/SKLTP-123
Already on 'feature/SKLTP-123'
Your branch is up-to-date with 'origin/feature/SKLTP-123'.
Summary of actions:
- A new remote branch 'feature/SKLTP-123' was created
- The local branch 'feature/SKLTP-123' was configured to track the remote branch
- You are now on branch 'feature/SKLTP-123'

Färdigställ en feature branch

Kodblock
╰─$ git-flow feature finish SKLTP-123
Switched to branch 'develop'
Already up-to-date.
Deleted branch feature/SKLTP-123 (was 039205e).
Summary of actions:
- The feature branch 'feature/SKLTP-123' was merged into 'develop'
- Feature branch 'feature/SKLTP-123' has been removed
- You are now on branch 'develop'

Göra en release (release branch)

Starta en release branch

Kodblock
─$ git-flow release start v1.0.0
Switched to a new branch 'release/v1.0.0'
Summary of actions:
- A new branch 'release/v1.0.0' was created, based on 'develop'
- You are now on branch 'release/v1.0.0'
Follow-up actions:
- Bump the version number now!
- Start committing last-minute fixes in preparing your release
- When done, run:
     git flow release finish 'v1.0.0'

Stega upp version i källkoden (pom.xml)

Kodblock
Från maven-release-plugin 2.1.0 finns möjlighet att sätta konfiguration som underlättar releaser till Git. Rekommenderade versioner på maven-release-plugin är 2.3.2 eller 2.5.1 (ej 2.4).


tagNameFormat, överlagra default namnsättning på version för att tex sätta v.1.0.0
pushChanges, 
localCheckout, 
autoVersionSubmodules, 
Kodblock
languagexml
titlepom.xml
<build>
	<pluginManagement>
		<plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-release-plugin</artifactId>
                <version>2.4.1</version>
                <configuration>
					<autoVersionSubmodules>true</autoVersionSubmodules>
					<tagNameFormat>v@{project.version}</tagNameFormat>
                    <pushChanges>false</pushChanges>
					<localCheckout>true</localCheckout>
                </configuration>
            </plugin>
		</plugins>
	</pluginManagement>
</build>
Kodblock
╰─$ mvn release:prepare
---
---
---
╰─$ mvn release:perform

Verifiera att versionen stegats upp och taggats korrekt i git

Kodblock
╰─$ git stauts
On branch release/v1.0.0
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)
	modified:   pom.xml
Kodblock
╰─$ git tag
v1.0.0-RC1

Dela ut release branchen så att andra utvecklare kan se den

Kodblock
╰─$ git-flow release publish v1.0.0

Färdiställ release branch

Kodblock
╰─$ git-flow release finish v.1.0.0
--
--
 
╰─$ git push --tags

Göra en rättning på en publicerad release (hotfix branch)

Påbörja en hotfix branch

Kodblock
╰─$ git-flow hotfix start v.2.3.1

Färdigställ en hotfix branch

Kodblock
╰─$ git-flow hotfix finish v.2.3.1

Skapa en långlivad support branch för att kunna rättningar på äldre versioner (support branch)

Påbörja en långlivad support branch

Kodblock
╰─$ git-flow support start v.2.3.0

 

Git flow processen och exempel utan git-flow installerat

Hämta ut develop branchen där utveckling sker

Kodblock
git clone ssh://user@host/path/to/repo.git
git checkout -b develop origin/develop

Införa ny funktionalitet (feature branch)

Starta en feature branch

Kodblock
git checkout -b feature/SKLTP-123 develop

Dela en feature branch

Kodblock
git push -u origin feature/SKLTP-123

Färdigställ en feature branch

Kodblock
git pull origin develop
git checkout develop
git merge --no-ff feature/SKLTP-123
git push
git branch -d feature/SKLTP-123

Göra en release

Merge develop till master

  1. Switch to master branch

    Kodblock
    $ git checkout master
  2. Merge develop to master

    Kodblock
    $ git merge develop

Gör release mha Maven release plugin

...

Innehållsförteckning

Info
Skarpa releaser och RC bör skapas med hjälp ett release jobb i  Ineras Jenkins server men kan i undantagsfall skapas enligt instruktion nedan. Se även Skapa release med Jenkins.


Här beskrivs hur vi genomför en release mha Git, Maven och Ineras Nexus( samt tidigare Sonatype). För allmän information om releasehantering se Release management.

För mer information om hur Git används se /wiki/spaces/SKLTP/pages/3187835204.

Kontrollera se.skltp komponenter i Ineras Nexus

1. Logga in på Ineras Nexus och verifiera att det inte redan finns komponent byggd med samma versionnummer. Finns redan en komponent kommer deployjobbet att misslyckas.

Merge develop till master

2. Kontrollera att det inte finns några utestående ändringar lokalt eller centralt för develop.

Kodblock
$ git pull
$ git status


3. Byt till master. Kolla att inga utestående ändringar finns!

Kodblock
$ git checkout master
$ git pull
$ git status


4. Merge develop till master

Kodblock
$ git merge develop -m "Merge from develop"

Gör release mha Maven release plugin

För att deploya krävs att projektet är uppsatt korrekt i pom och i maven settings, se Release management


5. Bygg och verifiera att du har en stabil och korrekt version.

Kodblock
$ mvn clean test

 

4. Gör en commit av master innan release påbörjas

Kodblock
$ git commit -a -m "Commit för release 2.2.10"

 

...


6. Gör eventuellt en dryRun för att se hur en release kommer

...

att påverka din kod. Detta görs framförallt när man hanterar nya artefakter/projekt och då för att verifiera att versionhanteringsparametrar är korrekt satta.

Kodblock
$ mvn release:clean release:prepare -DdryRun=true

Se speciellt på...

 

...


7. Utför första steget av releasen med prepare kommandot.

För mer information se  http://maven.apache.org/maven-release/maven-release-plugin/prepare-mojo.html

Kodblock
$ mvn release:clean release:prepare
$
$
$
$

 

...


8.  Gör steg 2 i releasen mha

...

perform kommandot

För mer information se  http://maven.apache.org/maven-release/maven-release-plugin/perform-mojo.html

Kodblock
$ mvn release:perform
$
$
$

Publicera din release på Sonatype staging

8. Gå till Sonatype staging repository och gör en release för att synka till Mavens centrala repo

    • Gå till https://oss.sonatype.org
    • Logga på Nexus UI
    • Gå till "Staging Repositories"
    • Välj korrekt "staging repositiory"
    • Välj din release
    • Klicka på "Close" knappen

Validera din release i verifieringsmiljö

9. Hämta din release från Sonatype Staging miljö till din verifieringsmiljö.

! Om något är fel i din release kan du ordna detta på din release-tag i git och därefter göra en omdeploy till Sonatype staging repository från tag-katalogen.

Gör release  från Sonatype staging till Sonatype central

10. Gå till Sonatype Hämta din release från Sonatype Staging milj

Förbered för nästa utvecklingscykel

...


Info
titleMöjliga problem vid körning av release pluginet
  • Man fastnar vid steget git push: detta kan lösas genom att skicka med användarnamn och lösenord "-Dusername=USERNAME -Dpassword=XXX"
  • Fel vid generering av javadoc: För att skippa javadoc kan man lägga till -Darguments="-Dmaven.javadoc.skip=true". Kör man deploy skip läggs "-Dmaven.javadoc.skip=true" i befintliga "-Darguments."


Förbered för nästa utvecklingscykel

10. Byt till develop

Kodblock
$ git checkout develop

...


11.

...

Merge develop från master

Kodblock
$ git merge master -m "Merge from master"

...


12. Bygg i Maven för att verifiera att du inte har några  problem i develop.

Kodblock
$ mvn clean install

14. Commit till develop

Kodblock
$ git commit -a -m "Påbörja arbete på version 2.2.11"

...


13. Push master och develop

...

  samt taggar till origin (eller använd SourceTree))

Kodblock
$ git push --tags origonorigin develop:develop master:master

Göra en rättning på en publicerad release (hotfix branch)

Påbörja en hotfix branch

Kodblock
git checkout -b hotfix/SKLTP-112 develop

Färdigställ en hotfix branch

...


Redeploy till Nexus

Om releasen av någon anledning inte laddas upp till Nexus så kan man köra om uppladdningen med

Kodblock
mvn deploy --no-ff hotfix/SKLTP-112
git push

git checkout develop
git merge --no-ff hotfix/SKLTP-112
git push

git branch -d hotfix/SKLTP-112
 
git tag -a 2.3.1 -m "2.3.1 release with hotfix SKLTP-122" master
git push --tags

Skapa en långlivad support branch för att kunna rättningar på äldre versioner (support branch)

Skapa en långlivad support branch

Kodblock
git checkout -b support/v2.3.0 master

 

...

plugin-updates -P skltp -f pom.xml

Man får antingen checka ut den tag som ska laddas upp eller så kan man ställa sig i checkoutkatalogen som relese:perform skapat i targetkatalogen.