Web Services

Web Services Internal Development Standards

Site Development Procedures

Requesting Access to a Directory

To request access to a directory in order to develop a Web site, go to the WWW Account Application page and fill out the form. It usually takes a few days before access will be granted.

Selecting a Lead Person

Before creating a development space or uploading any files, the individual with primary control over the new site should be selected. On some cases, a single person will be in charge of uploading files to the entire site. In other cases, different individuals will be assigned primary control over different sections of the site. The roles should be explicitly spelled out to all members of the development team.

In all cases, there must be a single individual with primary responsibility to each area of the site. In some cases, one person will have primary control over an entire site with the exception of one area that is controlled by another person.

In cases where multiple people need to upload files to a site or a section of a site, there will have to be a clear understanding of who defers to whom. See the section on Managing File Uploads to Avoid Overwriting for detailed information on how to manage uploading files to a site where multiple developers are involved.

Creating a Development Space

Once you have access to a site, and the lead people have been selected, a development directory should be created for the site. Typically, the development directory will be created by the project's overall lead.

A development directory allows Web Services staff to work on the new site without affecting or altering the existing site.

The Web Services standard is to create a "_dev" directory at the root level of the site for use during development. For example, if the site under development was www.csuchico.edu/inf, then the development directory would be placed at /m3/webdocs/inf/_dev/. All files used in the development of the new site would be placed in this directory.

Top

Managing File Uploads to Avoid Overwriting

Typically, several people may be working simultaneously on a single Web site, updating designs and styles, content, application code, etc. This can cause severe logistical problems resulting in files uploaded by one user being overwritten by files uploaded by someone else.

Applications are available that allow for precise management of complex sites. These programs, called concurrent versioning systems (CVS) prevent users from overwriting each other's information. Unfortunately, we do not currently have a CVS installed on the campus Web server that works with Dreamweaver.

Dreamweaver does have a primitive file check in/check out utility built in, but unfortunately, its limitations make it unsuitable for use by Web Services.

So instead of relying on software to prevent the overwriting of files, Web Services must rely on a simple file uploading etiquette to prevent problems.

The rules are very simple:

  1. A single person must be assigned primary control over each section of a site.
  2. The person with primary control over a particular area may upload files to his/her area freely, without notifying others.
  3. A person who wishes to upload files to an area he/she do not control must follow these steps:
    1. Contact the person with primary control and request that the most current versions of the affected files be uploaded to the site, and let them know which files will be edited and how.
    2. Download these current files to his/her local computer.
    3. Make the desired changes.
    4. Upload the files back to the server.
    5. Notify the person with primary control that the changes have been uploaded, so that he/she can download the new version of the files to his/her local computer.

Top

Going Live

There are a number of steps involved in going live with a new site, and this section merely outlines a few tasks that need to be done in the process.

The client should always be very clearly aware of the exact time that the site is scheduled to change. Transitioning to a new site should never occur until the client has signed off on all elements of the design, structure, and content. Going live with a new site, particularly a high traffic site, should take place during low traffic periods, such as before 8AM and after 5PM. If a site is particularly large and complex, the transition should take place either on weekends or during evening hours.

  1. Move all old site files into an /_old directory on your local computer.
  2. Move all new files into the root directory. Use Dreamweaver to do this, since it will automatically update most file path references.
  3. Make sure to check all path references, including those in include files and JavaScript files to be sure they have been properly updated.
  4. Test the site thoroughly on your local computer to make sure than all includes files, links, scripts, and file references work properly.
  5. Move all old site files into an /_old directory on the Web server.
  6. Upload all new files to the Web server.
  7. Thoroughly test the new site to make sure that all includes files, links, scripts, and file references work properly.
  8. Delete the /_dev folder on the Web server.

Top