Ron Whitman
OK, so you tell your developer you found a problem in your software project and he or she asks, “In ‘what environment’ are you looking at it?” You blink for a few seconds and realize you don’t know what that means.
In nature, an environment is a geographic region that has certain characteristics—weather, plants, animals. Sometimes it’s hot, dry and spacious like a savanna, or sometimes it’s chilly dense temperate woodland like a boreal forest.
As for software, you can install it in different computing environments. Different computers or locations with different configurations of hardware and software installed. And like taking an African elephant and dropping him off in the Chicago suburbs, if you install an application in a new environment, your software is going to behave in ways you don’t expect.
When we’re talking about web software, the typical home environment is the web server it lives on. For an iPhone app, its an iPhone. For a point-of-sale, its attached to a cash register.
Releasing an Elephant Into Your Backyard
Before we release software into the wild, engineers want to test how it will behave in its home environment.
If you’re going to move that elephant to his new home in your backyard, you’re probably going to want to see how he behaves before you let him have the opportunity to destroy your house. If there are any house guests, you’re going to want to present a well-behaved elephant, as opposed to letting them watch him destroy your flower garden and knock down your shed.
For our elephant, we need to train him somewhere safe, and then test out whether he feels comfortable in his tiny living quarters, or goes straight to smashing down the back porch. Only when we’re sure he’s safe, that’s when we put him in the backyard.
Kind of a ridiculous analogy, but you see where I’m going with this. For software, developers typically keep different environments where the software is installed for development and testing before being released. And even after its released, some software can be used in different environments—Mac, Windows, Linux, iPhone, Android etc.
Typical Web Software Environments
Because I’m a web guy, I’m going to break down web software environments that use a web server. For other types of software—such as desktop, mobile apps or embedded systems—testing takes place in simulators, emulators, prototypes or the actual hardware device it’s installed on. It really depends on your team and what they’re working on.
In web software, most engineering teams typically keep at least 3 environments:
“Local” – typically, this refers to a personal web server running on the developer’s personal workstation. Only he can use it or see it. It’s what he works from when writing code. Running the software on a personal laptop or desktop means it’s much faster to see changes, and there is no pressure to make sure it’s working perfectly.
“Staging” – This is the place where a developer can push (“deploy”) a working draft of the software for demonstration or testing purposes. Usually this is as close to the live environment you’re going to get, and the developer tries to replicate the conditions in the wild as accurately as possible.
“Production” – Some folks refer to this as “Live.” This is the site as it comes up when you go to your URL (http://www.mysite.com). When we deploy to Production, this is often called a “software release”—a new version of the software available for public use. Production environments have differing degrees of complication based on the size of your operation. This can be as simple as a tiny slice of a shared web host, or several dozen servers (“nodes”) bouncing traffic all over the web.
Even More Environments
Some teams will have even more complicated setups and workflows with various other testing environments.
“Development” – Often casually called “Dev”. A place where very rough code is shared. It’s very close to the local environment. In some cases, this is used in place of Staging. This is typically where teams can see all the work they’ve done together and test out large or experimental changes.
“QA” – A quality assurance (QA) environment is a safe place for testing. Usually a QA environment is used when there is a dedicated QA team. The goal is to have this environment be as close to Production as possible but isolated so that QA testers can find bugs in peace without tests being disrupted by other users or engineers who may be playing with the Staging environment.
“Integration” – This is an environment where different development teams can see how the software they’re working on works together. Typically this is used in very large organizations with separate components and services, or in cross-team integrations where different companies work together.
“Sandbox” – A sandbox is a little playground where you can do anything you want or to test out how something will work with no expectations of it getting used. Sandbox environments are typically used to demo software features or play around with a product in order to learn how to use it.
Testing and Deployment
Web software development usually involves each of the typical environments at different steps throughout the development process. Developers start coding in the Local environment, push their code for review to the Dev or Staging Environment, have it tested in the QA environment, and when it’s all signed off, deploy the (hopefully) bug-free final release to Production. This helps to ensure that your users never get to see how the sausage is made, yet it gives you some opportunities to train your elephant before he smashes up your backyard.
Hopefully, this gives you a little more insight into what a “software environment” means, and how it’s used. Go forth and be a more dev-savvy person.
(And here’s a bonus tip: if you’re hiring an engineer, ask him or her about testing environments. If the engineer is testing on production, that’s a surefire way to find out if he or she is inexperienced, or cutting corners.)
Any questions? Did I forget to cover something important? Let me know by leaving a comment below.
Ron Whitman