More or less you have a working best practice for version control within your team. There might be a problem here and there but you can always find a way out. Same applies in our team. With years of fooling around we came to a position where everybody in our team had to release stories ourselves. We did it okay with a well written release check list for most part of the year until we felt it was enough. Our project is built with Maven and subversion is our repository. It was a natural choice to use Maven Release Plugin that does the job well.
After configuring your pom following usage guideline you can release from your release branch easily.
mvn --batch-mode release:clean release:prepare release:performIf you need system property for your build, you could run into troubles as I did. Note that the release plugin checks out code into a temporary work folder and invokes Maven deploy goal from there. Your system property is invisible during the packaging process unless you pass it as an argument to Maven Release Plugin.
-Dtag=REL_${BUILD_ID} -Darguments=-Dtag=REL_${BUILD_ID}
Everybody can start a Jenkins release job without much training. That works great for us.
Moving onto the real treat. We are adopting GIT for future development, past experience with Maven Release Plugin drove me to look for alternatives and luckily I found JGit-Flow
After adding
<plugin>
<groupId>external.atlassian.jgitflow</groupId>
<artifactId>jgitflow-maven-plugin</artifactId>
<version>1.0-m4</version>
<configuration>
<squash>true</squash>
</configuration>
</plugin>
<groupId>external.atlassian.jgitflow</groupId>
<artifactId>jgitflow-maven-plugin</artifactId>
<version>1.0-m4</version>
<configuration>
<squash>true</squash>
</configuration>
</plugin>
into my pom.xml, all I need to do is issue command
mvn -U clean jgitflow:release-start jgitflow:release-finish -Dbuild.id=$BUILD_ID