Search for answers or browse our knowledge base.
SyncNow Release LifeCycle
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
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
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
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
When code is merged into develop branch, we examine the code for Quality and Security Issues and create an artifact for dev integration.
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.
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 :
- Developer create a branch from master with the name bugfix/<bug-name>
- The bug is set to in progress state and code is being developed to resolve it
- When developer has finished the bug it will be reviewed and then, build and deployed to QA environment
- After QA will verify the bug fix the build will promote the artifacts, code will merged into master and to other branches of needed