Let me preface this post by saying this is a bad idea for most true production systems, particularly ones with many hundreds, thousands, or hundreds of thousands of users. But for quiet, independently developed web apps with only a handful of users, I believe this is a viable strategy given the caveats in bold a few paragraphs down. Let me proceed…
In an ideal world for a production web app, you have at a minimum two identical systems with identical hardware, identical software, and identical operating system configurations. One system would be designated as “development” and another would be designated as “production”. This is ignoring an even better setup that incorporates a third identical system called “staging” which is more important when you have multiple independent development systems each managed by a different developer.
In a solo development project, you can skip the staging step and use your single development machine as “staging”. Still, in this simpler two-system setup, it is always nice if the development system is as close as identical to the production system as possible. What about taking it one step further – developing on production?
Now, of course, I’m not talking about developing directly on the app that production users (i.e., customers) are using. I’m talking about developing into a different directory on the same exact server and connecting into the same exact database and data storage systems. Since it is indeed using the production database, you can rely on your tests to know whether they scale because you are testing on ALL of the production data. That being said, there is a huge major super important caveat to point out given the connection to the live production database: any code that has even a remote potential of modifying/deleting/adding data should be double-, triple-, and quadruple checked before being tested. You should make sure you carefully go line-by-line through the code changes in the git diff along with the original source code and convince yourself 100% that you don’t have any serious mistakes that could compromise any data! Also, there’s no reason not to have a config setup to work on a trimmed down “test” database for truly major changes. But for minimal or minimally dangerous changes, as long as you are 100% vigilant, this should be ok. With all of this being said, proceed cautiously. The advantage is that the operating system configuration is by definition identical on both systems (development and production) since it is the same system. Config files can be closer to identical (but not quite) as can many absolute paths.
My current development/production setup is to develop using XAMPP-VM on a mac and then push to github, and then pull from github straight onto production. This works, but there are so many configuration differences, and the systems are most definitely “un”-identical enough that it’s actually a headache to get the development changes onto production safely.
Since I’m solo developing this and have recently merged the two systems which had diverged significantly over the years because of my hesitancy to try to pull those changes onto production, I’m going to try out this new approach where I configure a development setup on the production machine and work directly there … still using github to commit/push from the development directory and then pull from the production directory. I will know that things are going well if never get in a situation where I make a change directly in the production directory and need to push that change back to github. If that ever happens, then that means this strategy has not worked very well. Stay tuned!
