CM Journal Articles Taming a Wild Web Site
|
| In the past few years, website development has been a breeding ground for some Wild West style development tendencies! Heroic cowboys ride in, modify a few lines of HTML or JavaScript or Perl on the live server, and ride off into the sunset with no one else the wiser as to what they did but perhaps just grateful that the immediate problem was sorted (when it didn’t cause others to surface shortly afterwards!). It works for a while, but eventually the townsfolk get tired of their dependency on these individuals and the need for a more stable life grows ever stronger. This article describes a case study where such a wild web site was “civilised” and brought under reasonable control, using a standard branching pattern.
The obvious implication being that there were 22,000 items not under control!  Note that sometimes QA testing can throw up problems which are fixed and then propagated back to Main. Thus we wanted to create the above structure from a starting point of only 8,000 files currently in Main. Detailed Analysis The analysis above shows that we had a lot of files that were not in the repository at all. In fact things were a bit more complicated. We discovered the following types of files: 1 Files on the production server that weren't in the repository at all (22,000) 2. Files on the production server (Live files) that were in the repository, split as follows: a. Live files which were the same as the head revision in the repository b. Live files which were the same as a previous revision in the repository c. Live files with the same name but as a file in the repository but which were not the same as any revision of that file in the repository! There were also some Live files such as configuration files with the names of machines, or IP addresses which needed to be different in the Live environment than from any test environment.  Import Snapshot of Live We took a copy of the live server and imported everything into the snap branch in the repository. Validating Snapshot One of the developers spent some time going through all the files, which were now in the repository, and deleting files that were obviously not in use and had just accreted over the years on the live server. This included files such as *.bak, *.tmp, test_*, etc. It was important to do this after importing so that we could get them back if we made a mistake. Live Files Same As Main For files in Snap which were the same as the head revision of Main we just wanted to branch the file from Main into Test.  In the diagram, Snap#1 is the same as Main#3 so we just branch Main#3 to Test#1 (and there is no direct branching relationship between Main and Snap). In order to do this we needed to find this set of files, and then do the command to create the new branch. This was fairly straightforward with some simple shell scripting and SCM commands. Live Files Not In Main These are files in the snapshot of the live server but not previously in the Main branch (which in our case was nearly 22,000 files -i.e. most of them). We wanted to do 2 things: branch from Snap to Main and then branch those files from Main to Test immediately, to create a clean relationship between the branches Main and Test.  So Snap#1 is branched to become Main#1 which is then branched to become Test#1. This was easy! Live Files Same As Non Head Revision of Main There were about 200 such files that existed in Snap, and for which there was an entry in Main, but the version in Snap was the same as an older revision in Main, rather than the head revision. For example, snap/abc.html#1 was the same as main/abc.html#3 and the head revision was #5.  First we had to find these files (which involved writing a Perl script to compare each of the versions of the Main file, and output which one was the same). Then we had to set up appropriate branching history or relationship between those versions. This branches Test from the appropriate revision of Main -any later changes on Main would be propagated by the normal branch from Main and Test at the appropriate time in the future. Note that in this instance there is no branching relationship between the files in Snap and the corresponding files in Main but the contents of Snap#1, Main#3 and Test#1 are all the same. Live Files Not Same As Any Revision of Main This is similar to the above case, but there were actually no revisions in Main exactly the same as the revision in Snap (discovered by our Perl script). Note that it was important that we actually check the contents of each of these files and decide that this was an appropriate thing to do. This involved a couple of days discussing the detailed list of files with the developers and making sure we understood what had actually happened. In the example below, we overwrote the file in Main with the version from Snap to create #6. We then branch this version to Test, and then "back out" the change on Main, which means take out #5 and check in again as #7.  The result of this step is that the last version we had in Main (before doing anything) would be propagated to Test the next time a propagate/merge was done between the two branches. The Result The result that we wanted was for every file in Snap to be in Test and with every file in Test be branched from a file in Main – and that was tested and achieved. Once we had that in place, we branched everything in Test to Live. We made sure that any new changes to files in Live went from the repository. The actual cutover of the Live server to a workspace copy of the files in Live was a rather careful operation, achieved over a number of days. Working on the cultural issues at this client was as ever another story, which took somewhat more time! Robert Cowham is based in London, UK and works with a variety of companies doing SCM consultancy and training. He can be reached at rhc@vaccaperna.co.uk
Set as favorite
Bookmark
Email this
Hits: 5370 Trackback(0)Comments (0)
|
| Last Updated on Thursday, 13 July 2006 02:44 |
TrackBack URI for this entry
Subscribe to this comment's feed