Something that struck me about the latest hwdMediaShare v2 release is how many people jumped to upgrade their good old hwdMediaShare v1 to the shiny new version on their live sites. In some cases the process didn't result as expected, as it usually happens with this major version bumps, and resulted in frustrated users and heads banging against the wall.

While I understand the excitement of having your hwdMediaShare supercharged, the pessimistic in me frowns on the idea of doing in on my live sites without having tested them extensively before on my staging environment. That made think about the reasons why so many experienced professionals make the mistake of doing changes on their live sites without testing them first, and, in some cases, without having a plan to roll back if things go south.

Some of the reasons that came to my mind are:

  • Blind faith on the HWD software.
  • Time pressure/Procrastination/Adrenaline junkie.
  • Difficulty to set up a proper staging environment.

While I can't do much about the first two ones, in the rest of the article and following ones I'll propose a streamlined workflow to make the setup of test environments easier by using LAMP VMs configured to make the latest Joomla and hwdMediaShare work out of the box, including the required media conversion requirements.

Being a Die-Hard Linux user on my desktop, I'm not a stranger to the pain my coworkers suffer when trying to set up a web development environment from scratch on their Windows or MacOSX computers trying to match the environment used on the live server, which usually runs some flavour of Linux (go figure!)

Some of the issues they face are:

  • Software that is difficult to install or manage.
  • Some required tools might not be available on the Windows world (that's less bad on MacOSX thanks to the homebrew project, but still not ideal).
  • Although PHP has matured a lot in the recent years, it's still common to find scripts that work funny on Windows computers, for instance because of the different folder separator (C://)
  • The process of setting the environment is usually manual and time-consuming, and, in the worst case, non reproducible.
  • Need to work on project A that requires PHP 5.3, but project B requires PHP 5.5? Good luck!

One effective solution to these nuisances is to leverage Virtual Machines (VMs), either local or remote, for each of the projects we're working on. This offers several advantages:

  • Easy to roll-up, as VMs are created from a template.
  • VMs can be configured exactly to the production environment. No more "but it works on my computer :("
  • VMs are isolated, so can run different versions of the software without conflicting.
  • VM are easy to share with customers and coworkers.
  • It's configuration can be scripted to keep up with new requirements.
  • Disposable.

On the other hand VMs might have some rough edges too:

  • Need to mess with complex virtualization software or APIs
  • We'll usually deal with Linux VMs, what might look daunting at first.

In the next article we'll roll up our sleeves and see how to use some cool tools like VagrantChef and Git to easily spin and manage hwdMediaShare Linux VM like a Pro.