Pay attention to setting up a great development environment early, before the real development begins. Some of the common components are listed below.
| Component |
Benefit |
|---|---|
| Build script |
A well designed build script makes it quick to develop, with very few dependencies (if any) on slow internet or network resources. Normally a build script can generate classes, deploy and run the application from the command line, even do an automated release to the customer. |
| Source code repository |
Tracks changes to the source code to enable source code control at all times. The source code repository such as CVS or Subversion. Developers will make mistakes and it is important to use some kind of Source Code Control. But use optimistic source code control. Systems where files must be locked out to a user are too rigid for rapid development and constant refactoring. |
| Developer Workstation |
Developers typically need administrator access to be able to install and run standard tools such lightweight web servers and databases. The faster a compile or code refactor can complete, the better, so a recent model PC is critical. Developers can often do a hundred builds a day when trying to debug a problem, so if you can shave off a minute for each build that would save many man-days for the length of the project. |
| Wiki |
At the beginning of a project there will be all kinds of emails flying around. The best way to collate them all into something sensible is to put them straight onto the wiki. You can even paste the email itself without formatting if the team is too busy setting up other parts of the environment. Tidying up a wiki is project-long activity. |
| Build Server |
An automated build server such as Hudson can detect broken builds very quickly and notify the team by email. Normally it deploys to the development server. |
| Development Server |
The development server runs a version of the software which is the current state of the application in the source code repository – this can change hourly. The environment of the development server should be as close to Production as possible, so if the production server will run Apache as part of the solution, the dev server should have Apache too. If production will use Oracle, the dev server should too. |
| Test server |
This is a controlled server where the test team can access installed and formal releases of the software. Only code that is stamped/tagged in the source code repository and ready for testing should be seen on the Test server. The Test server environment should mirror production. |
| Staging server |
Once a release has passed on the test server, normally the Production server is duplicated onto the Staging server, which is is then upgraded with the release to ensure it will work. The Staging server should mirror production, ideally right down to load balancing configuration. Servers are expensive so there might be only two servers in Staging vs twenty servers in Production. |
| Production server |
Not normally part of the development environment, but it pays to start setting it up straight away in a project, especially when the server is managed by an outsourced team who are not under your direct control. Production is not a toy and should always be treated with care when live. |
Only one or two experienced developers should be needed to set up these components. If you have the right people setting up the development environment at the beginning, the project will reap rewards later in stability & man hours.
