When developing a process for deployment of production code, several key concepts should be held as critical:
Above all else, the most important thing is a working production system. This is where all business value is derived and therefore, it must be maintained in a suitable state.
The main working branch of the code base should always be ready to be deployed. Changes committed to this branch must not prevent the deployment of code. If they do, immediate priority should be directed at fixing the broken code. If the issues are not resolved in a short period of time, the changes that introduced the issues should be reverted.
Everything must be tested. Any change made to the system, must be accompanied by an automated test that ensures the change made achieves the desired result and does not break the system. Anything from the installation of a Ruby version, the configuration of Nginx, or setting of environment variables to the functionality within the code to be deployed should have a test to ensure proper functionality.
Everything must be automated. The deploy process can still (and should) be initiated by a person, but once the process has begun, the less interaction required with the system, the better. People driving the process provide room for error, and eliminate the ability to create a deterministic process that is testable. Even the tests for the automation should themselves be automated.
The output of any build process should be an artifact that contains all dependencies bundled with it. Third party dependencies must be included within the build artifact to prevent the inevitable erosion that occurs when old production code needs to be moved to a new server. This also allows deployment with no connection to any outside services; so long as one has the build artifact and access to the server where the code will be deployed, one can deploy the code with ease.
The build artifact is a combination of the code to be deployed and any configuration that is not related to environment-specific external resources. The build artifact must be tagged with a unique version number and once created, it is immutable. Any changes must result in the creation of a new build artifact, which must go through the full build process. A build artifact must contain code that is suitable for release.
Any code that makes it through the entire build process (which encompasses the CI and QA testing steps) becomes a release candidate for deployment to production. Multiple release candidates may be created before the production code is updated to a suitable release, but the upgrade process is a separate process from the build process and should not prevent the ability to create release candidates.