I am aware that the length of a Scrum Sprint can vary on a case to case basis. This raises the following questions:
Typical approach
Scrum by-the-book assumes that you release at the end of iteration, then you demo the product to a client. "Release" and "demo" of course may mean different things depending on a product you build, e.g. back office app for big corporation versus an app directly addressed to end-users.
Most Scrum teams try to release at the end of timebox as it gives them more freedom in terms of how the work is done within iteration, e.g. they can start everything at the beginning of a sprint and finish stories only as the sprint end approaches.
Frequent releases
However, if you want to release more frequently, which I would personally encourage, feel free to do this, no matter what is the typical practice or what books says. Scrum, as any other method, is not a religion and shouldn't be treated dogmatic.
You might want to introduce (more) frequent releases since:
By the way, there are methods that are decoupling planning, release and retrospective cycles. In this case we are talking about cadence. Planning cadence doesn't have to be the same as release cadence or retro cadence is. It's just Scrum that made them so. Read more about cadence versus iteration here.
In general, change to frequent releases affects the team as the tools you use usually have to evolve. You can spend a couple of hours to release a product if you're doing it bi-weekly. If you're doing it every single day, you can't. The good thing is that you may make this transition evolutionary, shortening release cycle step by step, e.g. from bi-weekly to weekly, and looking for pain points and addressing them.
Scrum originally didn't have anything related to releases, but fortunately it has been changed and there is a thing called Release Planning. During this meeting the Scrum Team and the Product Owner sit together and see when the product can be released. It is a high level planning meeting.
In reality, the releases are set by the projects and the stakeholders. The Scrum Team and the Product Owner shall use this meeting to give a periodic feedback to the stakeholders about the release. This feedback should contain information about the risks, scope (content) and possible impediments.
The frequency of this meeting depends on the length of the Sprints and the length of the original project. I didn't manage to find any data on the frequency, but I'd say have at least 3 meetings during a project - equally distributed on the length of the project.
This was the case when the release is pushed to the team. If the team can decide on the releases then I'd refer to the original Scrum idea that the result of a Sprint must be something shippable, hence the release happens after each Sprint Review Meeting.
Frequent releases in a large context have a huge overhead, but the feedback received from the customers/users/stakeholders are very valuable. That's why teams should do Agile: have frequent feedback on their work to verify that they are on the right track, and without frequent releases it is hardly possible.
I think as soon as a releasable package is ready, it can be released. That is why I wrote about why sprints should be time-boxed and fixes and releases can happen whenever a releasable package is ready. You can decouple the sprint process from the release process:
Thanks for advance CI and Continuous delivery process, we are able to release even multiple times a day....The release process in most places can be almost independent on sprint completion.
— Excerpted from Why time boxed sprints? What happens to releases?
The frequency of releases in a Sprint is not defined by definition and this could vary on need basis of the Project to the scope definition of a release by the Product Owner. Though majority of the teams prefer to do the release in the end of the iteration.
Another import aspect of a release is the Velocity of the team. This term is not talked about in any of the answers. Velocity is the average of the total number of Story points Story points completed by the Scrum team. The same is calculated based on the following points:
The role of Product Owner includes, keeping a well prioritized and defined Backlog. This high priority Stories of the Backlog should also have Story Points. Based on the Some of Story Points the Product Owner wants to completed and included on a release and the Velocity of the team the number of Sprints needed to make a release could be calculated.
Number of Sprint needed for a release = Total Number of Story Points to be Completed / Velocity of the team
This would be helpful to get a release date. Thus, a Product Owner gets an option to change the release date or the Scope of the release based on the Velocity of the team. This could result in a release after 5 Sprints of more than 5 releases in the Sprint.
Release happens at two levels - to the internal stakeholder; to the external customer. As far as the scrum team is concerned, it is Done once it is code, designed, tested, deployed in Pre-Prod or Prod, bugs fixed and user acceptance is received. This is called Minimally Marketable Feature. The customer may choose his own time to deploy in live server.
Scrum is about time-boxing. Continuous delivery is about rolling releases and (to some extent) automated continuous integration and deployment. They are not completely orthogonal, but they are not synonyms, either.
If you're practicing "real" Scrum, then a release should coincide with a shippable increment at the end of a time-box. However, I have seen real-world examples where "shipping" was a story within a Sprint, where the shipping story is tracked as work and has user stories that continue on past the shipping story in the Sprint Backlog. If that fits your work-flow, then it's certainly something to consider.
Alternatively, any Sprint can be abended by the Product Owner, so even within the traditional Scrum framework there's a methodology for shipping early. The idea is that the Product Owner can terminate the Sprint at any time and return the team to Sprint Planning. This incurs process overhead, but it may very well be justified in some cases.
An early Sprint termination isn't automatically a negative thing; it's simply a management tool that trades some cycle time and process overhead to respond to changing business requirements. If the Sprint Goal for a given Sprint is "ship the product," then early termination of the Sprint after a successful product shipment is the very essence of agile, since the project doesn't chug along and incur costs that aren't necessary to the organization once its goals have been met.