I use different approach depending on scale of update.
1. Small changes with minor updates to content. Add manually by editor (which might mean the developer) on production after minor feature release.
2. Large changes of content => create an export from staging environment if you have one (or test environment if you don't). Import after release of new functionality.
3. Major change of site (2.0.0). Take a exact copy of production to stage. Let editors work there for a week or two while production is frozen. Test like hell. Switch DNS to point to stage instead when releasing.
For finding necessary changes to content after each release is mostly about communication with editors. Reports on test environment can help you find changes of course. But normally the functionality should be documented and demoed to editors after each sprint/delivery where they are reponsible for adding the functionality to stage/prod. I add new tasks in my issue management system (JIRA) for required content changes for next release. Then when adding new functionality to test that requires editor changes on prod, I also add a release task for editor (update page x with bla bla bla to make it work).
You also have mirroring as an option. I'm not a big fan of that option yet. Have caused me more headaches rather than fewer...That's just my opinion of course :)
Also the new projects feature is a nice option for preparing a major update...
So I think the tools are there and it usually boils down to a communication problem => keep track of required changes to content / release notes and documentation / demo / training for editors.
I do love JIRA btw for issue/release management.
We have a process that includes issue tracking, manual update. But the process is error prone, since mistakes happens almost every release. We tried to do exports but there is always some sort of import/export problem, and it's hard for the editor to know how and what to export/import and you would almost always need developers tell editors what to export/import.
Is Mirroring the Epi Server recommended solution for this problem? What is problematic with Mirroring?
You get an additional integration between environments and that always costs more time / money than you want. But yes, the idea is using export/import for manually moving content or mirroring for automatic updates.
But additional complexity costs too so I normally go with a manual approach + additional testing instead. No right way to do. Just a few pros and cons with both...
What is the recommended way to move content between a test environment and production environment. The customer I work for have a process that works like this:
Developers add new functions and new content, page types etc in test environment, when the sprint finish, they manually copy all the content from test to production. Well, the problem with this approach is that sometimes, people forget to copy newly developed content when releasing.
Is there a recommended way/process in Epi Server to move content from staging to production. What I would prefer is to log in to Epi Server production and get a list of content that changed in the test enviroment from a specific date. Then be able to import that content into production.
Any thoughts on this?