How to make sure your website is NEVER accidentally deleted

One of the things I find myself explaining most often to my clients and students is that websites are LIVING beings.

Often people think that they just need to create their website once and it’s done. Not so! If you are running a business where the website is an important part of how you do business (like a blog, social network, online education company, or e-commerce shop) your website needs constant, often daily, maintenance and updates.

Some of those updates will be things you can manage through your content management system (CMS), such as changing the wording on a page, or deleting a post. But just as much of the work is going to take place in the codebase. You will need to fix bugs, update your user interface, add new states, features, and functionality.

So one of the first things you have to do when managing a web business is to create a process for how code changes are done and how your site is updated so that it doesn’t devolve into a hairy pile of unusable code, or worse, accidentally get deleted!

Among developers the process we are talking about is called “deployment,” which is to say that when you update your site with some new code you “deploy” your changes. If you ever wanted to learn how someone handles updates to their site you can ask what their “deployment process” looks like.

Here are three common deployment processes that developers use:

1. The beginner deployment process:

The easiest way to deploy a site is to upload the code files manually via FTP or SFTP. This is the process you would use with a hosting service like GoDaddy or Hostgator, and it’s usually the first type of deployment process that a beginning developer uses (in fact, it’s what we teach our students how to do in Skillcrush 101).

In the case of a simple website (like a personal portfolio or personal blog) this form of manual deployment works perfectly well because there are usually just a small handful of files being updated and only one or two developers making changes.

That said, the problem with this form of deployment is that it’s tedious and it’s easy to make mistakes, such as accidentally deleting or overwriting a file you didn’t mean to change.

Too Long Didn’t Read (TLDR): this process is ok to use when you are JUST getting your website off the ground, but shouldn’t be your long term deployment process.

2. The intermediate deployment process:

The more professional way to handle deployment (and what you see most web businesses doing) is to use a version control system (like Git) and deploy over SSH instead of FTP.

What this means is that a developer will make some changes to your codebase and then “push” those changes to your Git repository (which is tracking all of the changes). The codebase will then be put through the company’s testing process, which ensures that nothing has been broken by the changes, and then assuming all is good, the developer will manually trigger a deployment.

In other words, although the developer has to say YES, TIME TO DEPLOY the deployment itself (the actual updating of files) is handled by a script.

This approach is a mix of automatic and manual, which allows the developer to have control over the process but helps prevent dumb mistakes that are easy for people to make (like deleting files they didn’t mean to, etc).

In short: This is a great process for a small to medium sized web business!

3. The expert deployment process:

What makes the expert deployment process expert is that it’s almost ENTIRELY automatic.

In this instance what happens is that a developer updates some code and pushes their changes to the Git repository.

As soon as the developer pushes their changes, the deployment process automatically begins. First a series of tests are run on the entire codebase. If the updated codebase passes all of the tests, then the green light is given and another script pushes all of the new code automatically to the live site.

The important thing to realize about THIS process is that it will work if you have one developer working on a website or 1,000. In other words, let’s say you have 500 developers each pushing two updates to the site a day. Great! Your handy deployment script will deploy 2,000 times.

In short: This is the process that LARGE web businesses use.

Why you need to know about deployment best practices (even if you never plan to learn how to code)

If you own a web based business, or work for one, you need to understand deployment best practices because you need to make sure your tech team is using them!

There is nothing that will make your life more miserable or lose money faster than if something goes horribly wrong with your website’s code base. You have to protect it like it’s gold.

So next time you are hiring a developer, make sure to have them talk you through their preferred deployment workflow.


Emily Davis

Emily is the Director of Engineering at Skillcrush as well as the Product Development team's Scrum Master. Fun fact: she was Skillcrush's first full-time employee!

When Emily is not at Skillcrush (which is most of the time), she can be found practicing yoga, playing Zelda or wrangling her wild child of a daughter Ramona.