SVS Code Release Versioning
Overview
- SVS Bitbucket repo
- JIRA Project
- Web upgrade
- 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
- Tags - Labeled in the with the following versioning standard numeric value X.Y.X , e.g 1.0.0
X.Y.X refers to <MAJOR>.<MINOR>.<PATCH>
- 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
- Y - Recent improvements in the current Module. This should contain release from client request and Team Major Maintenance request.
- X - Small patches release such as bug fixes on a production.
- Team must still decide if it wants prefix be for the versioning. e.g svs-1.0.0 or svs-musika-1.0.0
- 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.
- Tags - Labeled in the with the following versioning standard numeric value X.Y.X , e.g 1.0.0
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.