15 minutes of eComm Wisdom: Paul from Storetasker

I would say the most important thing to have set up is a code repository for your e commerce store. So like a code repository is where you store your theme code and files.

So anyone with access to this code base can see the full history of all the changes that were made to your theme code. So it makes the onboarding process more efficient. Because new developers can get familiar with your store by looking through your code base and looking at the history of changes.

Another thing that it does, the code repository is that it allows you allows for easy collaboration between developers so you can have multiple developers working on your code base at the same time, right?

Each developer is working on a separate copy, and they're able to do their work there. let's say you already have a main developer. [00:01:00] But, a third party app developer needs to make some changes to your theme to make that app work. You can simply just grant them access to your code base. you allow them to make the changes on their own.

And then you can have your main developer review the code base before publishing any changes. That's super important, right? And then lastly, the Code Repository, it provides version control. So like we said, every change to your store is tracked within the code base. So if you ever need to roll back to a previous version, it can easily be done.

so most common places for,hosting your code repository is GitHub and Bitbucket. So you can just simply, you set up an account, create your code repository and invite the developer. The one thing to note is, Most developers you work with, if not all, they already have a codebase with your store.

And I'm saying this because many clients, when I start working with them, they either don't know it exists or [00:02:00] they don't have a codebase. So one thing I always recommend is for stores to own their codebase, since you can control who gets access. And always have that access to all the history. So if you're ever onboarding a new developer or offboarding one or anything like that, you have access to that history.

. One other tool that I would recommend to have set up, to streamline onboarding a developer and for working with them is a project management tool. so there's a ton out there. There's like Trello, Asana, FlickUp. And within that, you want to have a dedicated development board.

So share a quick video of what a development board looks like.

All right. So, this is just an example development board template on Trello. really want to pay attention to the columns that I have here. so number one is you have the backlog, which is a backlog of all the features and fixes and projects that you want to work on with the developer.

Up next is just what is [00:03:00] going to be coming up next, right? In progress is, what the developer is currently working on. Once the developer is done. They would drag it to ready for review. So ready for reviews for you and your e commerce team to review everything. That's the QA process, the revisions, any fixes.

And once that is approved by your team, you can drag it to ready for release, where now the developer can start prepping the release to push it live to your store. Once that's done, just simply drag it to done. So you can see how it's a natural flow,of tickets. it reduces the need for all the email back and forth, sending screenshots.

about multiple features and things like that, everything is contained,in one ticket. and you can easily see the progress of how the, development of all these features and fixes are going. so if you feel free to use this template, it will save a lot of time in terms of,onboarding and collaborating with a developer.

[00:04:00]

Once the developers done with implementing the feature and they're ready for you to review, the most important thing to have first is

a staging environment to review and test everything. So the most common one and the simplest one that almost everybody uses is making use of a preview theme. So the developer would simply set this up for you, with the feature that they've been working on. And, you're able to preview the new feature without anything affecting the live site.

So you can test everything there. It works for the majority of features and fixes. And, allows you to test everything just on that preview theme. So that is the most common. You're probably going to do that most of the time. But there are some times where you're not able to fully test the feature or a fix because it involves changing something on your store, something that's going to affect the live site.

So let me give you an example. [00:05:00] tweaking, let's say you're, tweaking app settings for this feature, there's an app that you have installed on your store and you're going to, change up the settings, but that app is already live on your store. If you go and change those settings. Then that's going to affect the live store, and you can't do that at the moment, right?

So how are you supposed to test the new feature with those new settings?

So for this type of scenario, you should be testing everything on a separate staging store. So one thing is you can easily create, a separate store dedicated for testing. you can do that. through the Shopify partner portal. so you can go ahead and just set up a free development store or for Shopify plus you can make use of sandbox stores.

So this is just a store dedicated for testing. you can configure it to test everything for the new feature before going live on your store,without affecting anything like for your customers that are shopping live right now. I would say one thing to note is [00:06:00] that most apps, most popular apps, at least, they do have a free plan available for development stores.

So you don't have to pay for the app twice because if you install it on a development store, you're actually able to use that app for testing purposes. And I highly recommend using a QA tool. This is going to streamline the process for revision rounds between you and the developer and everybody on the team and also help identify bugs quickly. So the most. Popular QA tools that I've used are Pastel and marker. io. So I'll show a quick example of pastel, and how it can help streamline everything.

I'm using Gymshark as an example here with the pastel the QA tool.just a quick overview, you can test the desktop version of the site. You can test the mobile version of the site on the left hand side here. And then after you can browse the site freely as you would.

And [00:07:00] then what you can do is you can actually toggle commenting on. So what this allows you to do is you can point and click anywhere on the site. So, for example, if I, wanted to request a revision for this men's, copy over here. I can click on it and say,less bold, right? I can mention anybody here I can also add files and I can post a comment. So that would be for, let's say I want to have a revision done. an example for bugs. If this care cell isn't working, or there's some bugs happening here, I can go and select this whole section. And I can say carousel isn't working, when I click the arrows, right? so I can identify there's some sort of bug, post a comment. And then everything gets logged on the left hand side. the developer, what they're gonna see is A screenshot of what you saw, get information exactly where it [00:08:00] happened, what device and browser you're using, and pretty much all the information they need to either make that revision or to fix the bug. if you look here on the left hand side, it gives your comment, shows you exactly where this is happening. Whether it's on desktop or mobile, what browser version, and it just streamlines the whole process of requesting revisions and also logging bugs because you don't need to write up all of this stuff in an email.

You don't need to go back and forth with screenshots. You simply just like point and click and the developer gets everything you need. And you can pretty much haveyour entire e commerce team on this, submitting any, revision requests. Or,identifying any bugs. And then on the left hand side, you have, every all the comments here, and it tracks the progress of, all the revisions and bug fixes.

So you can see which ones are still active that need to be done, which ones in progress. which one the developers working on fixing. Then another [00:09:00] in review status and resolve. So it really helps streamline everything, makes it super simple. You point and click and also makes it a lot easier for the developer to understand what's going on, what revisions are requested and, and, help identify and quickly solve any bugs because they have all the information that they need.

I would say the most important thing is to have backups Now, you have a pretty easy way to do it in Shopify as well, where before pushing a new theme, or like an update live, go ahead to your live theme, duplicate that live theme and backup that live theme.

You can name that theme, back up, today's date. So that's what I usually do before pushing any new theme live or any pushing any updates is always create a backup so that after you publish a new theme, if anything ever goes wrong, In a matter of seconds, I would say, [00:10:00] you could simply go to that backup theme, click publish, and you're back to your previous version.

And then you can continue to work on and fix what's going on with the new theme and new feature and try to identify those bugs. That, is one way of, helping if anything ever goes wrong after, you publish a new theme live and then on the topic of preparation.

I usually like to have a launch checklist, for whenever we're deploying any new projects or features or any fixes, because it you prepare everything beforehand. So I'll show you a quick example of what's involved in a launch. And I'll show you, just a template, that you can use. All right, so this is a super, this is like a basic, general Shopify launch checklist. that you can follow. so number one is preparing final assets. So any kind of images or anything like that, make sure [00:11:00] you just have everything prepared, any content, stuff like that's needed for the launch.

then, schedule a launch window. So preferably early in the week. Cause then you have that whole time to make any adjustments or fixes or revisions. After that, once you scheduled, your, your launch, update any apps, content settings, or made a fields or products that will not affect the live site.

So do as much as you can on your Shopify store, like changing settings and stuff like that, that will not affect the live site, set everything up beforehanD.

Then what I like to do is at the time of launch. So during that launch window, let's say we're launching at like 12 PM, I implement a customizer freeze. So this pretty much just instructs the everybody on the e commerce team to hold off on making any theme changes.

It's just a good practice to do this. I've, had instances where somebody was changing the live theme while a [00:12:00] deployment was happening. And then it pretty much those changes got lost. so this is just a way to prevent that. I call that the customizer freeze.

And then, after that's implemented, you back up the live theme, the customer, the developer prepares the release theme, you launch the new theme, you're all launched, and then you update any apps, content settings, meta fields, that could be updated before that couldn't, it couldn't be updated before the new theme launch.

And one other thing to note is, assign any new product page or collection theme templates. This is the most common thing to do after launch, just because templates, new templates that you make in a preview theme don't show up in Shopify, until you actually publish it to the live theme. So once you do that, if you made a new product template or a page template, or whether it's a collection template, you need to actually go into this products and change that template.

So this is like the, one of the most common things you need to do after launching a new theme. [00:13:00] So I just put that there doesn't apply to, every single thing. And then again, test the, the new live theme, right?

So once it's live, test it again. Go through the main customer flows. maybe place a test order if you'd like. Test the feature again. Sometimes, you never know, things might change when you publish a theme live. Maybe an app does something. That's it. To the theme. that causes something.

So again, just test it right after it goes live. Make sure everything's working. And so I would say,that's A general, checklist example here,obviously you want to add a bit more detail, for whatever features you're launching, but this is just like the structure that you can follow as a bonus that, that can help actually make deployments more efficient, and

I would batch features and fixes into one deployment. So let's say you have three or four features [00:14:00] that you've been working on and include some fixes as well. And they're all done, they all were completed at different times, right? They're ready for release.instead of doing four separate deployments at different times.

What you could do is you could just batch those features into one deployment, right? So if you can hold off on certain features going live until the other one is ready so that you can batch everything, instead of doing four separate deployments, you're doing one, right? So you don't have to go through the deployment process four times.

You're only doing it one time. And, that will help save on development hours as well, because it does take some time to go through this checklist, to back up the theme and do everything for the deployment process. Thanks. And that can just help things,make things more efficient.

‍