SNOMED International Mapping Tool

Space shortcuts

Child pages
  • Versioning "develop" and "master"

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 8 Next »

Overview

Documentation on basic versioning strategy (as of March 2017)

Managing Versions

The develop branch of the git repository is where features are pushed and deployed to UAT for testing.  

NOTE: When doing this process, make sure that eclipse is closed!  This process can be run with a combination of cygwin and tortoise git.

The develop branch should always be one minor version ahead of master.  For example

  • master = 1.3.1
  • develop = 1.3.2-SNAPSHOT

When it comes time to deploy features to PROD, the master branch needs to be updated/synchronized before that happens.

The basic process is this:

  1. Pull latest changes for the repository.
  2. Ensure the project is set to the "develop" branch.

  3. Use "mvn versions:set" to change the versions of the develop branch to the next release version (e.g. 1.3.2)

    cd /path/to/OTF-Mapping-Service
mvn versions:set
... when prompted, type in the next version (e.g. 1.3.2)
cd parent/
mvn versions:set
... when prompted type in the next version (e.g. 1.3.2)
 
... Note: If you make a mistake, use mvn versions:revert.
  4. Commit the "develop" branch changes (but not need to push)
  5. Switch to the "master" branch
  6. Merge changes from "develop" to "master"  (resolve any conflicts, rebuild code completely, confirm that ui deploys as expected)
  7. Push the "master" branch (it now has the next release version) 
  8. Switch back to the "develop" branch.

  9. Use "mvn versions:set" to change the versions to the next develop version

    cd /path/to/OTF-Mapping-Service
mvn versions:set
... when prompted, type in the next version (e.g. 1.3.3-SNAPSHOT)
cd parent/
mvn versions:set
... when prompted type in the next version (e.g. 1.3.3-SNAPSHOT)
  10. Commit the "develop" branch and push this change
  11. Redeploy UAT to reflect the next dev version

NOTE: Confirm that pom-us.xml also gets versioned appropriately.  If not, updated manually.

NOTE: you may notice the complexity of running versions:set twice.  This is because of the split nature of the parent and aggregator modules.  It is recommended in the future that parent project be merged into the aggregator and removed.  Thant involves:

  1. Moving the dependencyManagement section from parent/pom.xml to pom.xml
  2. Moving the pluginManagement section from parent/pom.xml to pom.xml
  3. Removing "parent" from the modules list in pom.xml
  4. Updating pom.xml to remove the "<parent>" section at the top (it is now the parent)
  5. Also change pom.xml description to indicate that it is both parent and aggregator
    1. in particular, change the artifactId to be "...-parent" instead of "...-aggregator" (this is for the next part)
  6. update all other pom.xml files in submodules to change the relativePath to the parent module 
    1. from "../parent" to ".." 
    2. OR from "../../parent" to "../.."


Managing Hotfixes

Occasionally, only a select few commits from develop need to be deployed on production as a hotfix.  In these cases, the full merging from develop to master is inappropriate, and the following steps should be followed instead:

  • n/a

 

 

  • No labels