When you build a new website, going live is relatively easy. You get ahold of a domain name, point it at a webhost, put the website code there, and you're up and running!
After a site is live, it gets a lot more complicated.
What's important about deployment?
If you have a simple brochure site, deploying updates doesn't have to be complicated. The more your site does, the more complex deployment becomes. A deployment plan can help you stay out of trouble, keep your site online, minimize data loss. So when going live with an update to a site, you should ask:
- How much downtime is acceptable?
- How much testing do we need before we make a change to the production site?
- What data could we lose, from the production site?
- What might go wrong with this deployment strategy?
- How can we recover if something does go wrong?
A good deployment plan should make you smile with comfort, knowing you have all the bases covered. Are you smiling? If not, read on.
Common deployment strategies
Here are the main strategies we've seen or used for deployment:
- Do all work in the production environment so there's nothing to deploy
- Copy the entire new site into the production environment
- Compile/build a site and put the result into the production environment
- Dev/Stage/Production pipeline
- Blue/Green deployments
Let's take a deeper look at each one.
No Deployment - work in production
All too often, this is what you get if you aren't careful hiring a freelancer. This really seems to be the standard approach for most WordPress sites, which to me is horrifying.
Coding is often a process of trying something, breaking things, and then fixing them. Rinse and repeat. If you're doing this on a live production website, your site visitors will see broken pages, weird issue, or sometimes nothing at all. If your site is already getting traffic, working in production is irresponsible, dangerous. Especially if you aren't extremely careful about backups, and aren't extremely proficient.
The only benefit of "no deployment" deployment strategies is that it's cheap -- you're saving the cost of managing a copy of your site, and deploying changes.
Copy site to production
This also seems to be a pretty common way of deploying sites -- simply copy the new site in its entirety to the production server and make it live.
For major upgrades, such as going from Drupal 7 to Drupal 8, or changing from one platform to an entirely different one, this is the main strategy we use. And there are definitely times when this strategy makes sense. However, for day-to-day maintenance, theme refreshes, or most typical deployments, this is not a very good approach.
If your production site has a database, and regular changes to it, you need to be extremely careful to not lose production data. For example, if your site allows user comments, or takes e-commerce orders, or manages sales leads, if you simply copy a new site up you risk losing something.
Save this one for entirely new sites. Don't do this for day to day work -- unless your site doesn't even have a database.
Build site and deploy
"Static site generators" like Gatsby and Jeckyll have become quite popular recently, because they generate static sites that do not have a database -- greatly simplifying security. If you're running a full-blown Content Management System (CMS) like Drupal or WordPress, you're putting an application with bugs on the Internet where anyone can attack it. If your site is just a collection of files, they can't really attack it -- they can attack the hosting environment but your site itself has far less "attack surface" for an attacker to go after.
Gatsby in particular is becoming quite popular as a front-end to Drupal and WordPress -- you write your content in a private CMS on a private LAN, not reachable from the Internet, export the entire site using Gatsby (the build step), and then copy the resulting code up to the web host (much like the previous deployment strategy).
If you use this approach, you still need to consider how to keep your CMS up to date, though if it's not online, updating it in place becomes a far more reasonable proposition.
Now we've reached what we consider to be the "standard" deployment practice -- run 3 copies of your site:
- Dev, or Development -- this copy is where you do the development work, or at least integrate all the various developer copies, and conduct the initial round of testing.
- Stage, or Test -- The main purpose of this copy is to test the deployment process itself, and understand what might break when you roll out to production.
- Production, or Live -- The site that's available to the public.
In general, code flows from dev to production, whereas content/data flows from production to dev. If your site takes orders, collects data using forms, supports ratings/reviews or comments, or does anything sophisticated, you'll probably end up with this deployment strategy.
Several of the more professional hosts, like Pantheon, Acquia, WP Engine, and others provide these 3 environments along with easy ways to deploy code up to prod, and copy data down from prod.
Many larger companies or highly technical startups have built out "continuous integration/continuous deployment" on pipelines along these lines -- including Freelock. "Continuous Integration" basically kicks off automatic tests after code is pushed to a particular branch, and "Continuous Deployment" automates the deployment of code to production when tests have passed.
This is the key service we provide to nearly all our clients -- two different kinds of testing, a fully automatic pipeline, with automatic backups, release scheduling, release note management, and more. And we've build our pipeline to work with a variety of hosts including Pantheon and Acquia but also bare Linux servers at any cloud provider.
The main downsides of this type of deployment is that it can be slow to deploy, very hard to set up, prone to breaking as code and standards evolve, and different platforms have different challenges around deploying configuration changes. For example, when you move a WordPress database to another location, you need to do a string search/replacement in the database to update the URL and the disk location, and you may need to do manual steps after the code gets deployed. Drupal, on the other hand, may put the site in maintenance mode for a few minutes as database updates get applied.
All in all, when done well, this is a great deployment strategy, but can be very expensive to maintain. That's why our service is such a great value -- we do all the hard work of keeping it running smoothly across many dozens of clients, have automated a lot of the hard bits, and streamlined the setup.
If even a minute of downtime costs a significant amount of income, you may want to consider a Blue/Green deployment strategy. This is a strategy made for "high availability" -- doing your utmost to both minimize maintenance windows, and provide a rock-solid roll-back option if something goes awry.
With a Blue/Green deployment strategy, you essentially create two full production environments -- "blue" and "green". One of them is live at any given instance, the other is in standby. When you want to deploy an update, you deploy all the new code and configuration changes to the offline environment, and when it's all ready to go, you simply "promote" it to be the live one. For example, if Blue is live, you deploy everything to Green, possibly using a normal dev/stage/prod deployment process. The configuration changes happen while the green site is offline, so the public never gets a "down for maintenance" message. When it's all ready, you promote Green to live, and Blue becomes the offline standby copy. And if you discover a problem after going live, you simply promote Blue back to live, and Green goes into standby where it can get fixed.
There is a big downside here -- if your site takes orders, or otherwise changes the production database, there's a window where you could lose data, much like the "Copy Site to Production" strategy. You might be able to somewhat mitigate this by setting the live site to "read only" but still available, while you copy the database to the standby site and then apply config and promote. Or you might be able to create a "journal" or log of changes that you replay on the new site after it gets promoted. Or move to a micro-service architecture -- but then you're just moving the problem into individual microservices that still need a deployment strategy.
Which deployment strategy is best?
There is no "best" deployment strategy -- it's all about tradeoffs, and what is most appropriate for a particular site's situation. If you break up your site into multiple pieces, you may end up using multiple strategies -- but each one might be quite a bit simpler than trying to update the whole. On the other hand, that might actually lower availability, as various pieces end up with different maintenance schedules.
If you're running a PHP-based CMS, and you want to rest easy that your site is up-to-date, running correctly, and with a solid recovery plan if something goes wrong, we can help with that!