Deploying a release is nothing more than the importing of a release file (.bprelease) created in a lower region (DEV, QA) to a higher region (QA, PROD). To do this, you must create a Release Package, which is a template containing all of the components of the release (such as Processes, Business Objects, Work Queues, Environment Variables, etc.). Releases themselves are created from the Release Package "template".
In the lower region, create a Release Package and populate it with all of the components needed for the release. Give it a name so it can be referenced again in the future when you need to do another Release. Once the Release Package is created and saved, click the New Release button. Give the Release a name and a storage location. This location should be a folder that will be accessible in the higher region. BP will create the Release and save it in the specified folder with a .bprelease file extension.
In the higher region (say, PROD), you (or more likely a Release Manager -- I will discuss this in a moment) will select the File menu, then Import. Navigate to the folder where the Release is stored and select the Release. Click the Import button. If it is a first time Release, BP will just import every component. If it is a subsequent Release, BP will present a table onscreen listing the components found in the Release which already exist in the destination region. From there, you will need to choose for each component whether to overwrite it or skip it. There are other options for which I will direct you to the Release Guide on the Portal to learn about. Once each choice is made, press the Import/OK button (I forget which it is, and I don't have access to BP at the moment to check. In any case, the button choice will be easily identifiable). BP will import the release, skipping the components you chose to skip and overwriting the components you chose to overwrite. Click the Finish button when BP is done importing. You should now see the components in the higher region, or if it was a subsequent release, you should see in Studio that the components you chose to overwrite have been updated to the new version.
Regarding my comment referring to a Release Manager: In many organizations, a Developer will not have permission to import a Release, and that task is done by a Release Manager. This is a best practice recommended by BP. For example, in my organization, I as a Developer can import a Release from DEV to QA, but a Release Manager must import into PROD. Your organization may not allow you to import into QA, as every organization's policies are different. A Release Manager is simply a role that allows the user to import releases. Typically, a Release Manager will not have the same permissions that a Developer has, and vice versa.
Things to consider:
1) Please note that if you choose to include Credentials in a Release, the password for each Credential must be entered upon importing the Release. For this reason, in my organization we exclude Credentials from Release Packages and thus from Releases. We just manually set up the Credentials in the higher region. We do not want the person doing the Release import to have to know the passwords, and the passwords in the Credentials in the lower region may be different than in the higher region.
2) In some versions of BP (we are on 6.5), we have noticed that any Schedules included in a Release will be imported even if we don't choose to overwrite them. This can mess up your schedules if it is a subsequent release and the schedule has changed since it was imported. Importing the Release seems to set them back to the state they were in in the lower region when the Release was created even if we choose to skip them. For this reason, we exclude Schedules from our Release Packages and Releases. We do include them in the Release Package for a new first-time Release, but we immediately delete them from the Release Package after creating the first Release.