Notes on deployment policies

• Major version number will remain 0 until we make a "marketing" decision that we are calling Synapse production instead of under development. Minor version number will correspond to Sprint number.
• Code should never be deployed to any production system on Amazon directly from a development environment build.  All deployed artifacts should be produced by a successful Bamboo build and deployed to Artifactory by that build process.  Only deploy artifacts to AWS that have been obtained from Artifactory.
• Code from the tip of trunk or development should always have a maven version of 0.x-SNAPSHOT where x is the sprint (minor version) number.
• For weekly dev-team integration deployments, it's not necessary to create a new version.  We will simply deploy snapshots off trunk, and include the svn build number and date in the version label when deploying to Beanstalk.  Any deployments to customer-facing stacks need to be tagged in SVN and archived in Artifactory.

Creating an Initial Minor Release

For end of sprint x, the branching and tagging procedure is:

1. Send email to platform declaring a check-in freeze on trunk
2. Verify that most recent check-in results in a clean Bamboo build of trunk
3. Do a svn copy of trunk to branches/Synapse-0.x.  If we need to do work to create a patch release, it will go in this branch, and continue to be labeled 0.x-SNAPSHOT.
4. Do a svn copy of branches/Synapse-0.x to tags/Synapse-0.x.0
5. Check out tags/Synapse-0.x.0 and change the root pom.xml file to update application version from 0.x-SNAPSHOT to 0.x.0 and check that in.  Eclipse will give you a warning that you shouldn't be checking in to a tag.  Do it anyways, and then delete the code from your workspace so you never accidently modify the tagged version again.
6. Create a copy of the Bamboo build of trunk and reconfigure it to point it at tags/Synapse-0.x.0
7. Manually kick off a build, which should pass and create the 0.x.0 artifacts in Artifactory
8. Reconfigure the Bamboo build to point to branches/Synapse-0.x
9. Update trunk pom.xml to 0.[x+1]-SNAPSHOT and check it in.  This should generate a bamboo build of trunk that pushes 0.[x+1]-SNAPSHOT to Artifactory for the first time.  Verify that this in fact happens.
10. Send email to platform declaring trunk and branch open for check-ins.

Creating a Patch Release

A patch release is a build of Synapse deployed to a production system facing end users, including internal alpha testers.  All Patch releases should have the form 0.x.y, where 0.x.0 is the initial sprint deliverable, and subsequent patches that are customer facing increment the 3rd position of the version number.  The procedure to create patch y on branch x is:

1. Send email to platform declaring a check-in freeze on the branch
2. Verify that the most recent check-in on the branch resulted in a clean Bamboo build, and verify with the developer who created the patch that it is in fact checked in.
3. Do a svn copy of branches/Synapse-0.x to tags/Synapse-0.x.y
4. Check out tags/Synapse-0.x.y and change the root pom.xml file to update application version from 0.x-SNAPSHOT to 0.x.y and check that in.  Eclipse will give you a warning that you shouldn't be checking in to a tag.  Do it anyways, and then delete the code from your workspace so you never accidently modify the tagged version again.
5. Reconfigure the Bamboo build of the branch to point to tags/Synapse-0.x.y
6. Manually kick of a Bamboo build and verify that a clean build generates Synapse-0.x.y artifacts in Artifactory
7. Reconfigure the bamboo build to point back to branches/Synapse-0.x
8. Send email to platform declaring branch open for checkouts.