Over the course of my evolution as a developer, there is one consistency that has held true for me and saved me from a LOT of heart-ache. That, my friends, is the Development Environment.
“Pssh, we don’t need no stinkin’ development environment! It’s faster to fix things right on production!”
Okay, I will concede… there are three reasons that are excusable, in my eyes, to develop on the production server.
- The problem not reproducible anywhere else, even when you create an exact snapshot of the production server and create an exact copy for a development server.
- The datacenter that holds your development environment exploded and there’s no way to make a snapshot to create a new one.
- More revenue will be lost than your entire annual salary in the additional six minutes it takes to push fixes through several layers of environments for testing purposes. This is questionable.
So, let’s discuss development environments. Your live site (the site that your main domain is pointed to and that people visit) is an environment usually called a “Production Environment.” Ideally, there should be three or more environments for any given development project: Production, Staging, and Development.
Sometimes these environment are also referred to as a “Server” but the concept of “environment” encompasses more than the server itself (which is the physical computer that your site code is stored that is opened to the Internet for retrieval). The environment refers to the type of software and configurations of the software and the amount of people that are allowed at once to view the code and the way the code is set to store to deliver a page faster, etc. There’s many different factors that create an environment.
A “staging” environment is usually used as a way to test EXACTLY what is on the production website OR EXACTLY what is about to be put on the production website. It is a place that is accessible by a series of users who can confirm or deny any changes that are made and identify issues before they are put on your live website.
A “development” environment, however, is king. Without this environment, I would be six times slower and hit issues with connectivity on a daily basis. Why? Because a development environment can be set up on a local computer and does not have to be dependent on an internet connection, necessarily. And in my case, rarely.
In some cases, a development environment cannot be set up locally. Usually, these are situations in which the information is protected by laws such as HIPPA or FERPA and the sensitive information should not be put on individual computers that can be stolen and misused. Or perhaps some proprietary software that requires a limited number of “seats.” Who knows, but in those cases, you can usually get a development environment set up remotely, which DOES require an Internet Connection, but should hopefully also require a VPN connection as well.
This post is for Local Development Environment (LDE). There are three levels of LDEs available:
- I’m a Doctor! Not an Engineer! Or, in this case, developer. This type of environment comes pre-built with little-to-no need for customization. You just click a button to open the server and start typing in your text editor and BAM. Good as Gold.Example: DesktopServer
- I’m the decision-maker here. This type of environment is software that allows for customization of your environment to a limited degree and can be just dangerous enough to screw things up if you’re not sure what goes where. It’s still one solid piece of software that runs everything, but allows for configurations to be changed or plugins to be added in.Examples: WAMP, MAMP, XAMPP
- I’m a total control freak. This type of environment is hand crafted to set up every piece of software required for the environment. This allows for you to make an environment as close to your production environment as possible, but requires advanced knowledge of how the pieces of the environment work and how to not blow things up (digitally, speaking).Examples: Apache, MySQL, PHP, Perl
I tend to use the second type, because I fall between “Ain’t no body got time for that” and deciding things for myself without having to dig into a bunch of hidden configuration files. For my development environment, I use MAMP PRO and tweak the configurations for memory used, number of connections, etc. In addition, I like to pick my own domain names easily, and MAMP PRO allows for this right out of the box.
It should be noted that DesktopServer is for WordPress development ONLY and is built as a layer on top of XAMPP. This is a great solution for people who are purely developing WordPress and use a hosted/managed service such as WPManage because these types of settings are not AS important in these cases. What this means is that it CAN be customized “under-the-hood” by digging through the XAMPP configuration files, but it’s not required and isn’t built into the application itself.
How has this helped me?
The biggest help it provides for me is the fact that it saves time. When you’re logging into a server to do your work, across an Internet connection, you’re generally dealing with a slight lag or delay. So I’ll sometimes type in my commands and watch them fly by several seconds later while the message is getting sent to the server from my screen. Having this happen on a regular basis is F-R-U-S-T-R-A-T-I-N-G! So the fact that there’s no need to hop across a slow Internet connection is the biggest benefit I gain. Secondly, I also gain the ability to program anywhere I am at. No excuses! Unless my excuse is “I’m off” – in which case, don’t touch your computer, because “off-time” is valuable and important. A third reason way that this has helped me is because I am able to experience bugs and issues and keep those types of issues protected from being viewed by everyone else first (and possibly exploited). It’s always better to release tested and scrubbed code into the wild wild webs as a measure of protection against hackers or other Internet Foe.
One useful tip for setting up a development environment is to use some sort of version control system to move the changes from one environment to the next. I use GIT to track all of my changes and put them on my staging environment. Then you can use a website such as DeployHQ or create a service yourself that deploys all of your changes to your production environment.
Image by deviantArtist 0Atropos0 by way of Google Image Search.