At one time or another all software developers have joined a project or team where the development was already underway. The most common introduction for a new developer to these projects is to setup their development environment. If you’re extremely lucky, a lot of this work is already done within the corporate disk image, but more often than not it’s up to you. This is especially true if you’re a contractor.

For a typical Java project, the story goes something like this. Download and install a specific JDK (Java Development Kit). Download and install a particular IDE like Eclipse. Download and install a specific web server. By the way, depending on the company, some of these versions may no longer be available which means you have to track down someone who still has an available copy somewhere. But assuming they’re all the latest versions, that’s just the start.

Once that’s done, you have the core applications to setup. Then you get to start downloading and installing the support applications. If you’re using Eclipse, maybe it’s the SVN (Subversion) subclipse plugin or the TortoiseSVN client. A good text editor such as UltraEdit. FireFox. The list goes on for about a dozen or so applications.

After that you probably need to configure your system settings. Most likely you then have to set up some development environment variables or configurations (server.xml, eclipse.ini, etc.). Save some connection settings in Putty. Setup some network drive connections. And on it goes.

But the fun doesn’t stop there! At this point you’ve just got your environment setup, you haven’t downloaded the project’s source code. Now you need to checkout the project from the source. Once that’s done you need to run the automated build system to get the project up and ready on your box, perhaps using Ant or Maven. If you’re lucky, and the company was in the upper technological echelon it ends there. Unfortunately most companies don’t completely automated their builds so you often still need to do some extra manual tweaking to get your project running. And on it continues.

Which means that all new developers lose anywhere from a few hours to several days setting up and configuring their development environments. Very expensive! And the longer your project goes (there will be some developer turnover with time) and the bigger your team gets, the more expensive it gets. Plus, with time this knowledge will disappear. People will forget steps, or why things are done in a certain way. Which means that at some point setting up a new project will be, well, for lack of better word, insanely difficult. You’ll have to track down specific people within the project because they’re the only ones left who know anything about certain parts of the system. If you’re really unlucky, the only way to get up and running might be to you copy the complete environment from one computer to the other. Yes complete copies of directories! It can become a mess.

The good news is that there’s a much much better alternative. One that will make everyone’s life much easier, and keep the knowledge over time. Can it really be? Yes, we don’t all have to suffer through this. And what’s even better is that I’ve implemented what I’m about to suggest with great success several times, and not just at LandlordMax but also at companies I’ve consulted for in the past.

Create a developer’s installer!

Why should your final product be the only system with a deployment strategy? Why not create one for your developer environment as well. Especially if your company doesn’t have a fully pre-prepared disk image ready with everything (which is virtually guaranteed).

How hard is this to do? It’s actually extremely simple, simpler than you might think. If you’re company already owns an installer like Install4J (which I’ve recommend in the past), then it’s a matter of an hour of someone’s time. And it shouldn’t just be kept on someone’s machine, it should be it’s own full project within your version control system. This way if any developer does any environment change, it’s up to them to update the developer installer project. This includes if an application needs to get updated (for example to the latest version of Eclipse, the latest version of FireFox, etc.). This isn’t just limited to new software updated, but also configuration changes, etc. No longer do you need to keep a record of configuration change emails, it’s all done for you in the developer installer!

Therefore when a new developer starts, all you have to do is get the latest executable build, copy it on a USB key (network drive, whatever), and let them run it. Better yet, you can do it the day before they come if they’re going to use in-house hardware. During this time you can walk them around and introduce them to the rest of the people they’ll be working with, explain them the project in more detail, or any other higher value action items you may have.

And don’t worry if your company hasn’t bought a great installer building tool like Install4J, you can also use the open source installer creation system called NSIS. Up until LandlordMax, I generally relied on NSIS to create Developer Installers since I could never guarantee what was available in the different development environments, but with LandlordMax we use Install4J. Both are great, the main difference is that with NSIS it will take you a lot longer and you’ll need to acquire a lot of specific NSIS knowledge (it’s a scripting language). So instead of an hour or so for Install4J, expect it to take a few days to a week or more with NSIS to build a good installer. But even if it takes a week, it’s worth it!!! The good news is that it doesn’t have to be production quality, just beta quality. In other words, you don’t have to include all the checks like in a production installer, you can assume that your users are pretty smart and will mostly enter in valid values (for example you can assume there’s enough disk space on the hard disk, that it exists, that’s writable, and so on).

The good news is that an NSIS installer script shouldn’t be more than a few dozen lines to a couple hundred lines (assuming you’re using functions and macros available on their website). So that’s not too bad overall. With Install4J it’s all GUI based, and the resulting script is stored in an xml file which can be called from any Ant build script! The cost to benefit ratio for one person to translate all the developer environment knowledge into an automated installer for everyone that will be available forever is unbeatable!!

A few quick tips:

• Don’t re-create your main build file (Ant or Maven in Java), leverage what’s already there. In other words, you developer installer can call the main build file in your project to complete the environment setuo.
• Use silent installers. Most applications have silent install options, so use them. The less interaction your developer installer requires the better.
• Give the developer the option of selecting the initial install location.
• As part of the install, leave all the individual installers within the main install directory (for example leave the FireFox setup executable somewhere in the install path so that it can be run separately later).
• Give the option to select which “modules” to install. For example give the option to install FireFox, to install Eclipse, to configure the server.xml configuration file, etc. I’ve done this in the past by presenting a list of options (checkboxes) the user could select. By default all are selected with a toggle to unselect all of them near the bottom.
• Assume advanced users are using your installer. In other words, you don’t need to spend too much time on checking for user errors. Let it fail miserably if there’s an error. It’s not worth the time.

As an added benefits, everyone has the same development environment initially by default. With time some developers will deviate from the standard development environment to what they like, but it’s good to start the same way. At least this way you have a default method to setup a developer environment which is a million times better than having a bunch of different developers setting up your environment in slightly different and unique ways. Plus if there’s an issue, it’s REPRODUCIBLE!

Discuss (6)