Have you ever heard the one about the web developer who goes in to make one last change to the site at 4:45PM on a Friday afternoon? It is SUCH an easy fix--he can get it done and go home for the weekend with his head held high. Ah, what a relaxing weekend it will be! Cleaning out the gutters, hiking with the kids, and really just taking some "me time". As it turns out, that plug-in update was not well-architected. As a result, it impacted the structure of the site--and now all of the content is right-justified. WHAT JUST HAPPENED? Okay, this is so clearly a sign that this needs to wait until Monday. Let's just roll back to an archived version. Wait a minute, why haven't we archived in six months?
Now his weekend has to start with a very difficult conversation with his boss, followed by a very difficult conversation with his wife--and the kids for that matter.
Unfortunately, we've all fallen victim to this trap. Yet, there are many times where we all run the gauntlet of making changes in prod, because small changes take forever to run through the dev environment, test, transfer over, retest, send release notes, etc...
In short, making the changes in prod is WAY easier.
Dev Ops as a Service
Confession time: we preach from the gospel of "thou shalt not make changes in prod", however, we have once or twice also drank from the chalice of "thy weekend will be spent recovering thouest website". In our nearly two decades in web development, many camping trips and gutter-cleaning has been "postponed".
That's why Freelock created an ecosystem that makes sure every website in their platform has been updated, is safe and secure, and can be restored with minimal human interaction. In the above scenario, the so-called "Friday Doomdsay Scenario", Freelock's ecosystem would have tested the plug-in upgrade, confirmed it had issues, and not installed the update. Even if the change would have been made in prod, one of the many daily updates could have restored the site in a matter of moments--still time to start the weekend.
The Freelock Dev Ops Ecosystem
The question we often get is "how can you make sure that our site is always safe"? Well, we've put a lot of time, effort, and resources into our ecosystem to make sure that all of the backups, upgrades, changes all happen automatically. Our ecosystem has many components that are all a fail-safe for your company and it's web presence.
Our solution starts with a production environment, a dev environment, and a staging environment. All of these are automatically backed up, and the production environment is checked for changes every night. When there is a change to make to the site, we do it on dev and our bots test it thoroughly before applying it to the live site. We actually do encourage our clients to make CONTENT CHANGES in prod--notice we do not want system or structure changes in prod. Sure, we have a backup if something goes awry, but we would prefer not to have to use those backups.
Automatic Updates from the Staging Environment
One of the many reasons that developers make changes in prod is because they do not want to do them in dev, only to go update them in prod (with testing each time)--it's cumbersome. However, our system replicates the changes from dev to the staging environment for a full screenshot test of every important page. While you are making the changes in the dev environment, it feels like you are working in prod.
Visual Regression Testing
Our solution is so robust that we've even got minions who do our testing for us (read: bots). Our solution will evaluate your prod environment against the staging environment and show any differences in a pixel-by-pixel basis. If the staging environment does not match the dev environment, it means we've got a problem. We'll get that fixed right away.
Automatic Release Notes
Our minions also summarize the change (whether it is a patch, a security update, plug-in updates, or whatever) into an email and sends the release notes for your review as soon as the tests are all approved.
Yes, we backup your site daily. If you require more-frequent changes than that, we can do that. We also backup on multiple environments.
Many of our clients are on similar CMS platforms (Drupal or Wordpress), when there is an update to one of these platforms, our system automatically updates all of the sites in our management plan. If there are any issues (and there sometimes are), we get information from our system where things went wrong--and then we roll up our sleeves.
If you want to run your business, instead of your website--why not use the Freelock Dev Ops as a Service so that you can focus on your business?