Any reason NOT to use subdomain for development?

I was originally planning on using a local machine on our network as the development server.

Then I had the idea of using a subdomain.

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

If I did this, I would know that the en开发者_运维知识库tire software stack was configured exactly the same for development and production. Also development could use the same database as production removing the hassle of syncing the data. I could even use the same media (images, videos, etc.)

I have never heard of anyone else doing this, and with all these pros I am wondering why not?

What are the cons to this approach?

---

Update

OK, so its seems the major no no of this approach is using the same DB for dev and production. If you take that out of the equation, is it still a terrible idea?

---

The obvious pro is what you mentioned: no need to duplicate files, databases, or even software stacks. The obvious con is slightly bigger: you're using the exact same files, databases, or even software stacks. Needless to say: if your development isn't working correctly (infinite loops, and whatnot), production will be pulled down right alongside with it. Obviously, there are possibilities to jail both environments within the OS, but in that case you're back to square one.

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

PS: Obviously, if the development environment missed a "WHERE id = ?", all information in the production database is removed. That sounds like a huge problem, doesn't it? :)

---

People do do this.

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

---

We use subdomains of the production domain for development as you suggest, but the thought of the dev code touching the prod database is a bit hair-raising.

---

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

1. Its wise to prepare all changes in SQL script, that is run after testing from different environment not your console. Some accidental updates to live system made me headake for weeks.
2. Once happend to me, that restored backup didn't reproduced live system problem, because of unordered query result. This strange baviour of backup later helped us find the real problem simplier, than retrying on live system.

---

Using the production machine for development takes away your capacity to experiment. Trying out new modules/configurations can be very risky in a live environment. If I mess up our dev machine with an error in the apache conf, I will just slightly inconvenience my fellow devs. You will be shutting down the live server while people are trying to give you their money.

Not only that but you will be sharing resources with the live enviroment. You can forget about stress testing when the dev server also has to deal with actual customers. Any mistakes that can cause problems on the development server (infinite loop taking up the entire CPU, running out of HDD space, etc) suddenly become a real issue.