SyncNow Release LifeCycle

GENERAL

We are working with Azure DevOps and Agile to track our work and releases. As we work with Agile methodology we always have finished and tested user stories when a sprint is over
Our release contains features and resolved bugs. We have a roadmap and plan our features with our work tracking | ALM service, currently we use Azure DevOps.

Below is our work item (issue) types and their relations

Traceability

All our issues | Work Items are linked, for a feature which is deployed in a release we can arrive to it’s stories (children) and their work tasks.
Code is linked to its respective bugs, stories (which are linked to their parent features)
Every Build and Release contains links to code commits, pull requests and work items delivered

Version Anywhere

All our releases are versioned with semantic versioning: <major>.<minor>.<patch>

Every Release is versioned :

• version number is set on the code, database, files and the artifact itself. Our version appears in the API and also the UI of the application

• Code is versioned with tags that contains the version number
• QA verification tests are planned for release (including regression

We have DevOps processes to continuously monitor security and quality of our product

• All artifacts created are versioned and stored in a repository (Nexus)
• Our Database is also versioned – we developed a process so that during initial start of SyncNow it’s checks the database version and upgrades it
• When an artifact is ready it is versioned and published to production repository

Work Process In General

Features and Bugs are set in Azure DevOps and related to a release. Features are split into user stories and prioritized in the backlog

Every sprint is planned

We work with agile methodology, every sprint we set work for stories and bugs to be developed.

Developers opens a branch from story, write code , CI processes verify code quality ,security (see code Section and CI-CD for code)

QA verifies stories during the sprint, Auto tests are running every day to verify the stability of merged code

Stories are closed after Demo meeting NewElaborationReady For DevIn ProgressResolvedVerificationClosed

Code

We are working with git flow methodology, every story developed/ bug has its own branch. When development is finished, we have pull requests with code reviews, then the code is being merged develop branch (release for sprint bug fixes, master for hotfixes + backward merging).

See CI for commits and verification

CI – Build & Promotion

We monitor code changes continuously

Develop Branch

When code is merged into develop branch, we examine the code for Quality and Security Issues and create an artifact for dev integration.

Release Branch

When code is merged from develop to release branch it is considered approved by developers (including DOD has passed), release builds automatically executes and create a versioned release for QA, the release is placed in our internal repository and deployed on QA request to QA environments.

Finished Release – Promote to Prod

When a sprint is finished, we decide if to publish a release. We promote and store the release for our customers in production repository.

CD

All of our deployments are automated for our dev | QA, we use dockers, AWS for our deployment as we can select a version and release it to any internal environment.

Customers deploy manually with our installation script

Hot Fixes Flow

Product defects (production bugs) are prioritized over the backlog, critical defects are set to work immediately with the following process:

If the bug is large and will take time to resolve it will be added to the current sprint and will be developed, verified and deployed as part of the ordinary work flow.

If the bug is small :

1. Developer create a branch from master with the name bugfix/<bug-name>
2. The bug is set to in progress state and code is being developed to resolve it
3. When developer has finished the bug it will be reviewed and then, build and deployed to QA environment
4. After QA will verify the bug fix the build will promote the artifacts, code will merged into master and to other branches of needed