What do I mean with development environment? Not only the developer workstation with Eclipse and the common tools like JDK, Maven, Ant and so on, but the environment you need for producing high quality software.
The following article is a kind of proposal for such an environment. I think every organization has its own needs but overall this could be a starting point, if you want to build it for your organization.

Structure of a development environment

Which roles are involved?

There are developers (in figure 1 in the top left corner), the QA (in the bottom right corner) and – of course - the customer (not shown). Of course there a many more roles in a software project – you know them as stakeholders, too.
But you know the ditch between developers and the QA-Guys? You can work well with the QA if the software they test has a good quality. But for this you need some components.

What components do you need?

Component	Description
Ticketing System	This is a must have. This component you need to track your tickets during development. Trac Jetbrains YouTrack Atlassian Jira Bugzilla Mingle Mantis …
Revision Control System	This component you need for versioning your source files. The is a great number of such systems: Subversion CVS Bazaar Mercurial Git Clearcase …
Wiki	You need something as documentation storage. Something that is agile enough not to block the development process. A Wiki can help you. But remember not every wiki is a good wiki
Continuous Integration	To produce high quality you need an automatically build and tests. Only with this you can verify your changes not breaking already existing features. With a CI-System you can achieve this. Some of this CI-Systems are: Hudson Cruise Control Atlassian Bamboo Jetbrains Teamcity Cruise …
Artifact Repository	You need always a repository where you can deploy the artifacts you build. The meaning of artifact in this context are archives like JARs, WARs, EARs but DLLs, too. Of cource you can deploy them to your Revision Control System. But it is always an good idea to have a mechanism you can resolve dependencies you have automatically. With Maven and Ivy you have Buildtools that do this for you. An Artifact Repository is a simple (or not so) storage for deployable artifacts. You can choose between 3 well-known OpenSource Products: Archiva Sonatype Nexus Artifactory

And now…

Every component must communicate with every other component. But let’s us begin with the developers. Developers working directly with the Ticketing and the Revision Control System. They need the Ticketing System to manage the development orders (or tasks or Sprint Backlog Items if you are familary with Scrum). Changes at the sources of the project will be committed to the Revision Control System. If you have a full featured Ticketing System you can log this commits and show the relevant commits in the tickets. So you can track all changes needed for the resolving of a ticket.

The Continuous Integration System (CI) is polling the Revision Control System to get notified for changes. If there are one or more changes the automatically build will be started. After the – hopefully – successful build all tests are executed – and hopefully green – and the artifacts can be deployed to the Artifact Repository. At the same time the revision (in Subversion) or the commit (in Git) can be tagged. So you have a marker for the sources the CI used to build and create the artifacts. With this tag it is every time reproducable. If you add the Ticket-ID in the commit messages the CI can add a comment to the ticket, so you can see if the buidl was successfully or not.

After some time the developer can resolve a ticket. At this time the CI should create a QA-Release. This is a special release because if the QA-Process is green this build should use for a release. The QA-Team gets notification for a testable build from the Ticket System. After the test the QA mark the ticket as tested or reopen the ticket. In the second case the developer should fix the errors or problems.

Conclusion

This was a quick view of a possible solution to build a development environment. Such an environment you need to use Scrum successfully. I am very interested in your opionion. Please leave a comment…

I am using a Macbook. Now I want to play with GIT and the Subversion-Support of this. After some searching with Google I found this Blog-Entry. If mentioned there is is very easy to install git-svn:

• Install Darwinports
• install subversion-perlbindings
• install git-core +svn

Instead of Darwinports I want to use Macports. There is a image for SnowLeopard you can download here. After the installation it were very easy to use Macports. The next step is to uínstall the subversion-perlbindings. This is done with a

sudo port install subversion-perlbindings

and some time. This works very fine…I thought
The problem begins with the installation of git-core +svn.

sudo port install git-core +svn

stops with an error if curl should be installed:

Error: Target org.macports.destroot returned: error copying
 "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_net_curl/work/destroot"
 to
 "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_net_curl/work/destroot-x86_64/destroot":
 file already exists

After some searching with Google I found this Bugentry. The solution was to install zlib +universal first. But this doesn’t work for me
So I decided to uninstall all of Macport and start a new try:

sudo port -f uninstall installed
sudo rm -rf \
    /opt/local \
   /Applications/DarwinPorts \
   /Applications/MacPorts \
   /Library/LaunchDaemons/org.macports.* \
   /Library/Receipts/DarwinPorts*.pkg \
   /Library/Receipts/MacPorts*.pkg \
   /Library/StartupItems/DarwinPortsStartup \
   /Library/Tcl/darwinports1.0 \
   /Library/Tcl/macports1.0 \
   ~/.macports

At next I am reinstalling the Macport image followed by

sudo port install subversion-perlbindings
sudo port install zlib +universal
sudo port install git-core +svn

And it works

Große Entwicklungsabteilungen stehen oft vor dem Problem einheitlicher Entwicklungsprozesse und Werkzeuge. Nach einiger Zeit hat jedes Projekt eigene Prozesse und Werkzeuge etabliert. Dies ist nicht im Sinne der Entwicklungsabteilung. Softwaresysteme müssen i. d. R. über Jahre hinweg gewartet und erweitert werden – oft von einem Team, das sich neu in die Anwendung einarbeiten muss.
Nicht selten stellt die Rekonstruktion der Entwicklungsumgebung einen erheblichen Aufwand dar.

Dieser Vortrag beschreibt – anhand eines Erfahrungsberichts – den Aufbau einer strukturierten Entwicklungsumgebung, die auch für grosse Entwicklungsabteilungen skaliert.

• Zentrale Projekt- und Codeverwaltung (ähnlich wie Sourceforge)
• Buildmanagement mit Maven
• Entwicklungswerkzeuge basierend auf Maven und Eclipse
• Installierbare Teamserver mit Virtualisierungstechnologie für Continuous Integration