Explained In 60 Seconds: Basic Development Workflow

The development process is a complex and esoteric one, but by learning a few key terms, you’ll have a much better understanding of how developers work and the stages of their process. In the next sixty seconds, we’ll walk through development environments, or versions of a website that exist in the web development workflow. Every developer follows some version of these steps when putting together code for a website, whether it be something as small as a change to the image styles or something as large as a new feature. Getting familiar with these terms as part of a larger process will help you better communicate with your technical team and follow their workflow.

Local Environment

When a developer wants to update, enhance, or fix a website or part of a website, changes are not made on the version of the site the rest of the world sees. The work is actually done on a private version of the site only the developer can see, one that lives on their computer. This environment is often referred to as the local environment because it exists only in one, limited space. It is on the “local” that a developer can make any change they’d like without worrying about breaking anything on the website permanently. Something important to note: before beginning work on a local environment, most developers will copy a fresh version of the live, public site to their local machine. This ensures they’re working with the most recent code and making changes to the latest iteration of the site. This also subverts the chances that new code will cause something to break, as any additions to the site will be quality assurance (QA) tested against the codebase already present on the live site.

Staging Environment

Once work is completed on the local environment, the developer will push the code into the staging environment. Staging is just what it sounds like -- it’s a testing environment where code can be QA tested without the risk of tampering with the live site. Staging environments sometimes exist on their own servers and almost always require some sort of password to access/view. There are numerous uses and advantages to having a staging environment. This environment is often where most of the testing takes place, either by internal QA or by clients. It serves as an arena where potential bugs can be sorted out and fixed before the final deployment to production.

Production Environment

Production sites are the live sites we see when we surf the web. If you’re reading this, you’re reading it off of OHO’s production site right now. This site is live, or ‘in production’ and therefore visible to any web user. Production sites are final products, but this doesn’t mean they are inflexible or free from work. While development work usually takes place behind the scenes on local and staging environments, oftentimes work will have to be completed directly on Production in order to accurately test a functionality. For instance, if you’re looking to test the ecommerce functionality of your website, you might have to do it on the live version of the site in order to execute a transaction. Because work is often done directly to Production sites, it’s very important to always start new development on a local environment by copying a version of the live site to the local environment. This ensures the most relevant canvas to paint on and the best workflow for bug-free QA and deployment.