Code Review before publishing changes to the Development Environment

By Billy Blackwell on 24 Feb
As a Team Lead, Department Manager, Lead Developer, etc.; I would like to be able to review the changes made to an eSpace by subordinate developers before they are committed to the Development environment.  
 
Currently, all changes made are immediately published to the Development environment.  These changes can then be deployed to the Test environment with the assumption that the changes are correct and follow best practices.  Also, changes could have been made by more experienced developers in the same eSpace.  However, in a large application, it is very easy for novice developers to complete their work and publish it to Development without any oversight.  When the application is being reviewed in the Test environment, discrepancies will be found that were created by the novice developer.  All changes will then have to be rolled back, including the proper changes made by experienced developers, which will delay deployment.
 
I would like to be able to set a role in LifeTime for developer users that prevents their changes from going directly to the Development environment.  Instead, their changes would go into repository like a “shelveset” in TFS.  The novice developer's supervisor could then access the changes, review them, then move them to the Development environment.  If any issues are found, they'll have no effect on the rest of the Team or delay deployment.  It could also serve as a training tool where the supervisor could review the code with the novice and teach them how to correct their mistakes.
J.26 Feb
I agree there should be something in place like the Pull-requests from Git.

However, Imho, it should be done from dev -> test, otherwise, how could the developer test it properly, without actually publishing to dev.