It’s important to make a splash. The timing of that splash is also important.
In the wake of the election this week, someone at the Romney Campaign accidentally launched a site they had prepared for transition purposes. While the site was quickly taken down, Taegan Goddard was able to grab screenshots.
Yes, someone should be embarrassed at Romney headquarters for this error. We here at Rocket Pop Media go to great lengths to reassure our clients that their new website is launched only when they and the site are definitely ready to make a splash.
How do we do that?
We start with local development. We’re an all-Mac workshop here and we make extensive use of MAMP. If you’re a command-line geek like myself, you can stick with the basic (and free) version of MAMP. If you prefer a little easier time, or need the additional options available in MAMP Pro, the $59.00 price of admission is well worth consideration.
Because we’re a team environment, and multiple developers often work collaboratively on the same project, we do one small thing differently. We don’t make use of the MySQL server installation in MAMP. We use a central database store to ensure that all developers have the same content, plugins, WordPress options, and more. However, with multiple developers comes the need for version control. For that, we turn to Git.
We were already fans of Coda 1 and the introduction of Git controls into Coda 2 made the decision to use Git a little easier (and cheaper). Git allows us to manage multiple workflows quickly and easily. In addition, the ability to quickly branch or rollback allows us to take chances with our development and try new things (knowing that we can quickly backtrack if it turns into a dead-end or we don’t like the outcome).
When it’s time for the client to take a look, we make extensive use of development URLs to allow our client access to dev sites with as little hassle as possible. These sites are online but not in the public domain. This allows the client to check-in on our progress at their leisure, from their offices, and on their time. Meanwhile, our developers are busy behind the scenes continuing to make progress in their local environment without worrying if they’re breaking the client’s preview experience.
This does throw one hiccup into the process, especially with WordPress. With static sites, or even non-CMS dynamic sites, migrating from URL to URL is easy. In fact, most development of that kind is URL agnostic.
However, WordPress is not. In addition to the standard “Site Address” and “WordPress Address” most developers and site managers are familiar with, there are several WordPress options in the database that are URL specific. If the URL and the database option don’t match, the site doesn’t work. Migrating from development URL to live URL used to be a pain. Not so anymore.
We are big fans of Backup Buddy. In addition to making server and URL migration a breeze, Backup Buddy will automate your backup process, including sending the files offsite.
If you don’t need the robustness of Backup Buddy, Daniel Doezema has written an excellent script and tutorial to help you through the process.
Because migration has been made easy, we can deploy quickly and easily to our production environments on a live URL. This means little downtime even if you already have a site. We’ll take it down and, in most cases, less than 10 minutes later you’re back up and operating.
We’ve launched a number of websites and realize the timing of the splash is almost as important as the size. And we go out of our way to get both right.