Many system and network administrators are responsible for supporting development, QA, and production systems for sites and web based applications. In simplest form the code/app is moved from one to the other as it progresses through the lifecycle. The systems could be located on different networks, are usually housed on different servers, and can even be geographically dispersed. They can also be extremely large with some shops breaking out environments into UAT, regression, and even business process testing as well. This easily produces sprawl across the infrastructure and can make administration difficult at times.

But how do you know which version of the site/app you’re looking at is if you don’t have a way of identifying it? Worst case scenario, you could accidentally change code for a QA site when it really should have been the dev site if you’re not careful. Using different URLs is a typical choice but that can result in wild variations that are just plain ugly, disorganized, and sometimes end up being ridiculously long or making no sense.

Since users depend on DNS to resolve URLs, a great trick to differentiate between these environments is implementing zones to distinguish one from the other. You can create zones for each part of the process, allowing development and other teams to use the same URL for every environment/system, avoiding different and confusing names. This makes things trivial to identify, for example;

Match the URLs on the server side and everything is nice and neat. The possibilities are endless and keeps a tidy, organized, uniform URL scheme across the infrastructure that easily identifies things and takes very little time or effort. You can take this a step further with your database designs on the backend, use Active Directory domains for added features and security, and even match your system names. Granted there are plenty of other ways to accomplish this, but the zone method doesn’t require a lot of work and is visually simple for the end user.