I get asked by developers about my own, personal development environment. I revel in the joyous moment when I get to tell them I don’t have one. At least I don’t have a staged server on my computer that I’ve set up to build out each project.
The truth is, each project is very different and my own specialities I have developed require me to develop each staging or development environment on a per project basis. Sounds like a lot of work, doesn’t it? Well, you’re wrong. It just takes me a few minutes to set up whatever environment I need.
I’m sure other developers will have their own techniques and methods. So take this as one version and go out there and build what works for you.
What is a Development Environment?
A development environment can be anything from a local Apache server running on your local machine where you install WordPress to a full-blown integrated development environment (IDE) where scores of developers maintain, manage, and check-in code for review.
I use a development environment for more complex projects. My most complex projects start on a local machine environment and get migrated as soon as possible to a web-based development environement. I STRONGLY prefer developing on the exact same server where my client’s site will be hosted because I can’t possibly replicate that on my machine.
What is a Staging Environment?
A staging environment is what I use when I’m developing for a site that is already live and running. I make the distinction between a staging and development environment because staging is what I do to show how my work will look different than the current product.
To help draw the contrasts out, here are two scenarios:
- A client needs a completely new site with a host of custom features – I would use a development environment to develop the product.
- A client needs me to add some functionality or redesign a current site – I would use a staging environment that mirrors the current site content.
I usually stage the project on one of my own sites. This allows me to control the code and content. Once the client has approved the staged version of their site, I’ll migrate my work over to their site.
Local Machine vs. Hosted
To each their own. You may want to always develop on a local machine and demo your work via screen sharing. I like having my project online either on a dev.domain.com or my own site.
Local machine hosting has one, really big advantage: speed. You don’t have to upload the code – just save it and refresh the screen.
In my own experience I have run into problems with migrating code I developed on a local machine to a hosted environment. I can’t reproduce the exact server configuration on my machine. And it would take a LOT longer to do that anyway.
For really complex projects that require a MASSIVE amount of custom PHP, I will take the time to set up a local server and build it out on my computer first. But that’s fairly rare. I’d usually rather just have the code hosted in the same environment where it will be functioning, but that’s just how I roll. You can roll how you like.
Developing a Process
The real key is to have a formal process in place. And by formal, I mean mostly informal – just do the same thing every time so you don’t have to go set everything up. I have a couple of tools that I’ll share in a separate article that I reach for all the time.
For small projects, my process is typically
- Install WordPress on my site or a sub-domain of my client’s site
- Copy the current WP database (if they have one) and load it in my stage/dev environement
- Start working…
For larger projects, I might start off on a local machine version, but pretty quickly I’ll have it on the hosted environment.
For the largest of projects, I typically work with a team where they have a repository of code that goes through a review process. Sometimes I’m in charge of code review and managing multiple projects and sometimes I just have a small piece of the larger picture that I’m working on.
Why is a Staging/Development Environment Important?
If you’ve developed anything at all on WordPress, you’ve experienced one of those site-killing warning messages. It’s usually because you have an extra bracket or misplaced comma. It happens. But that should NEVER happen on a site that is live.
That’s why we have a development or staging environment. You should never, ever add code to your site while it’s live. Make changes and test those changes in a development environment. Work through the details and any debugging. THEN you can migrate your code.
Even when working with a plugin, you should stick with the staging/development environement before changing code. Most plugins will simply get deactivated by WordPress if they kick out errors. Sometimes you’ll just get an error message at the top of the site. Still, the whole process can be avoided with a dev environment.
I recently worked on a project as a member of a development team. The contract was managed by a large organization. The end client had a clause in their contract that for every second the site was down, they were penalized in the thousands of dollars (USD) – per second!
Working in a staging/development environment is a differentiator. Tell your clients that you work with this process and why it’s important. Show them how you’re protecting them with this higher standard of care. Many quick-start developers don’t take the time to do this and they break stuff. But if you have a dev environment, you’re going to know way ahead of time if something doesn’t work.
Don’t be a lazy-ass developer (LAD). As I’ll show you in an upcoming post, setting up a dev site or staging environment can literally take a few minutes, whether on your machine or online.
The post Development & Staging Part 1: What and Why? appeared first on YinPress.