Be a Go Getter

One of the biggest barriers to advancement for a lot of smart, hard working people is the "Does not show initiative" knock or some variation on the same theme.  You would not believe how many times I've been in discussions about who's ready for a promotion and heard something like "Joe does a great job at whatever I tell him to do, but only what I tell him to do" this is the kiss of death because we don't want to tell everybody what to do.

This might be a great surprise to many because from the trenches we feel micromanaged and thwarted in our attempts to make the great improvements we know we could make if only we were allowed.  It's a conundrum - I admit it.

How do you show you're a "Go Getter" ready for advancement while being micromanaged and thwarted by evil Pointy Haired Bosses that cannot code their way out of an open grocery bag - such as myself.

Well it's simple really.  Do the small stuff for yourself or for the PHB of your choice.  For instance if I say "let me get with Don and get back to you with an answer" you say "I can check with Don and make sure I have everything I need."  This is the perfect response because it takes a task off my plate, and it allows you to get the work done more quickly - not waiting for me or annoying me with constant badgering about did I get with Don yet.  Btw the badgering thing will just makes you look like a high maintenance pain in the ass.  I do not want to be reminded of my status as a bottleneck...  

The scenario above is just the starting point of an upward spiral of Go Getter goodness.  Now you are the focal point for the task with Don too - he's likely to be just another PHB and might say "Let me get with Tim and I'll get back to you"  For the life of me I do not understand why middle managers so often turn themselves into Gofors.  Anyway, same thing, tell Don you can get with Tim directly and that you'll keep Don in the loop if he wants.

So at this point you've helped two managers without doing any more work than you would already be doing.  You've made life better for you and Tim because you guys don't have to wait for PHBs to communicate.  And you've made it much easier to iterate through possible solutions with Tim - if that's applicable.

Make this little technique a habit and you'll get more interesting assignments, managers will start to listen to your ideas because they'll know that you are not just thinking of stuff for them to do, and when it comes time to select somebody for promotion you are way more likely be on the list.  Get on the list often enough and you'll get the nod.

Thanks for reading - Mike

A dozen things Deployment Scripts must do

Just like the barefoot kids of the local cobbler I find the installation of many software packages ironic and painful.  Lately I've been talking, a lot, to development managers about getting their deployments scripted and to business people about why Fast, Easy, Reliable deployments are important to them.

Strangely, there seems to be a real lack of understanding on the part of developers about what a build script should do.  I blame IDEs for allowing developers to mostly ignore how things get built and deployed - but I could be wrong.

Anyway,  I've written a list of generic requirements for an automated deployment and this seems to have helped several folks focus their efforts so I thought I would share.  I have gotten some feedback that this list is 'pie in the sky' but I reject that while allowing that some of these things are not all that easy.

An automated deployment should:

1. Start with a single package.
   
2. Reliably put the target environment into a known state.
   
3. Ensure that required disk space is available.
   
4. Save anything needed for rollback.
   
5. Place all files where they belong.
   
6. Register anything that needs to be registered.
   
7. Configure anything that needs to be configured.
   
8. Start everything that needs to be started.
   
9. Validate the state of the application.
   
10. Validate connectivity to all required resources such as databases.
    
11. Report Success or failure and the name of the artifact you have deployed.
    
12. Log all relevant deployment activities.
    

Starting with a single package is important because it's a lot easier and less error prone to move one jar file than a jar file, a couple of properties files, a config.xml etc.  Plus you can give the package a name and store it someplace for later.

By "Reliably put the target environment in a known state" I mean just that.  If you need to shut down an application server you should also search for and kill any hung processes.  If there are status flags, set them to the correct value; basically clean the kitchen before you start cooking.

Nobody wants to get part way through a deployment just to run out of disk.  Check it first.  This is a no-brainer, but often overlooked.

Save your old stuff so you can drop back and punt if needed.  I would urge you to save it into a single package just like the one you're deploying.  I don't think you should rely on going back to the old package as there may be required changes in the current environment.  Those changes should have been the result of a proper deployment, but stuff happens...

Place your files.  I usually call this sprinkling - the deal is that your script needs to put every file where it belongs, using an appropriate path reference.  If it is always going to be the same in relation to the root directory, I like fully qualified path names.  Otherwise I like paths names relative to the installation directory - hopefully all within the installation directory.

Register things that are registered.  I don't know what you might be registering, but get it done here.  Also, start from scratch each time.  If you rely on something already being there, at some point it won't be, so trust nothing. 

Configure things that need to be configured - whatever they are - same as above, start from scratch.  Rather than sending a deltas for a config.xml send the whole (version controlled) file with the contents you want.

Start everything up.  Do this in the script rather than expecting the guy doing the deployment to do it manually.  There's no telling how many hours of otherwise useful human activity have been squandered on troubleshooting just to find that something did not get started when it should have.

Having started everything, go look to see that it is really running.  Seems simple because it is.

Validate connectivity.  If you need it for production make sure you can talk to it and that it answers.  This does not have to be complex, a simple select statement, ping or whatever makes sense for the end point you need.

When something is completed, say so, when something fails, make some noise.  Let the poor guy doing this in the middle of the night know what's going on.  Also, reiterate what version has just been deployed; I have seen people go through a long deployment and troubleshooting session just to find that they deployed the stuff from the previous release.

Build a log as you go.  Tell me when each thing starts and stops and what you did.  Do not dump a bunch of useless noise in the log though.  It should read like a detective's notebook.  

• 22:17 Copied Blahblah1.2.jar to...
  
• 22:20 Change directory to /user/loc...
• 22:20 Executed jar - xf...

Above all put yourself in the shoes of somebody that has to deploy your app along with 20 others, in the middle of the night, while taking calls from people that want status, and trying to grab a bite to eat.

Thanks for reading - Mike