ArtsAutosBooksBusinessEducationEntertainmentFamilyFashionFoodGamesGenderHealthHolidaysHomeHubPagesPersonal FinancePetsPoliticsReligionSportsTechnologyTravel

Web application deployment with CVS

Updated on September 28, 2008

CVS is a popular version control system widely used by programmers around the world. With CVS, many programmers can work on the same project without having to manage who works in which files by themselves. Concurrent modifications in the same files are allowed and CVS merges the changes into the main version of the file. This feature avoid you having to redo an entire day of work simply because another person changed the same file.

Although version control systems are popular, it's frequently used strictly in the coding process. This leaves processes such as testing and deployment unattended, and organization create a parallel work flow for managing this processes.

This text is intended for showing the process, but some CVS knowledge are required, as CVS concepts and commands will not be widely explained, just cited.

CVS for deployment – when it applies?

CVS does not control automated building, unit testing or such. In a specific case, this is no problem. CVS can be used for deployment when:

  • The language used is an interpreted one. So, there is no need for compiling code.
  • The application in question is a web application. In this case, you have control over the environment your application will be run (once it's your own web server).
  • And of course, your server runs a platform capable of running CVS.

Unit tests (if you're using them) have to be into the repository, managed as any other file in the project. This is important, as their versions have to be in sync with the components being tested.

Spend some time doing the first installation with this process, even if it seems to be more complicated than simply upload all files using FTP. You'll see, the updates will be much more simply than that, and the control you get over which customer runs which version compensate the effort.

Preparing the environment

You will need to have SSH access on your web server and your CVS server needs to be accessible by it. If your CVS server is the same machine or is internet accessible you will not have problems. If it's installed inside your Intranet you may have an extra work, but is possible. Ask you system administrator (if not you) to establish a VPN between your web server and the internal CVS server. In this case they'll be visible to each other by its VPN-assigned IP address, not the public or the Intranet ones.

Once this requirements are met, all you have to do to install your application in the server is to checkout the module on the destination folder, as you would do on a development machine. After you do that, files will be transferred, but they'll have versions, and not simply exists. It will be specially useful when it's needed to update the whole application.

Controlling versions independently

What I have described in the previous section was needed for advanced version control, but alone you'll see it's almost useless. That's because you did a checkout of the whole module, but you did it in the main (trunk) version. It means that in any moment you can update it and get development version of that files, possibly not well tested or defective.

First thing you got to do is close well tested versions, meant for installation on production servers and then branch them. When you make a branch in CVS, you can work independently on this version, leaving alone the main version and vice versa. Then, you checkout or update the module on the server, but this time, specifying a branch. This will allow to check in files continuously into the main version and leave you installed versions intact. In the case of a bug, you can fix the branch version, update clients and leave trunk intact. Or even merge with to avoid duplicated work.

Install and update cycle

Suppose you have a test_app module you want to install on your web server. If you have the environment ready, you can:

  • Once you think the development version is OK, test it. If it's working well, make a branch. You can give any name, such as a date, version number that makes sense to you, or even any arbitrary name. But give a name that can help you identify in the future what is in the version. A branch can be created using cvs tag -b BRANCH command, being BRANCH your desired branch name.
  • Now you create the branch, you have an identical version of the module, but tagged with the version name you chose. If you did not make the checkout process on the server, do it specifying the branch. If you already did it, do an update. On the same way, you have to specify the branch. A branch can be specified in checkout or update using the -t parameter.
  • Continue to develop and integrate files into CVS. Note that even after you check in files into the main trunk, updates in the server (which is using the branch version) will not change any files.
  • When you want to update your module again, all you have to do is repeat the process. Make a new branch, update on server, keep developing on trunk.

Bug fixes in branch versions

A bug always can be found in a version that is already tested and on production. In that case, you may not want (most of the cases you'll not want) to fix the bug in the main version and do a full upgrade, as it can be slow and can lead to more bugs.

When it occurs, all you have to do is fix the bug on the trunk version, commit and then update on the server.

  • Checkout the files you have to change using the parameter -t BRANCH to inform CVS that you want that file on the version of the branch BRANCH. If you prefer, checkout the entire project on a separate directory, always specifying the branch.
  • Change it, and once tested and working, do a commit. The commit will affect only the branch.
  • Do a cvs update on the server. Your changes will be copied from the CVS server.
  • If the bug occurs on the main version, you can replicate the changes into the trunk. On a trunk version directory, run a cvs command -j BRANCH. It will merge changes from the branch into the files. Note that it will affect only your local files; you still have to check them in to put it in the repository.

Managing multiple installations on the same server

CVS stores the version information on files located into sub folders named (surprise!) CVS. Each folder managed by CVS have this sub folder, which some files inside it. This simplicity makes each directory not dependent on any system-wide file, or so.

That way, all you have to do to run multiple versions is to have each one in a different folder on server. Just take care not to share the same database configuration or any other sensitive information that have to be different between installations of the same application.


    0 of 8192 characters used
    Post Comment

    • dougmcunha profile image

      dougmcunha 7 years ago

      The method proposed in the article can also be applied to other version control systems, like SVN. You can use this approach in any version control system that supports tagging and branching.

    • profile image

      Brijendra Kumar soni 7 years ago

      CVS web is an very good application for project and file managemnt(Histort,tag,commit,checkout etc..)

    • manoharsinghbisht profile image

      manoharsinghbisht 8 years ago

      Good article..Using CVS, you can record the history of sources files, and documents. It fills a similar role to the free software RCS, PRCS, and Aegis packages.

    • profile image

      Anthony Damasco 9 years ago

      very helpful - thanks, - ill give it a shot