Web Servers and Workflow From Testing to Production

Data centre, illustration in huge white room


Working with a large site, with lots of people and pages maintaining it, you will come across various workflows to get from a web design paper prototype to the actual pages live on the internet. The workflow for a complex site can include many separate web servers and server locations. And each of these servers has a different purpose. This article will describe some of the more common servers in a complex website and how they are used.

Production Web Servers

This is the type of web server that most web designers are familiar with. A production server is a web server that hosts web pages and content that is ready for production. In other words, the content on a production web server is live on the internet or is ready to be delivered to the internet.

In a small company, the production server is where all the web pages live. Designers and developers test the pages either on their local machines or in hidden or password-protected areas on the live server. When a page is ready to go live it is simply moved into place on the production server, either by FTP from the local hard drive or by moving the files from the hidden directory to the live directory.

The workflow would be:

  1. The designer builds the site on a local machine.
  2. The designer tests site on a local machine.
  3. The designer uploads the site to a hidden directory on a production server for more testing.
  4. Approved designs are moved into the live (non-hidden) areas of the website.

For a small site, this is a perfectly acceptable workflow. And in fact, you can often see what a small site is doing by looking at files named things like:


And inside directories named things like:


As long as you remember that non-password protected areas like that can be found by search engines, posting updates to the production server is a good way to test new designs in a live environment without needing extra servers.

Testing Server or QA Server

Testing servers are a useful addition to a website workflow because they provide you with a way to test new pages and designs on a web server that is not visible to customers (and competitors). Testing servers are set up to be identical to the live site and usually have some sort of version control setup on them to make sure that any changes are recorded. Most testing servers are set up behind a corporate firewall so that only employees can see them. But they can also be set up with password protection outside a firewall.

A testing server is very useful for sites that use a lot of dynamic content, programming, or CGIs. This is because unless you have a server and database set up on your local computer, it is very difficult to test these pages offline. With a testing server, you can post your changes to the site and then see if the programs, scripts, or database still works as you intended.

Companies that have a testing server typically add it to the workflow like this:

  1. The designer builds the site locally and tests locally, just like above.
  2. The designer or developer uploads changes to the testing server to test dynamic elements (PHP or other server-side scripts, CGI, and Ajax).
  3. Approved designs are moved to the production server.

Development Servers

Development servers are very useful for sites that have a large development component, such as complex e-commerce sites and web applications. Development servers are used by the web development team to work on programming the back end of the website. They almost always have version or source code control systems for multiple team members to use and they provide a server environment for testing new scripts and programs.

A development server is different from a testing server because most developers work directly on the server. The purpose of this server is typically to try new things in programs. While testing does happen on a development server, it is for the purpose of making a piece of code work, not testing it against specific criteria. This allows developers to worry about the nuts and bolts of the website without worrying about how it's going to look.

When a company has a development server, they often have separate teams working on design and development. When this is the case, the testing server becomes even more important, as that is where the designs meet with the developed scripts. The workflow with a development server is typically:

  1. The designers work on the designs on their local machines.
    1. At the same time, developers work on scripts and programs on the development server.
  2. The code and designs are merged onto the testing server for testing.
  3. Approved designs and code are moved to the production server.

Content Server

For sites with a lot of content, there may be another server that houses the content management system. This allows the content developers a place to add their content without it being affected by the design or programs being built alongside. Content servers are a lot like development servers except for writers and graphic artists.

Staging Server

A staging server is often the last stop for a website before it is put into production. Staging servers are designed to be as much like production as possible. So, the hardware and software are often mirrored for the staging and production web servers. Many companies use a testing server as a staging server, but if the site is extremely complex, a staging server gives designers and developers one last chance to verify that proposed changes work as designed and don't have a negative impact to the site overall, without having other tests being performed on the testing server causing confusion.

Staging servers are often used as a form of "waiting period" for website changes. At some companies, the staging server deploys new content posted there automatically, while other companies use the server as a final testing and approval area for people outside the web team like management, marketing, and affected groups. The staging server is typically put in the workflow like this:

  1. The designers work on the designs on their local machines or the testing server.
    1. Content authors create the content in the CMS.
    2. Developers write code on the development server.
  2. Design and code are brought together on the testing server for testing (sometimes content is included here, but it is often validated in the CMS outside of the design workflow).
  3. Content is added to the designs and code on the staging server.
  4. Final approvals are received and the entire site is pushed to the production server.

Your Company's Workflow May Be Different

One thing we have learned is that the workflow at one company may be completely different from that at another company. We have built websites writing HTML straight on the production server using Emacs and vi and we have built websites where we have had no access to anything but a small section of the page we're working on and we did all our work inside a CMS. By understanding the purpose of the various servers you might come across, you can do your design and development work more effectively.