I worked for the U.S. Navy as a contractor for years. They demanded separated files and environments because production outages would potentially affect a lot of folks. They applied that to big systems and small systems. (To be clear, mine was a smaller system.)
What you do is you have a fully secured, ready-to-use production front-end linked to your production back-end. That goes in your production folder. What your end users see is always from the production folder. File permissions allow them to do what is needed in the production folder.
BUT... you have at least two more environments. (I had three more.) Something that you are building is built in a private folder and that FE/BE combination is NOT fully secured. Because your users never touch the development area, file permissions will block them out totally, but you have full control. You do what you have to do with the "dev" copy. Edit, play with it, etc. Eventually, you have a copy you think will be stable enough to try it out. So you promote it to TEST.
In the Test environment, you have a nearly secured FE/BE. "Nearly secured" because you allow yourself to open that TEST copy with the BYPASS keys because you have not yet disabled the SHIFT BYPASS feature and any other things you might do for the "prod" copy. But the links to the private TEST back-end are there. As to how many people there are in this folder? All of your testers - and you - have access but your end users do not. If the tests fail, back to the DEV copy. If all is good with the world, you are ready to promote.
I built a staging area where I could do what I needed to do on the copy of the DB that had passed all tests. It was in this STAGING area that I finalized all links to the PROD back end file and set the Opening Menu and locked down the SHIFT BYPASS feature and any other restrictive things I needed to do. When all was well, I then copied from STAGING to PROD and notified all users that a new copy of the FE was available. I could not use the automatic updating batch job because my Navy IT guys had this thing about scripts. When I was done, the fully secured copy of the app left over in the STAGING folder became my backup copy.
Doing it this way, as long as I was ONLY changing FE stuff, I never had to take down the DB. But if a new FE change required a BE change, I would take the DB down, work on the BE file in one of the other areas, and eventually replace the old BE file with a newer version of same.
By having the DEV, TEST, STAGING, and PROD folders, I was able to keep things very tightly organized and at the same time, keep the Navy brass happy. Worked well for me.
