I am wondering where can I find some steps to create a staging for EE2 ?
-
2You need to clarify what you are trying to do. Do mean you want to create a staging copy of a EE2 production application? One where you can test development before deploying to a production application? If so, we can give some tips, but the theory behind a web application having testing, staging, and production instances isn't really EE specific.– jrothaferAug 10, 2018 at 4:14
2 Answers
If you know how to create a production or development server for EE2, you can create a staging server... if you don't know how to create a development or production server then go find that out first.
The challenge with database driven CMS's however is not the servers, it is the database that drives the CMS. Before you can push changes that include any changes to the database (i.e. in EE2, that's most things except perhaps javascript or CSS changes) you need to be sure that any changes in the database on the production server are replicated back to the development server... (otherwise when you ship the development server database to the production server, you may overwrite any changes that have happened on the production server while you were working on the development copy...)
There is no elegant fix for this - how you solve it very much depends on what you use the CMS for and what sort of changes you plan on making.
This is not an EE issue specifically - you'd have the exact same issue with any database driven CMS.
If you give some more info on what kind of environment you want the staging server for, maybe there is scope for a more complete answer, but for the generic concept this is it.
HTH
You might want to consider this Bootstrap file from Ben Parizek (originally from Leevi Graham). It allows for Local, Development (Staging) and Production (Live) environments. You can set different environment variables and database connections for each. Works well if you're using (and you should be) a code versioning system, and the some kind of deployment tool.
-
I don't want to hate, but this path basically makes you push environment variables across environments. I think it is generally a better idea to contain environment variables (such as DB user, DB pass, etc) to the machines they pertain to. You can do this easily by git ignoring secret credentials files, and not deploying over those configuration files. Any modern deployment tool lets you do this. Sep 4, 2018 at 6:44