In need of version control
A friend of mine, that I’ll keep anonymous, asked me to help her with an ASP page that didn’t work.
The changes she made wasn’t visible when she ran the script on the server. I got most of it running on my local machine and thought there should be no problem running it on the production server.
A couple of hours later the ASP file contained nothing but plain HTML and it still wasn’t working. By this time she was convinced the web server was serving an old file to visitors.
(No it wasn’t a caching issue.)
I didn’t hear from her in about two hour until she told me the issue was solved. Clearly a bit ashamed she told me she had an intern working for her. They had been working on the same file and none of them had a development server, so they were both uploading their versions of the same file to the server.
Not considering the lack of coordination and development environments, they definitively would have been better off using version control.
No history to Subversion
I’ve been involved in a couple of projects where SourceSafe was kicked out.
In most cases there were long discussions on how to handle the history in SourceSafe.
Most developers seems to manage without migrating the history, but there has always been a vocal minority that desperately want to have the history migrated.
When dealing with this it has struck me that every project that was in favor of migrating the history also was missing decent release practices.
The loudest arguments are usually that they often need to check what changed between two old versions when bugs are triaged. There are usually two reasons for this. The first is that someone has to be blamed for the error. The other is that they don’t really know when the feature was released in the first place.
My recommendation usually is to set up a working release management structure before migrating the source code to a new repository. Especially if the SourceSafe repository hasn’t crashed yet.
As far as I know there is no tool that can recreate the SourceSafe history in Subversion or Team Foundation Server for all edge cases. Especially since the notion of sharing doesn’t exist in SVN or TFS.
If you know of a good tool to get the history out of a SourceSafe repository please let me know.
A formal build-and-deploy process becomes essential.
I’m reading Pro BizTalk 2006
The author thinks it is a disadvantage that: ‘A formal build-and-deploy process becomes essential.‘
WTF; in an organization big enough to think about, and afford, BizTalk I would say that a formal build-and-deploy process is a prerequisite. Since BizTalk is a lot, if not all, about integrating different systems and organizations having a strict configuration management is essential to keep the cost down and the quality up.
It is a nightmare to find, and correct, errors that exists because there is version inconsistency between the partners in an integration project. I find that having a formal build-and-deploy process is almost essential even for a small one man project. I’d even say it’s more important the more infrequent there is work done on a small project.
On a software project, of any kind, there has to be a formal build-and-deploy process in place as soon as there is artifacts to be delivered from a developer.
Old PC working again
I’ve got the old PC up and running again. It was no easy quest to find a matching motherboard for an ancient computer. I ended up buying a used board.
The current plan is to run it as a file- and svn-server mainly, but I had to keep running XP so the kids can do their stuff on it. I will probably have the svn repository on the system disk and back it up daily to the other disk. I will also make some kind of offsite backup of critical data, like source code and pictures. My free 2GB account at Diino will definitively be enough for the source code. I might even be able to ftp it to my web host. All pictures are a different story. I think I’ve got over 2GB already. On the other hand; I am thinking of moving my web site to Dreamhost and they offer a lot of space for their hosting plans.
I haven’t finally decided if I should run Subversion my self. If I go to Dreamhost I can use svn there, but then it will be unavailable when my crappy internet connection drops. It will be available when I’m not at home though, and I wont have to keep my box running all the time. That will probably save me a lot of money per year.
If only people could click more on my ads so that my internet activities become self financing. I’ve got a donation button if someone feels like helping me move to Dreamhost.
No SVN, bummer
I’m using OpenSVN to manage the source code to some of my projects, but it has been down for a couple of days now. That is a real pain. IT is (was) a free service so have expected that it would shut down eventually.
I don’t have a computer that I can run SVN on. I do all my programming on the same machine so I could possibly run SVN or (evil thought) SourceSafe on that and use Diino for external backup. But I am a bit to lazy to set up backup routines ad manage the SVN server.
The SVN host I have seen online are a bit to expensive for me. I’d gladly use a cheap one with a low up time guarantee, as long as they make some kind of guarantee.
Hmm, maybe it would be possible to sign up as a reseller for one of the big server farms and sell hosted SVN.
(Just two seconds after I posted this OpenSVN was up again but I really have to get something a little more reliable.)
Check your automatic builds frequently
Make sure your automatic, daily and continuous, build actually works.
It is just like checking that your backup procedures actually works. You do not want to find out either one of those is not working when you really need them.
This weekend our Team Foundation Server was moved and everything looked all right on Monday morning. There was no problem at all to connect to the new server and the Cruise Control Tray icon was a comforting green. I did have that uncomfortable feeling that something was wrong though…
… and sure enough; the configuration for Cruise Control wasn’t changed so it looked at the old server and kept on building the same old stuff.
Broken builds sucks and it should be a cooperative effort to keep the system in a buildable state, but there has to someone responsible for the automation. Someone who verifies the build frequently.
Continuous builds instead of meetings.
Lots of times I have been involved in lengthy discussions about how to solve a problem and trying to guess what the user really wanted based on his initial request. It is not uncommon that implementing all of the possible solutions and lettings the user choose the one that satisfies his needs would have been done in a shorter amount of time than discussing it.
I’m probably rambling but if we have a continuous build, that is releasable, we could in many of these cases give the customer builds with all of the solutions and let the customer decide.
I have heard of development teams that has taken deliverable builds to such an extreme that they build Virtual PC images with their system preinstalled every night. So even if there is server software involved it is possible to create agile deliveries.
Installable daily builds and salesmen
I have quite often ended up in situations where the salesman has promised new or existing customer non-existing functions. Functions that took lots of overtime and ugly code to get done. When developers, more or less loudly, protests against this practice they are either laughed off or told they don’t understand the sales process.
Quite often these forced solutions are not tested enough so the client isn’t satisfied anyway.
Assuming you took my previous advice and created releasable daily builds, I suggest you deliver what you have at the moment and update with new functionality as it is done. With shorter iterations everyone involved gets a feeling of success. This will probably not work for all kinds of systems but I think that generally it is not devastating if you (re-)introduce a bug that a large regression test would have found. The risk is quite big that a suite of test that are run a couple of times a year will find less than an ever growing suite of tests that are run every day. Furthermore, the receiver knows it it non-critical since there a new deliveries soon.
I don’t think you should be afraid to deliver often. One way of removing that fear is to have a well organized automatic test suite and build environment.
OpenSVN; A free SVN repository
Edit 2012-01-17:
OpenSVN seems to be down.
I moved to xp-dev.com a couple of months ago. They have a free plan that works like a charm.
This was a plug for OpenSVN a free subversion repository.
I use it for keeping my university work so I can reach it from all my computers and revert to old version of reports and source code.
Sourceforge also uses subversion, but I guess my school work doesn’t really apply as an open source project. I have logview4net hosted there though.
Broken builds
Nightly builds are almost useless if there is no collective responsibility to keep the code in a buildable state.
Why should I even bother to make sure my code builds before checking in, when the build has been broken for a week and no one, who can/should do anything about it, cares?
Is it the responsibility of the ones who do care to be a PITA, or should we take it upon our selfs to fix all error just because we care?
