A release groups completed work into something you can name and discuss. While tasks, plans and Sprints organise ongoing work, a release organises work that has been finished.
Locate them under Releases.
Purpose of a release
To answer the question "what was released?" — for release notes, for stakeholders, and for your own record of when changes occurred.
Coroid tracks work at the task level, which provides the right level of detail for execution but is unsuitable for communication. No one wants to see a list of forty task titles. A release turns these into one clear statement.
How to create one
Create a release and link the completed work that belongs in it. The work must already exist before it can be added — a release describes what happened, rather than scheduling future activity.
Releases and your deployment process
A Coroid release is merely a record, not a deployment tool. It does not build artefacts, tag your repository or push anything to an environment — your existing pipeline handles all of this when merges occur.
This separation is intentional. Coroid opens pull requests; what happens after they merge falls under your existing process. Introducing a second deployment authority would create the very ambiguity you want to avoid on release day.
Relationship to Sprints
A Sprint is a time period; a release is a shipment. They often align, but not always — work from a Sprint may appear in two releases, and a release may include work from multiple Sprints.
Use whichever term your organisation actually uses. Employing both simply adds unnecessary admin work.