This article is intended for those of you with a business - who still hopefully have a business in these horrifying, challenging times of the coronavirus pandemic. A tiny, tiny silver lining of this shelter-in-place time might be that you have some more time available to devote to improving your business or your practices. If so, this one’s for you.

Meanwhile, hang in there everybody - we hope you and your family are safe both medically and economically.


Intro - Your Sandboxes

It doesn't take a degree in software engineering to intuit that developers should not be editing and testing files in production. Whether it's sophisticated APIs, supporting files for internal company software/apps or it's on files on your website, you need a "sandbox" to play/test in before you let them go "live".

These terms and environments that we're about to talk about might sound overly serious or like big-time programming, but they are just as applicable to a simple website - perhaps even more so. Accordingly, if you're reading this and the only software you're involved with is your one-page website, it still applies to you!

We all like to think we do the right things with backups, testing, documentation - but are we really as good as we think? Having a "staging" environment is one of those areas where we get tempted to cut corners - and somebody needs to slap us on the wrist. Consider this article as that slap.


The Various Environments

* Development - Where the developer is actively writing code and doing real-time trial-and-error testing while coding. Could either be the developer's local machine or an easy place to deploy (the latter especially if the development/testing is collaborative and not done just by one person).

Conditions and settings should be fairly similar here to the production environment, have the same plugins, use the same supporting APIs, etc. And if the environment is the developer's local machine, for web projects, something like Windows IIS should be installed so it's running like a server.

* Testing - This should definitely not be a local environment and it should very closely mirror the production environment with identical hardware and software.

While a programmer's local "development" environment can have rapidly changing code, the testing environment should have build numbers assigned so problems, testing, changes for a particular build version can be referenced.

In a group setting, then other team members would do their testing in a "test" environment (instead of the shifting "development" environment). And if multiple developers are working in separate areas of the application, they would work on their own individual changes in development, but the two people's work gets put together and really tested in tandem first in this test environment.

* Staging - Everything here should be exactly as it's proposed to look like in production environment when released. It's basically what's going to be released but a final environment to test and evaluate before deploying. Or think of it as "pre-production."

You probably should only place things here that are seriously ready for a new release in the near future. Don't stockpile all changes you've made in the last 3 months here.

* Production - The "live" version of the application that customers/employees (or "end users") are actually using.

Ideally should only be new production versions in officially scheduled releases.


Exceptions?

Can you survive without discrete Testing and Staging environment? Yes, you can. But life will be much better to have both. Think of Testing as the place to unit test what you're working on, but Staging to really system test the latest version of the app.

This is the crux of this whole article. If you're developing your website just by yourself, maybe you can skip the "testing" environment - only if your development environment truly mirrors its production conditions - but you better treat your testing in "staging" very seriously.

Another thing I can tell you from experience is to not be tempted to cut corners. You might think you're just correcting a typo so you can push it from development to staging, and then to production while skipping build testing, etc. This is a VERY slippery slope, my friends. Yes, you can do it, but be very careful about this. If you keep going down this road then you'll start losing the ability to track what changes happened in what build, your source control will get sloppy, and seemingly innocuous things like swapping out a photo can all of a sudden break your design. Be disciplined! (These days tools like .Git and the major cloud hosting servers - or the tools at your web host - make things easy, so there's really no excuse to cut corners.)


Simple Websites, WordPress

Like I said before, these principles aren't just for sophisticated software projects. Even if your website is basic WordPress site or some other CMS solution where an online control panel basically is developing your web site for you, that's no excuse to be implementing your changes live without "staging" or testing.

Basically, you need a "sandbox" to test your new changes before they go live.

You can Google "staging" and "WordPress" and come up with some great advice. I recommend this one. And this site has a great how-to for setting up staging. But lots of popular site hosts (like SiteGround) have them built in.

Even if you have a simple website with no WordPress or framework (old school!) and FTP your files up to your server, make sure to have a separate server folder to upload the staging version of your site to before you deploy. And don't leave it exposed - here are our tips for robots.txt files & "dorking" concerns .


Tools Out There

If you're truly doing software development and not using .Git for source control, I don't know what to tell you. There are so many great .Git applications, tools out there like BitBucket, SourceTree and also tools/plugins within Visual Studio. (Just make sure not to confuse what we're talking here with "staging" environments with .Git staging before commits.)

The heavy hitters in cloud hosting have truly great tools that help manage separate environments (testing, staging, production). Amazon (AWS) environment has the Beanstalk environment management console. And Brad and I here are really fond of Microsoft Azure's "slots" where we just "swap" the successfully-tested staging slot into becoming the production slot.

And if you're developing with .NET Core then they have the .NET core runtime environment variable to control which environment you're in to manage some elements slightly differently in various environments. Case in point: we have one app that sends hundreds of scheduled reminders to customers in live production environment, but we don't want those going out from the development or staging environments using/testing the same production dataset.


Able To Rollback

One of the great safeguards of all of the modern hosting, cloud hosting, backup and source control tools is that we can roll changes back if we find a problem in the production environment we didn't previously catch. If it's a serious problem, we can roll back code to a previous build. Similarly, we could roll back to previous versions of a database if we got bad data in there, or a previous version of just one component of the app (like an API).

To do any of these, you need to build your code in discrete build versions (made easier with .Git, other source control solutions) and have intelligent automatic backups or snapshots (like a nightly capture of your database).

Even if you're operating without source control and just FTP'ing your site to your server on occasion, if you're disciplined about backing up your versions or just backing up your computer with scheduled backups, then you'll be good to restore things to a safe, previous state whenever you need.


Minimum Takeaway

The biggie is: Never edit production files live.

And if you want to be professional about your operation, then get a middle, "staging" environment together.

Please, let us know what you think .