TIL Thursday: Your Questions About Backups Answered

It is not uncommon that when someone joins or leaves a role, that ownership of a SuiteCommerce Advanced site changes hands. If you're the person who's taking over control of that website, it can be difficult to get up to speed. After all, the previous developer has their entire development environment set up and running at full steam; you, on the other hand, don't.

This is where backups come in.

By default, whenever you deploy SCA code to NetSuite using Gulp, a zip file of the distribution files is made and uploaded along with deploy distribution. If you have this backup zip then you can recreate the site on another computer.

We have, however, received feedback from a number of people about this process, so I wanted to put something together which I hope will help elucidate things.

Can't I Just Use Version Control?

Yup. We recommend using a version control system, and you can read my write-up on how to get started with Git, a VCS that I, personally, prefer. We also recommend using Git as an easy way to apply patches to SCA source code, and we know our partners use it and has aided them when migrating to newer releases.

One of the benefits of VCSes is that they allow you to quickly distribute up-to-date source code to whomever you want. If you have multiple developers (or if you're solo and you handing over to someone else) then giving access to your repository allows you to carry the change log on unbroken.

Restoring from a Git repo, for example, is typically quicker than the process of restoring from a NetSuite backup. If the site is already up and running, getting a new developer up to speed is sped up by Git because you've effectively created and distributed an image of the local development environment.

What is the Process?

If you're not using Git, then the new developer will need to go through the normal setup process for the dev environment, specifically installing Node and Gulp and a copy of the unmodified source code for the SCA version the site uses. Once they have those set up they can grab the zipped backup from the backend.

Backups are stored in the file cabinet in Web Site Hosting Files > Live Hosting Files > SSP Applications > [name of SSP] > Development > backup. The backup is stored as a zip but will have a numerical file extension after .zip, which is usually 001.

Sometimes, there is more than one zip:

  • There may be a zip from the first time you installed the bundle (in which case, note the time stamps and grab the most recent one)
  • Your uploaded source is so large that it had to be split into multiple zips

After setting the local development environment, you unzip the backup file(s) and place the contents into the working directory. Allow it to overwrite any of the base files.

Now that all the files are ready, you just need to install NPM and then use NPM to install Gulp. You need to do this not least, because as you'll notice, the ns_npm_repository directory is not included in the NS backups.

After that, you should be good to go.

Do I Have to Upload a Backup with Each Deploy?

You don't. Naturally, we recommend that you do — however, during development this can be cumbersome as it slows everything down. There is a flag that you can attach to the end of the deploy command to prevent a backup being generated and uploaded:

gulp deploy --no-backup

You can see a list of all available Gulp commands in our documentation.

Are There Issues With Multi-Site and Backups?

At the moment, yes. We've been aware of an issue during deployment where the backup upload fails with an error message beginning like this:

Uploading backup{ Error: ENOENT: no such file or directory, scandir 'DeployDistribution/_Sources'

The problem lies in a way that some people are choosing to develop multiple sites at once, thus this is may be something you'll need to do on an instance-per-instance basis.

It can be fixed, though. The configuration for where Gulp should get the files for the distribution from are in distro.json. Open it up and in the folders object at the top, change the values of the distribution and deploy properties to the names of the directories for the specific site you want to deploy. In other words, you can only deploy one site at a time and each time you want to deploy a site, you will need to specify the one you want.

Next, you also have to make a change to gulpfile.js:

// Change this:
process.gulp_dest_distro = path.join(process.gulp_init_cwd, package_manager.distro.folders.distribution);
process.gulp_dest_deploy = path.join(process.gulp_init_cwd, package_manager.distro.folders.deploy);

// To this:
process.gulp_dest_distro = path.join(package_manager.distro.folders.distribution);
process.gulp_dest_deploy = path.join(package_manager.distro.folders.deploy);

In other words, you need to remove process.gulp_init_cwd, as arguments.

Once you've done that, you should be able to deploy and do backups normally.

Final Thoughts

I recommend using version control, not least because it may alleviate some woes you experience with backups. If you're happy with VCS then skipping backup with the --no-backup flag can save you time when you deploy.

Do you have any questions or tips with backups? Use the comment section below to share.

Special thanks to Chris Dembek of Intente for providing additional information for this post.