0

I'm hoping to implement staging and production installations for a larger scale Craft project I'm working on. My plan is to have the following structure:

/staging.domain.com -- Complete Craft Installation

/domain.com -- Complete Craft Installation -- Image Assets

Updates would get done on my local server and then pushed to the staging domain, and finally cloned to the production domain. The two would share the same database and images would live on the production URL. This would allow me to see client updates to content while I make changes to templates and presentation files. I would also be able to make and test Craft software updates in the background.

From reading the documentation I would use the Sites settings to add in both domains and then set variables (dev mode, for example) in the general.php config file.

Does this sounds like a proper set up for this situation?

One optional additional change would be to move image assets off the production server and onto their own (cookieless) domain...

Many thanks in advance!

Improve this question

1 Answer 1

Reset to default
3

Database

I strongly discourage you from letting Staging and Production share a database. That is a recipe for disaster.

Your Staging site should be semi-disposable, and it's likely that your client will treat it as such. The last thing you want is for someone to make a change in Staging without realizing that they are also making the same change in Production. It's counterintuitive and dangerous.

Instead, have your Staging database be a copy of the Production database. There are several ways to do this, and with the right tools it is actually very simple to clone the database on a regular basis.

I'd recommend using Craft Scripts by Andrew Welch to quickly & easily clone the database. I've found the pull_db.sh script to be quite invaluable.

Image Assets

Cloning images is also possible (Craft Scripts has a tool for that), but you may find that it eats up a ton of server space. This, of course, only matters if you're storing your asset files in a local folder. If the assets are cloud-based, then cloning them is a non-issue.

So instead of cloning your image files, I highly recommend the new Untransform plugin by Ben Croker. It allows your Staging server to actual use transformed images directly from the Production server. There won't be any need to store a second copy of those files, the Production site can provide the originals to your Staging environment.

Local Dev

You can use both of the aforementioned techniques on your local machine as well. Indeed, that's what they were originally created for.

Improve this answer
5
  • Many thanks for this. To clarify, your suggestion is to push the database from Production to Staging, correct? Would this cause trouble if the Staging Craft installation was updated first to try out new features, etc? In this case, would the process be: update Staging Craft installation > push file changes w/ new Craft Version to Production > let Craft update Production DB.
    – Document Services
    Commented Aug 30, 2019 at 18:52
  • Are you using Project Config? That would have a minor impact on your workflow.
    – Lindsey D
    Commented Aug 30, 2019 at 18:54
  • No, but I can. I have used a fairly low tech deployment process for past Craft sites (Local pushed to Production with a few safeguards) but its less than ideal as it requires me to isolate what I'm syncing and when...
    – Document Services
    Commented Aug 30, 2019 at 18:56
  • We don't use Project Config, and the processes I described work great for us.
    – Lindsey D
    Commented Aug 30, 2019 at 18:58
  • If you want to discuss it in greater detail, let's take this conversation over to Discord.
    – Lindsey D
    Commented Aug 30, 2019 at 18:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.