SVS Code Release Versioning


  1. SVS Bitbucket repo
  2. JIRA Project
  3. Web upgrade
  4. Journey upgrade 


SVS Bitbucket Repository Management

  • We manage SVS DSL source code in Bitbucket with Git
  • Master - Tags - Here resides the currently deployed production code
      1. Tags - Labeled in the with the following versioning standard numeric value X.Y.X , e.g 1.0.0
        1. X.Y.X refers to <MAJOR>.<MINOR>.<PATCH>
        2. Increment in X should happen only when there is to a Major release , such newly release SVS 2.0.0 Module containing the Stock Receiving Functionality
        3. Y - Recent improvements in the current Module. This should contain release from client request and Team Major Maintenance request.
        4. X - Small patches release such as bug fixes on a production.
        5. Team must still decide if it wants prefix be for the versioning. e.g svs-1.0.0 or svs-musika-1.0.0
      2. Developer - Should be branched from master and used as a current branch where all developer branches are created and merged to while waiting deployment deployment to production. 

JIRA Project Management

  • All current development work must be documented through JIRA tickets .
  • All tickets must reflect their target project code
  • Development work that involves a commenting to the Bitbucket must be committed / created / reflected on the Ticket
  • Each Major release version must be have been reflected in a form on an epic on JIRA

Managing Release upgrade on the DSL

  • All web app release must be document in a form of a JIRA Ticket
    • List of all SQL Migrations Scrips where applicable
    • Indication of any possible effect to any middleware
    • The JIRA ticket must be linked as related issue / subtask / Check Box
  • An increment to the release version must done and be reflected from the Web App
  • Each Major release the whole team must be aware.
  • If the release involves Journey , the source code must be pulled and committed to the Bitbucket repository.