Change control and Release management process for code - Archimydes/docs-public GitHub Wiki

These are the general guidelines we are following up for change control and release management for all of the Archimydes project.

• Change requests are created in https://archimydes.atlassian.net/jira/
• Change requests are then prioritised and assigned to the devs.
• All the code repositories are hosted within https://github.com/Archimydes
• Only the invited members can view and make changes to the repositories.
• Code changes goes through a Pull Request based peer review/approval process.
• For every change request, developers will create a branch out of the development branch.
• Makes the necessary changes, and raise a Pull Request against the development branch.
• Post review and approvals (min 1), the code will be merged to the development branch.
• Only the repository owners will be allowed to merge the code into the development branch.

• We do manual releases to staging and production environments periodically.
• Once we have aggregated changes merged to the development branch, those will be manually merged to staging branch.
• staging branch will be deployed to the staging env.
• Code repositories, will have the scripts to perform deployment.
• All npm repositories, will have npm deploy:staging as a script task.
• Once verified on staging env, the branch will then be merged into the production branch.
• A release tag is added to the production branch.
• Release tag should follow semantic versioning. (https://semver.org/)
• Any issues, identified in staging will need a fix in development branch first before moving to staging.
• Deployments to staging and production can be done only by the application owners.