Everybody comes across this issue from time to time. You have a fresh and exciting project with a couple of developers. The skills of the team members are different and you have to deliver a complete setup of the development environment for all of them. This is probably no big deal if you have up to five members. You just decide, what components to use and write a small howto which everybody can follow. Running around solves the rest of the open issues. But this is getting much harder if the team grows beyond this. And this is a setting you can still find. Even if more and more projects get smaller and use agile methods ;)
If you are not willing to spend weeks in team internal support for setup and configuration you have to find the right approach. I am going to summarize some thoughts about this in the following parts.
Basic Requirements
Let's look at what is needed for a minimal developer setup.
- Applicationserver (Binaries and Configuration)
- Database (Binaries and Configuration)
- Build Tool (Binaries and Configuration)
- CVS/SVN/Whatever Client (Binaries)
- Integrated Development Environment incl. Plugins (Binaries) - Basic Project Setup (Configuration)
For almost any single part in this hopefully not too incomplete list, you have some kind of binary that needs to be installed on a developers desktop and some kind of configuration. It is highly recommended to keep any project specific configurations within your source code repository. The following thoughts only apply to the binary installs.
Preliminary work
The bigger the teams get, the more you are in need of a detailed plan for what you are going to do and use. This does include everything. Beginning from the basic decision about the Java EE Appserver up to the single plugins for the IDE used by the developers. Basic rules are:
- Be as near as possible to the future production environment. If this is not possible, think about staging and possibly arising problems and how to avoid them.
- Find the right balance between the number of plugins for your IDE and make shure, they work together smoothly.
- Find the right build tool. Even if already commodity, I still like Maven. But this adds more infrastructure to your projects. (e.g., proxy, company repository)
- Think about the software design and architecture up front. You have to have an idea about which modules you will need and which parts of the team should work on them. (There is much more in/behind the team issues in a project. But I am not going to cover them here and now;))
If all this is done, you can think about the rollout. It highly depends on the basic setting. Are you using Windows based systems for development or Unix/Linux? Do your project have special infrastructural dependencies (e.g, SSO, Host) that cannot be mocked? Make a complete list of all things that could influence the development and choose one or even combine the following approaches.
And by the way, it is always good to catch up with the most experienced members in your team to discuss your prefered solution:
The "all-in-one-solution"
Rookie's Workplace
I love to call it this way. The name stands for a single image of the complete environment. Could be achieved using any kind of VM solution out there. We experiment with VMWare but there are a lot of other products available. The only task here is to setup the virual machine and install everything the way, you would like it as a developer.
After this, you have to rollout the VM runtime to the dev PCs and ship the image.
Implementation cost: probably some days
Rollout cost: should be around half a day per team member
Advantages: Very easy rollout. Highly predetermined setup.
Disadvantages: VM performance (?), no easy incremental update, cost of the VM solution
The "bit-by-bit-solution"
Hacker's Workplace
The complete opposite of the previous. You define all used parts and rollout a document containing the install and setup instructions. Place the binaries in any kind of network share or provide download links and version information.
Implementation cost: probably one day
Rollout cost: easily more than a day per team member
Advantages: hardly any rollout, Highly configurable, Easy to update
Disadvantages: Cost of setup within the team, error-prone, learning curve
The "best-of-bread-solution"
Developer's Workplace
If you don't like one of the above, you are in need of a combination. Such combinations are most often called the "best-of-bread" solutions, derived from a couple of projects. This is, where you start to cut the problem into pieces. Which parts of your setup is project related? Which parts change often? Which parts are common in your company? Depending on this, you have a much broader range of options to choose from. Some examples:
Software distribution for common software
IDE, build tools and source control clients are good examples of common software you could probably put into the (already in place) software distribution system of your company. This reduces the complexity in your rollout to basically two components. The appserver and the db.
Implementation cost: not your budget :-)
Rollout cost: not your budget :-)
Advantages: stable and standardized
Disadvantages: probably not the software version you like to have.
Option central server
This is a unusual but valid solution. You set up a central server instance and enable it for multiple developers. This could be done in different ways and is highly dependend on the application/db server you are going to use. You could for example
a) have separate domains for each developer (something like a multi project server)
b) use individual application deployments (beware of naming problems)
c) have separate databases or schemas
d) have separate tablenames
To get an idea what this is all about, I recommend you read
"Gone fishing for Glassfish" by Sidsel Jensen
Implementation cost: Depending on your org. probably not your budget :-)
Rollout cost: none
Advantages: stable and standardized. Garanteed operation, SLA, central infrastructure, capable of big deployments with lot of data
Disadvantages: Depending on your org (hardware cost, monthly cost), hardly any flexibility
Option de-central server
The most common setting. Every developer gets his own db and appserver on his local hdd. How easy this is, depends on the used products. If you are going to use websphere and db2 you probaply have to have bigger hardware at hand and it takes slightly more time than using mysql and tomcat :-D But this should be no problem at all. The biggest issu is to rollout the project specific configuration. In most cases it is promissing to think about a scripting approach. Nearly all appserver have any kind of command line interface you can use. Or you can even use a scripting environment. Arun Gupta posted an example for the GlassFish v2
in his blog.
The database should not need any special setup or configuration for the development environment at all. You can thing about moving it to the central software distribution or try to find the silent install option.
Implementation cost: Probably some days
Rollout cost: highly dependent on the products you use. One to five days per developer.
Advantages: stable and standardized but flexible
Disadvantages: Bigger hardware required, cost of setup within the team, error-prone, learning curve
Option embedded server
To be honest, I don't like the central approach. And having some three blue character company's software stack on my notebook is also something I realy don't even want to dream of ;) If you have the time to prepare it, you could thing about using the embedded server approach. There are some containers out there, that could be run in embedded mode. If you think about H2 DB, OpenJPA or GlassFish it is definitely an option to have a local startup class for all needed containers. In most of the cases you are forced to develop on components far way from the productive environment. Therefore you have to strictly stick to the Java EE standards your container provides. If you even have different DB this gets even more complex.
Implementation cost: Probably some days
Rollout cost: should be around half a day per team member
Advantages: stable and standardized but very flexible
Disadvantages: learning curve, staging problems
