As a seasoned developer of a bit over 15 years I’ve grown accustomed to having an organised dev to staging to production process. Software is hard so it just makes sense to have a staging environment where things can be tested and bugs ironed out without affecting a live production server.
Shopify is a platform that means business, now powering many global leaders of ecommerce. If a bug gets into their production Shopify Plus store it’s going to cost them serious money in lost sales. I’ll show you how to set up a staging environment for your Shopify store.
What do you want to stage?
Conceptually we can think of a Shopify store as two pieces: 1) the data of products/collections/pages/images etc. and 2) the theme and its configuration.
When deciding what you want to stage, first think about why. Bugs in the theme (2) can be the most apocalyptic: customers can’t order products. Errors with the data (1) may also be bad: incorrect pricing, bulk deletes done in error.
But these two pieces may be owned by different people on your team working on different things. Having a single staging environment for both your shop’s theme and its data could slow your workflows down and cause confusion within your team.
My recommendation is to focus on having a staging environment for your theme (2) and for your data (1), a backup instead of a staging environment.
To be a useable staging environment for your theme it should have some up-to-date data, but it isn’t used as a place to test that data: just your theme.
A wishlist for your Shopify staging environment
Shopify does present some unique challenges when it comes to setting up clean staging and production environments! Let’s take a minute though to think about how we’d like it to work.
- Master branch – the live Shopify store www.pluginuseful.com
- Staging branch – staging.pluginuseful.com
- Feature branches for local development
A spanner in the workflow
What makes Shopify pretty different to most software is that the code and configuration can be changed at any time by anyone with access to the admin. Someone on the team can install an app or customise the theme, or even (horror!) edit theme code.
We can’t just have our git repository as the source of truth that master equals production.
Some workflows say that the theme settings can just be ignored for the purposes of development. However this limits us from using the theme settings in our development and makes our development and staging environments out of step with production.
Our solution will instead make sure that theme settings can be changed in both production and during development.
Apps can go amok in a theme, changing all kinds of things everywhere. But they are much beloved of shop owners and give great plug-in functionality to shops.
Our goal is to let apps do their own thing, reflecting that in our git repo as a change.
While everyone on your development team will likely follow your development workflow and never make changes using the Shopify theme editor, you can’t count on other collaborators to do the same.
Your client or someone else on your team might hire a developer/designer/marketer for a small job. They’re just going to open up the live theme, edit the code, done. Overwriting their work would not be good.
Real-world Shopify development workflow
With that in mind, we’ve found this is an efficient and realistic workflow, benefiting everyone who works on the shop.
First, set up a git repo on your hosting provider of choice like GitLab.
Beanstalk is software that lets us deploy automatically to our Shopify store whenever we change a branch in git- saving a lot of time. The free plan covers just one deployment, ideally we want two: production and staging. Sign up for Beanstalk.
Set up Beanstalk to pull in your current live theme into your git repository. Create a new deployment in Beanstalk to automatically deploy changes to your live Shopify theme whenever master changes.
Duplicate your theme in your Shopify admin, calling the copy ‘Staging’. In git, create a branch off of master: ‘staging’. Set up Beanstalk to deploy to the Staging theme copy whenever your staging branch changes.
If you haven’t already, set up your local development environment using Slate. My recommendation is to use development shops created in your Shopify partner admin to develop against, not your live shop.
Now you’re ready to develop!
- Take a branch from master ‘shiny-new-feature’
- Develop locally using Slate
- When dev and dev test is complete, create a pull request to master
- Merge your shiny-new-feature branch into the staging branch
- In your Shopify admin download your production theme
- Switch your branch to master
- Copy the contents of the production theme zip into this folder, overwriting existing files*
- Commit any changes directly to master with as descriptive a comment as possible (like ‘Installed slideshow app’)
- Merge master into staging
- The staging branch will now automatically deploy to the staging theme copy using Beanstalk
- To view staging, in your Shopify theme admin push Actions > Preview
- Test and fix
- When staging is ready to deploy, depending on how long has elapsed you may want to repeat steps 5-9 again to make sure git is up-to-date
- Approve the pull request and merge into master
- Beanstalk will deploy and your change is live!
* We’re doing this to make sure that any changes that have happened to production in the meantime (app install/uninstall, theme settings, code edited) are reflected in git.
Some of the tooling for Shopify could be improved to support this, but the solution we use here is a good way to get clean development, staging and production environments on Shopify.