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


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

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

if ( length($comment) == 0 ) {
print STDERR "A comment is required!";
elsif ( length($comment) < $minchars ) {
print STDERR "Comment must be at least $minchars characters.";
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);

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 ="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


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!!!

Sunday, February 15, 2009

Confused Agile

Going Agile - the CMMI something way!!!

Well we all know Scrum is on a roll and more projects are adopting it. But I saw something recently that was like a full course of lot of recipes for disaster. I am talking of a place that over the years has matured itself on 'goliath-weight' (heavyweight would be light for it) processes defined, documented, version controlled over a huge repository, process with thousands of forms if not millions. Going by that as a developer I had to fill up more 'lines in form' than the 'lines of code' I could write.

Well to start with, I had to come up a project plan - accepted. Then the crazy run began. I got questions from the quality guy. What about QA, why not code reviews? Where is defect prevention metrics? And the list of those long scary names went on while I was just numb thinking 'what the *uck?'

I then saw a well, 'document' which defined the 'Scrum Process' to be used by projects in the organization, defining how 'every project will do scrum, execute sprint. Poof!!!! Goes the Scrum.... May be I am wrong here but from what I have learnt, Scrum is a 'framework' and has to be adapted to every single project’s needs. But, I see the same problem of not letting go of the old and grabbing for the new as the root here.

But a few things that I think can address their concerns and still keep Scrum Agile.

There is no use writing review forms and quality docs and expecting developers to follow it. Well, face the truth; WE don’t really care about all that. Not that we least bothered about anything else than checking in pieces of rubbish and running back home, the processes are so not like what I wanted to do in life. How about realizing that their are tools that can keep doing such things which you document in quality docs. Using Checkstyle and Cobertura can help; fail the build if code checked in does not pass the check, or line and branch coverage drops below say 85%. 

Many more things like this can help. You can have a document explaining what scrum is; its key-points etc. but for me documenting a Scrum process to be followed by all projects in your organization is what I call Confused Agile.