How to best deploy to staging/production with Bedrock & Sage

[MikeFishtank]

So in my daily work we have to update or amend websites frequently.

We use GitBucket for our repos and have a cloud based WHM/cPanel hosting setup. We’re new to Sage and our normal process before sage was to locally work on the site running webpack etc and this would compile any SCSS and JS and update a build directory etc. We would then simply push our changes to the repo and then SSH into the staging/production and do a git pull.

With Sage 9 the dist folder is ignored so doing this isn possible. I am currently doing what I feel is a backwards step…

After running yarn build:production locally I zip up the dist folder which is added to the theme folder and commit/push to the repo which I then have to unzip to overwrite the existing dist folder on staging/production after doing a git pull.

I’ve read the docs and search for better solutions but have found nothing that would make deploying to staging or production a easier/more normal process.

Does anyone else have a better way that would fit more closely to our original process?

[strarsis]

So you want to deploy on a shared hosting/non-VPS/non-Trellis system,

This theme zip build script for Sage 9 or 10 could be helpful:

Deployment on Shared Hosting

IMHO it could be quite helpful to add an “eject” task to Sage that automatically creates a minimal theme ZIP as build artifact. Note: node_modules/ is only required for building the theme - it is not needed and should not be needed by the theme during runtime. If there are any files that should be available for the theme, either add them using webpack (e.g. imported SASS, url(...)) or copy them from node_modules/ into dist/ or - for some cases - resources/. For Sage 10 themes: #!/bin/sh echo …

[alwaysblank]

If you’re using git to deploy, what’s stopping you from removing dist from .gitignore and committing your build artifacts? Sage’s only objection to that is philosophical; it should work with the process you describe.

[MikeFishtank]

Yeah that is a good option but locally when you run yarn start it generates a lot of development files that you wouldn’t want adding/committing to production.

[alwaysblank]

You wouldn’t commit the result of yarn start, you commit the the result of yarn build:production.