We have three environments - Test, Staging, and Production, where the all content is created directly on Production. The problem is that when we test functionality on Test our testers look also at the content, which may not be 100% the same as in Production (i.e. older). In some cases we can discard that, but in other it is important that the content is correct. We do make a back-up of Production's DB and restore it on Test and Staging on regular basis, but as we develop new content types and test them on Test, the restoration of Production's DB may interfere with the other tests.
So my question is how do you manage your content? Do you write it on Test and migrate it to Staging and Production? Or do you only write it on Production and migrate it back to Staging and Test regularly? How do you distinguish between functional and content test on Test? I would be happy to hear your experience :-)
We have the same setup in a few projects. Our strategy is normally :
1. Content is created on Production. Stage contains the same content as production using a db backup every night. We use this mainly for reproducing bugs and system testing.
2. Test server contains content from production too but slightly older. We normally update at start of sprint.
3. Functional tests after sprint are done on test server with some demo content.
4. Full test including regression test is done on stage before major releases with latest content. If it's a major release with lots of content changes, we switch dns instead to let stage become the new production.
5. Unit tests are run on developer machine currently. Sometimes we use build server for that as well.
Thank you, Daniel, for sharing your strategy. We do something similar today, so it was interesting to see what others do as well :)