The company my team is delivering additive value to product in terms of continuous evolution there are two principles which makes me think more about release cycles.
The company PO conducts Integration Testing and when it has passed they conduct User Acceptance testing. Without those procedures they are not releasing the release into production.
User Testing can never occur more that once in a month or two, because the users do not have enogh time to test after every short sprint release. Hence we are calling or sprint releases “pre-releases”and defining a release backlog which is “the master” in terms of nesting to sprint backlogs within the release.
My trouble is that before the sprint begins we have to conclude the release planning meeting when we determine the tasks from the product backlog which are going to be a part of next production release (so we create release backlog and then cut it into several sprint backlogs).
What are the best ways to connect the actual releasing process into production with the process of creating another release backlog? Should the releasing process be one of the last sprints of the previous release cycle (release backlog) or should there be a gap between release cycles (thus the sprints) ?
Find the answers in the Comments
Agile Web Operations 
I would not create a gap. Better do all the release planning and going live preparation during a sprint. Sprints should create a takt and if you miss one, you are out of the rhythm of the sprints. That’s not a good idea IMHO.
LikeLike