Automated Releases
Similar to builds, your releases should not be manual. Future maintainers should be able to make changes and deploy automatically or with a click. We typically use Azure DevOps Pipelines to automate these.
Some things your releases should do:
- deploy an artifact from your automated build to an environment
- progress the exact same binaries through environments dev -> test -> uat -> prod (same bits that were tested in earlier environment should go to prod)
- notify stakeholders when a new build is deployed to production
- summarize changes so testers and stakeholders can see progress and know what's new
👮♂️ Note: it is also extremely important that secrets (passwords, keys, etc.) are managed properly and are not store in source control, but either managed as variables
Frequency
You should strive to release incrementally to production frequently throughout your project (ideally, every iteration). This enables the possibility of getting real user feedback, QA, etc. within the timeframe of a project.
Projects that end with the final week or two being QA, followed by the first deploy to production often overrun schedules and might require surprise support (probably by you).
MVP
Determining an MVP (Minimum viable product) early will help your team immensely to get the first release out to customers. Real user feedback is many times more valuable than your guesses, and if you do this early enough in your project that you can continue iterating after with incremental improvements, the difference in value delivered over big-bang releases will be obvious.