Recently, I needed to make some changes to an older application that was created before I joined the team. I set out to find the most recent version of the source for this application. The team, at the time the application was built, used a combination of Visual Source Safe and backing up copies of the source (not the source database) to both a share on the network and also an external hard drive that was hanging off one of the developers' workstations. I first checked the backups on the hard drive and found 20 copies of the source there. Apparently, most all the copies had been moved at the same time because the time stamps on the files were identical. Some of the folders had dates in the names, but had sub-folders with multiple versions in them. In checking the share, I found basically the same thing. Next, I checked VSS and found the source checked out by an employee no longer with the company and that about 5 months of bug fixes had been made without checking the code back in.
So, after the shiver went down my spine, I went about trying to decide how I was going to handle the fact that I had a version running in production that was about 5 months newer than the latest version of source code I could find. Not a pretty situation...
This experience just underscores the value of having and using an automated build system and a process that keeps it a central part of the overall approach to things. With a build server in place, the release versions are generated FROM source control. So, unless you lose your repository, it's impossible to deploy a version that isn't in the source database.
I found another problem with the source, as well. It depended on several third party controls. Apparently, the controls had been installed on the developer's computer and references from the project to the third party assemblies had been made to the installed location. What this meant for me was that after I had obtained the source code, I had to go hunting for the assemblies (there were multiple versions involved) in order to get the references corrected so the project would even compile. This makes getting set up to modify an existing application a long and arduous task. Then, too, the controls have to be installed on your build server in exactly the same location as on the development box or your builds will fail, as well.
Instead of doing it that way, try creating a folder, in your project, that contains all the third part assemblies required by the application. If you like, you can even subdivide them by vendor, purpose, or whatever in sub folders beneath. Then, set all your references to the assemblies in those folders. Make sure, too, that these assemblies get checked into source control along with your source code.
Now, when a new developer goes to check out the code to work on it, all the dependencies are there, working, and a clean compile is only a click away. Same goes for the build server. You won't have to worry about installing the dependencies there, at all.
Subscribe