March 16, 2011

Thinking about a developer setup template

March 16, 2011 - Categories: geek, ibm, kaizen, work

Development on one of my projects has gone in fits and starts. It’s been particularly challenging because the information about server configuration has been incomplete and scattered, trickling in as the IT architects sort out what’s going on and find people who can answer questions. The other developer and I are both new to this software stack (Websphere Portal, Websphere Application Server, FileNet, Enterprise Content Manager, DB2, Rational Software Architect). This means that we run into all the things that experienced developers take for granted: where to find documentation at the right level of detail, which ports and URLs to use (or even how to go about finding them), how to deploy our code, and how to diagnose and troubleshoot problems.

Stoic philosophy to the rescue. It’s no use whinging about not having all the bits and pieces up front. =) Besides, the people who set up the virtual images are people too, doing the best job they can while probably being pulled in a million directions or afflicted with the curse of expertise, forgetting the kind of knowledge they take for granted. It’s okay. It is what it is.

We’ve managed to figure most of the pieces out with a lot of poking around and experimentation. I’ve successfully deployed a web service, found sample code that can post a file to our Filenet object store, and written a web service client. We’ve previously been able to connect to DB2, so we should have all the major pieces now. The next step is to wire it all up with application-specific code.

I’m thinking of organizing all the bits and pieces of information we needed into a template that I can share with server administrators and developers next time we’re on a project like this. It would make work a lot faster and easier.

So, what do developers need? We typically need to:

Set up our development environment
software, licensing, config, source code control information, bugtracking, etc.
Orient ourselves on different environments
login/access/VPN details for integration, testing, and production environments; deployment procedure
Confirm that the service is running correctly
the full URL to the web-based administration console and to other web interfaces we can use, any hosts entries needed (for name-based virtual hosts, for example)
Log on the server and look around
VPN details, boundary firewalls, IP addresses, usernames, passwords, connection software (Remote Desktop? VNC?), file paths, location of log files
Write code
API documentation, software versions, ports, paths, usernames, passwords
Deploy and run code
file paths or upload interface, instructions on starting or restarting services
Test that things are working
web interfaces, ports, URLs, etc.

This could be a lot of information, and it might not be worth doing if you’ve got a couple of developers who can pick things up quickly. On the other hand, if you’re preparing a demo image that could be used dozens or hundreds of times for development, or if you gradually build this document over time, that could be pretty handy.

What’s in your developer setup template?

Photo (c) 2009 Mecookie – Creative Commons Attribution License

2011-03-15 Tue 20:03