V3 Release Procedure Steps to promoting a V3 Build
1. Create a branch from V3 trunk workspace
- The branch is named: 3.0-b## where ## is the build number.
svn copy https://svn.java.net/svn/glassfish-svn/trunk/v3 https://svn.java.net/svn/glassfish-svn/branches/3.0-b##
2. Checkout the branch workspace
svn checkout https://svn.java.net/svn/glassfish-svn/branches/3.0-b##
3. cd to the branch workspace
4. Checkout Sun-GlassFish workspace (Note the Sun-GlassFish workspace is in an internal cvs repository)
svn checkout http://mercurial.sfbay.sun.com/svn/glassfish/trunk/v3-internal sun-glassfish
5. Execute mvn release plugin to resolve any SNAPSHOT dependencies and update all the pom.xml files with the release version.
- Command to execute mvn release plugin
mvn -Dmaven.repo.local=$PWD/repository -B -Dtag=3.0-b## -Prelease-phase-all release:prepare -DlocalRepoDirectory=$PWD/repository -DreleaseVersion=3.0-b$BUILD_NUMBER -DdevelopmentVersion=3.1-DONT_CARE -DpreparationGoals="A_NON_EXISTENT_GOAL"
The pom.xml files will get updated with the release version. However, we do not want to check-in the changes and tag the workspace. We want to build and test the workspace before doing that. So to make sure that maven release plugin do not check-in the changes and tag the workspace, we will force maven execution to fail by providing a non-existing goal for the parameter, "preparationGoal". The output of maven execution is saved to a file and egrep command is used to search for the string, "Invalid task 'A_NON_EXISTENT_GOAL'".
e.g.:
mvn ... release:prepare ... 2>&1 | tee /tmp/mvn_rel.output
egrep "Invalid task 'A_NON_EXISTENT_GOAL'" /tmp/mvn_rel.output
if [ $? -ne 0 ]; then
echo "Unable to perform release using maven release plugin. Please see /tmp/mvn_rel.output."
exit 1;
fi
Note that profile, "release-phase-all" contains all the modules in the v3 workspace including the Sun-GlassFish modules.
6. Build maven glassfish extension and plugin.
mvn -Dmaven.repo.local=$PWD/repository -U -Prelease-phase1 install
It's imperative that this step comes before compiling GFv3 workspace since maven glassfish extension and plugin are used in building GFv3.
See: build instructions
7. Build GFv3 workspace, packager, distribution-ips, installer. In addition, build Sun-GlassFish branded modules (glassfish, packager, distributions and installer). One maven invocation will build everything!
mvn -Dmaven.repo.local=$PWD/repository -Drepo.url=<ips-repo-url> -Dpython=$PYTHON_HOME/bin/python -Dbuild.id=<build_number> -P release-phase2,ips clean install -X -e
This step requires an IPS repo server up and running. This step also requires that you have either python or Update Center toolkit on the system. Download Update Center toolkit here. Update Center toolkit is packaged with python. GFv3 packages are deployed to the IPS repo in this step.
Note that the profile, "release-phase2" contains all the modules except for the build module.
After successful completion of this step, you'll find the installers in installer/target and glassfish/installer/target
8. Execute QL and SmokeTests
1. cvs -d:pserver:cvsguest@jescvs.sfbay.sun.com:/m/jws co appserver-sqe/bootstrap.xml \\
2. cd appserver-sqeUWC_TOKEN_DBBS
3. ant -f bootstrap.xml co-smoke-testUWC_TOKEN_DBBS
4. ant start-domainUWC_TOKEN_DBBS
5. ant pe-v3smoke-testUWC_TOKEN_DBBS
6. ant stop-domain \\
9. Commit the changes to the branch.
10. Promote the binaries so QE can start their testing.
11. If all goes well, then tag the build and publish the artifacts to the remote maven repository.
- Command to create a tag from a branch:
svn move https://svn.java.net/svn/glassfish-svn/branches/3.0-b##
https://svn.java.net/svn/glassfish-svn/tags/3.0-b##
- The Sun-GlassFish workspace will also be tagged.
- Commands to publish artifacts to maven repository:
v3 artifacts
mvn -Dmaven.repo.local=local_maven_repo -Prelease-phase1 -s settings.xml deploy
mvn -Dmaven.repo.local=local_maven_repo -s settings.xml deploy
embedded artifacts (build and publish)
1. cd embedded/packager/all
2. mvn -Dmaven.repo.local=local_maven_repo -s settings.xml deploy
Note: For weekly promoted build, the branch can be removed. For release candidate builds, we want to keep the branch and follow similar steps for V3Prelude release (see below). V3 Final Release Process
- Decide which weekly promoted build from trunk to create the final v3 branch. Name the branch 3.0-FCS.
- Create the branch from v3 trunk:
mvn --batch-mode release:branch -branchName=branch-name
Note that the branch will contain 3.0-SNAPSHOT and the trunk will now have 3.1-SNAPSHOT in the pom.xml files
- Create a branch of Sun-GlassFish workspace. Name the branch: v3_fcs_release
- Continue weekly 3.0-b##a-z promotion from the branch
- Update Hudson jobs to build from 3.0-FCS branch: dev, continuous, promoted (weekly), nightly
- Create Hudson jobs for 3.1-SNAPSHOT (trunk): dev, continuous
- Continue weekly 3.0-b##a-z promotion from the branch.
- Final promotion from 3.0-SNAPSHOT branch will have the version 3.0.
V3 Preview Release Process
- Promote build 3.0-b47 from trunk
- Branch 3.0-Preview from 3.0-b47 with the version: 3.0-Preview-SNAPSHOT
- 3.0-PREVIEW branch will have pom.xml files updated with 3.0-Preview-SNAPSHOT
- Create following Hudson jobs: dev, continuous, promoted, nightly for 3.0-Preview branch
- Create UC repos for 3.0-Preview
- Weekly promoted build will be from 3.0-Preview-SNAPSHOT, starting with the version, 3.0-Preview-b47a. Following the same convention as the past, future promotion will be 3.0-Preview-b47b, ...b47c, b47d and so on.
- Hold-off on trunk promotion but Hudson jobs for dev, continuous and nightly will still be available.
- Final promotion from 3.0-Preview-SNAPSHOT branch will have the version 3.0-Preview.
V3 Prelude Release Process Cannot resolve external resource into attachment.
The above pictorial view represents proposed RE promotion process. (Proposed by Sahoo) Here are the steps involved in promotion (of every build).
- RE have existing v3-prelude-branch where the version is a 3.0-Prelude-SNAPSHOT
- RE creates another branch from v3-prelude-branch (call this as child branch)
- RE makes changes to versions of pom headers to 3.0-PRELUDE-b28a-f? where a-f? stands for b28a, b28b,...b28f for each promotion
- RE builds the child branch, after versions changes to the right version b28a-f?
- RE runs all the tests as per the earlier promotion process.
- RE publishes this branches artifacts at the java.net maven repo.
- RE commits the changes (made to the child branch) to child branch.
- RE does an svn move of child branch to the tags.
- RE promotes the tagged build as above, following the today's normal promotion steps.
Notes:
- Any fixes that are targeted for the prelude (in the branch) will be checked into the prelude branch whose version is @ 3.0-Prelude-SNAPSHOT
# The 3.0-Prelude-SNAPSHOT branch is always open for checkins (of course with proper approval) and does not interfere with RE promotion
# RE repeats step (2) as above for each promotion.
# RE version changes are frozen into tag. So, No check-ins into that workspace. It is tagged only to reproduce the problem in a promoted build.
# The main 3.0-Prelude-SNAPSHOT branch will be turned into 3.0-Prelude-URXX-SNAPSHOT., when we finally decided to cut a prelude release. (XX=the update release number in those times)
- When we do the final release of v3 Prelude, the version should be changed to 3.0-Prelude. External components should not depend on 3.0-Prelude-b28c while specifying dependency in their pom.xml. They should depend on 3.0-Prelude."
Cannot resolve external resource into attachment.
|
