Monday, June 22, 2009

About hooks and cute scripts

This one stands as the the real stress buster in terms of cutting down the amount of work not needed to be done by me now that it is in place.

Here's how I reduced the time taken in giving long code walk through to my colleagues handling maintenance of the same system you do development for after you are done with what all you want to release.

Get a pre-commit hook to your source versioning repository to ensure every check-in has a story or defect ID(We use Rally and subversion), but this can work largely for other similar systems as well. Not really written by me but I took an existing Perl based one and modified a bit to suite my needs


#!/usr/bin/perl

# config section
$minchars = 4;
$svnlook = '/usr/bin/svnlook';

#--------------------------------------------
$repos = $ARGV[0];
$txn = $ARGV[1];
$comment = `$svnlook log -t "$txn" "$repos"`;
chomp($comment);

if ( length($comment) == 0 ) {
print STDERR "A comment is required!";
exit(1);
}
elsif ( length($comment) < $minchars ) {
print STDERR "Comment must be at least $minchars characters.";
exit(1);
}
elsif ($comment !~ m/^S\d{4,}.*/ && $comment !~ m/^DE\d{4,}.*/ $comment !~ m/^Tech.*/){
print STDERR "Comment must have Rally Story Id,Defect Id or Tech as prefix."; exit(1);
}
exit(0);


and then you can use this sweet little thing written by one of my developer colleagues to get a complete history of what in the code base changed how many revisions for a story or defect.


#!/usr/bin/env ruby

branch_path = ARGV[0]
start_date = ARGV[1]
end_date = ARGV[2]
search_string = ARGV[3]

file = File.new("svn_logs_#{start_date}-#{end_date}_[#{search_string}].log", "w")
revision_separator = "------------------------------------------------------------------------"
commit_log = `svn log #{branch_path} --verbose -r {#{start_date}}:{#{end_date}} --incremental`

file.puts "Branch path: #{branch_path}"
file.puts "Start date: #{start_date}"
file.puts "End date: #{end_date}"
file.puts "Search string: #{search_string}"

for revision_log in commit_log.split(revision_separator)
if revision_log.downcase.include? search_string.downcase
file.puts revision_separator
file.puts revision_log
end
end

file.close()


The good part is that while I might be presenting the release features which always takes it's own good time, I do not have to go through long sessions of browsing code and explaining where is what to the other guys as that info is in these change logs which they can use to see it for themselves.

Tuesday, June 9, 2009

eXtreme on the Roll

Not something I have done but I plan to if they give me time, because this isn't something that I can wrap in business value terms;-) to make the customers understand but my view is when it falls in place it will speak for it self.

Over the past months I have been working on adding Selenium RC based tests that can run through the site ( we have well a mix and mash of JQuery, Velcoity, XHTML, and DWR in logic that belts out pages, or well page regions), automated load test scripts running on a combination of ruby, ant and JMeter, and tweaking deploy scripts to use the dynamics that good Mr. Hudson can provide all in an attempt to ease out things for me and cut down time taken in a release.

So, we have three weeks sprint, and here's what I think is worth wasting hours on

1)Check before you commit - (stop the production line types)
I don't like code reviews , and nor do I trust myself doing it seriously for anyone
Now just in case you are thinking of what happens to code quality? I add checkstyle/PMD config in all my developers' eclipse and block a checkin if there is a coding error or coding style error.

2)Keep Deploying
It does not stop at it: each build is followed by the deploy, and each deploy is to be followed a whole suite of automated functional/regression tests and then automated load tests(thanks again to Selenium and JMeter). the idea is that I should be the first one to know when the site starts cranking due that new story I did (better than anyone else finding it out a few weeks later)

3)Tests, more tests and even more tests
not just unit tests here; I go by the philosophy that you should have a test written also for that new feature/functionality/layout change on the site. (I stumbled upon JSUnit so you can test first Java Scripts as well and keep adding to the test base) befoe you change a feature on the presentation tier, and run all of those as a suite which is 'reliable'.

4)Do you need a release cycle then?
I can just pick it up from my maven repo and deploy it to production. If not production at-least integration and leave it to the releavnt owner of enviroment beyond to follow their processes , but yeah, I might be throwing in another one to integration before they manage taking the first one to production :-).

Om tatsat!!!