Any reason NOT to use the subdomain for development?

Question

I originally planned to use the local machine on our network as a development server.

Then I had the idea of ​​using a subdomain.

So, if the site was located at www.example.com , then development could be done at dev.example.com .

If I did this, I would know that the entire software package was set up exactly the same for development and production. In addition, development can use the same database as production, eliminating the difficulties of data synchronization. I could use the same media (images, videos, etc.).

I have never heard of anyone else doing this, and with all these professionals, I wonder why not?

What are the disadvantages of this approach?

---

Update

OK, so it seems that there is no such approach that uses the same database for dev and production. If you choose this from the equation, is that a scary idea?

Answer 1

The obvious professional is what you were talking about: there is no need to duplicate files, databases or even software stacks. The obvious con is a bit more: you use exact files, databases, or even software stacks. Needless to say: if your development does not work correctly (endless loops and much more), the production will be demolished along with it. Obviously, it is possible to isolate both environments in the OS, but in this case you will return to the square.

My suggestion: use a dedicated development machine, not a production server, for development. You want to break it down to stability.

PS: Obviously, if the development environment skipped "WHERE id =?", All information in the production database will be deleted. That sounds like a huge problem, right? :)

Answer 2

People do it.

However, it is a bad idea to start development against a production database.
What happens if your dev code accidentally overwrites a field?

Answer 3

We use subdomains of the production domain for development, as you suggest, but the thought of the developer code regarding the prod database lifts the hair a little.

Answer 4

In my experience, using the same database for production and development is meaningless. How would you change your data model without changing the code? And 2 more things:

• It is wise to prepare all the changes to the SQL script that are run after testing from a different environment, not your console. Some random updates to the live system made me ride for weeks.
• As soon as I came to the conclusion that the restored backup did not reproduce the problem with the live system due to an unordered query result. This strange backup stock helped us find the real problem easier than retrying on a live system.

Answer 5

Using a production development machine will take away your ability to experiment. Trying new modules / configurations can be very risky in a live environment. If I messed up our machine with an apache conf error, I will just be a little uncomfortable for my fellow developers. You will be shutting down a live server while people try to give you their money.

Not only that, but you will share resources with the living environment. You can forget about stress testing when the development server must also deal with actual clients. Any errors that can cause problems on the development server (an endless loop occupying the entire processor, running out of hard disk space, etc.) suddenly become a real problem.