A release groups delivered work into something you can name and talk about. Where tasks, plans and sprints organise work being done, a release organises work that is finished.
Find them under Releases.
What a release is for
Answering "what went out?" — for release notes, for stakeholders, for your own record of when something changed.
Coroid tracks work at the task level, which is the right granularity for execution and the wrong granularity for communication. Nobody wants a list of forty task titles. A release is where those become one coherent statement.
Creating one
Create a release and associate the delivered work that belongs in it. The work must exist before it can be included — a release describes what happened, it does not schedule what will.
Releases and your deployment process
A Coroid release is a record, not a deployment mechanism. It does not build artifacts, tag your repository or push anything to an environment — your existing pipeline does all of that, triggered by merges the way it already is.
That separation is deliberate. Coroid opens pull requests; what happens after they merge is your process, and inserting a second deployment authority into it would create exactly the kind of ambiguity you do not want on release day.
Relationship to sprints
A sprint is a period; a release is a shipment. They frequently line up, and just as frequently do not — a sprint's work may ship across two releases, and a release may collect work from several sprints.
Use whichever your organization actually communicates in. Using both because they exist mostly creates bookkeeping.