The new sub-site development infrastructure brings a full featured, professional web development environment to the CIS department.
Sometimes our robust personal web development environment is somewhat unsuitable for certain project needs. Examples of project needs we hope to fulfill with the sub-site development infrastructure are:
Persistence - Often personal web spaces are inappropriate for projects because the projects will last longer than an individual's tenure in our department.
Technology - When a department project's needs grow beyond the capabilities of our fully managed hosting environment, it may be appropriate to create a sub-site for the project.
Examples of projects that currently fall into this category are the SAnToS research group and the ACM student chapter.
- Version control (Subversion).
- Automated deployment.
- Robust support for development teams.
The following technologies are fully supported.
- PHP (suphp)
- CGI Python
- CGI Perl
The following technologies will never be supported through the sub-site infrastructure.
The Development Cycle
In order to provide guidance on utilizing the new sub-site infrastructure, our documentation is organized based on the workflow for a development cycle.
The initial environment for a sub-site is that of the G-Forge based project and the associated subversion repository. An initial checkout of the (mostly empty) repository will show two branches already created: trunk and live. The directory structure follows:
The two branches are very important to your workflow. Your active development and testing will all initially take place in the trunk branch. When your active development reaches a stable point that you wish to update your web site with, you will then merge the trunk branch with the live branch. The live branch is then automatically synchronized with your sub-site on the web server during the next scheduled synchronization.
This section is dependent upon the G-Forge software and is not yet finished
You can build your team by giving users access to various portions of your G-Forge project. Most importantly, those users with "commit" access to the live branch of your repository will be considered full privileged collaborators by the system staff.
Your primary development cycle takes place in a local working copy of the repository that you check out to a local development environment. While a local, fully configured web environment is best, you may find that the easiest way for you to test and develop your web project is by checking out a working copy to your personal web space located in the public_html directory in your home directory. You can then continue your cycle of coding, testing, and debugging until you are ready to commit your changes back into the trunk of your repository.
The version control system has mechanisms for handling parallel development by all members of your team on the same branch.
To deploy a version of your sub-site to the web server, email firstname.lastname@example.org or email@example.com and we will perform a merge between the most stable version of your trunk branch into the live branch of the repository.
Maintenance of your project may be a bit more complicated than you are familiar with. If you have a very small correction to make, you may feel the urge to just fix the live branch. Resist this temptation. Instead, update your trunk branch with the necessary fix and then merge the trunk into the live branch again. This will insure that you will not "regress" by reintroducing the problem into the live branch when you merge the unfixed trunk branch at a later date.
If making a quick fix to the trunk branch poses too much difficulty, then at least be sure to apply the fix to both the live and trunk branches before committing.
Example uses the acm subsite for the project, replace with your project name.
Check out a copy
cd public_html svn co file:///common/admin/svnroot/acm/trunk acm
This will make an "acm" directory in your personal web space that will be your working copy (where you will make all of your changes) and allow you to test your changes using a URI like: http://people.cis.ksu.edu/~jamason/acm/htdocs
svn up (make any changes and do all you're testing) svn up svn ci email support
The first and third commands will update your working copy with any updates that any of the other editors have made. You want to do this before you start working on new changes and before you commit your changes. Obviously, between these two steps you would edit the pages just as you would normally, using whatever app you prefer. The fourth command will commit your changes, updating the repository with all of the changes you've made in your working copy. When you do this it should open up an editor with a list of the changes. In this file you should (before the horizontal line) add a message briefly describing the changes made. "Added the fall 2007 lan party gallery" or "Fixed a bug in the CSS" would be sufficient messages. The last step is for you to just send an update to firstname.lastname@example.org or email@example.com and let us know that you guys have committed changes and are ready to update the live copy.
Whenever you want to remove or add files, you need to do so through subversion. So to add a file called, header.jpg, first you'd put it where it needs to go, then you need to run:
svn add header.jpg
And this will make sure that the file is added to the repository correctly. Similarly, you can remove files with:
svn del header.jpg
If you've forgotten what's been changed or whether you added files correctly, use the 'svn status' command. This will list everything that's been change in your working copy. If you want to actually list the contents that have changed, you can use 'svn diff'.
For additional information, read the handbook for svn at: