Similarly, you could try to deploy your code straight to production, but only expose part of the traffic to the new code for some time. You can build a system where only a small percentage of the traffic hits the new servers that are running the new code and compare the error rate and performance originating from each release for a short period of time. Usually, 10% of the traffic for 10 minutes is sufficient to collect enough information about the quality of the new build. If, after that time, everything looks good, you can then move 100% of the traffic to the new version of the service.
Bugs such as memory leaks are usually slower to manifest themselves; once the deployment is complete, continue closely monitoring your ...
