20.09.2010, 17:00 Uhr – 20.09.2010, 20:00 Uhr, Köln, TechnologiePark Köln, Veranstalter: itemis AG, Preis pro Person: 49 EUR zzgl. MwSt.

Agile Methoden, wie z.B. Scrum, XP, FDD schreiben keine konkreten Werkzeuge vor. Allerdings geht es auch nicht ohne. Ticketingssystem, Continuous Integration, Wiki, Versionierungssystem werden mehr denn je benötigt.

In Teil 1 dieses Vortrags stellt ihnen Thorsten Kamann aus der Sicht eines Scrum-Projekts die benötigten Services und die Integration untereinander vor. Hierbei liegt der Fokus auf der Realisierung des Single Point Of Information-Konzepts gelegt. Ein zentraler Service bietet auf Basis eines Tickets oder Aufgabe alle nötigen Information über seinen Status.

Teil 2 des Vortrags besteht aus einer Demo der in Teil 1 besprochenen Services aus der Sicht eines Scrum-Teams. Dabei wird gezeigt, wie die Services von Erstellung des Product Backlog über das Sprint Planning bis hin zu der Abarbeitung der einzelnen Tasks miteinander arbeiten, so dass jedes Teammitglied zu jeder Zeit den Status eines Sprints verfolgen kann.

Teil 3 des Vortrags sind für Fragen und Diskussionen reserviert.

Weitere Informationen und die Möglichkeit zur Anmeldung finden Sie hier.

In Teil 1 dieses Vortrags stellt Ihnen Thorsten Kamann aus der Sicht eines Scrum-Projekts die benötigten Services und die Integration untereinander vor. Hierbei liegt der Fokus auf der Realisierung des Single Point Of Information-Konzepts. Ein zentraler Service bietet auf Basis eines Tickets oder einer Aufgabe alle nötigen Information über deren Status.

Teil 2 des Vortrags besteht aus einer Demo der in Teil 1 besprochenen Services aus der Sicht eines Scrum-Teams. Dabei wird gezeigt, wie die Services von Erstellung des Product Backlog über das Sprint Planning bis hin zu der Abarbeitung der einzelnen Tasks miteinander arbeiten, so dass jedes Teammitglied zu jeder Zeit den Status eines Sprints verfolgen kann.

Teil 3 des Vortrags ist für Fragen und Diskussionen reserviert.

Veranstaltungsort ist Zürich, Schweiz. Weitere Informationen finden Sie unter http://www.jugs.ch/html/events/2010/scrumservices.html.

• Bug tracking
• Manage your projects with Jira
• Create your own workflows for tasks and issues
• Powerful Reporting
• Extensible with plugins

You can download a standalone version bundled with a Tomcat 5.5. With this download you can start directly. But typically you already have an infrastructure. For such scenarios it’s much better to use the WAR/EAR-Edition of Jira.

This article describes the installation with Apache Tomcat 6 on a Linux box. If you plan to do this on windows you only must change paths and – of course – shell against Windows Batch.

Install Tomcat

You can get Tomcat from the official projectsite. You get a ZIP- or TAR.GZ-Archive. Now you can extract the archive and do a testrun by browsing to http://localhost:8080.

If you want to deploy Jira to this instance of Tomcat you need some additional Jars not included in the web archive you will later deploy. You can get the additional jars from here. Create a new directory in you Tomcat installation directory: ext/jira/lib. Copy all Jars into this directory.

Finally you must Tomcat announce the new libraries. For this you edit the conf/catalina-properties by changing the common.loader property (the property is a single line; here are only breaks due to layout reasons):

common.loader=${catalina.base}/ext/jira/lib/*.jar,
       ${catalina.base}/lib,${catalina.base}/lib/*.jar,
       ${catalina.home}/lib,${catalina.home}/lib/*.jar

Jira needs a lot of memory. Sometimes Jira needs more than Tomcat can deliver. So you should add mor memory to Tomcat. This and some other properties you should set, before the next restart of Tomcat.

export JAVA_OPTS="-XX:MaxPermSize=256m -Xmx1024m

       -Dorg.apache.jasper.runtime.BodyContentImpl.LIMIT_BUFFER=true

       -Dmail.mime.decodeparameters=true"

The first both options gives more memory to Tomcat. The last both options are needed by Jira. The 3rd is needed to avoid a memory leak of Tomcat and the last option is needed to send attachments with another encoding than the default encoding.

You must restart Tomcat to activate your changes.

Installing Jira

The archive you get as WAR-Edition contains the binaries you need to deploy it to Tomcat. But the archive contains the binaries for the EAR-Edition too. And for older Tomcats and Resin and so on… Additionally this archive enables you to do customizations like configurations, templates,  additionally sources to compile and JARs. After you downloaded the archive and extract it you must change one property pointing to the data directory used by Jira by editing edit-webapp/WEB-INF/classes/jira-application.properties.

Now you can build the web archive you can use to deploy to Tomcat. In the root directory the is a build script (build.sh and build.bat) you can use to archieve this. After some time the script is ready and a new directory is created: dist-tomcat/tomcat-6. There you find the web archive and the deployment descriptor for Tomcat 6. You can simple copy this descriptor to <<tomcat-install-directory>>/conf/Catalina/localhost. Tomcat will install Jira and you can browse to http://localhost:8080/jira.

Customizing the web archive

You can overwrite every file the web archive contains. The can archieved vy copying the file into the edit-webapp directory. Please remember to create the same directory structure. For instance if you want to customize the file webapp/WEB-INF/classes/log4j.properties you must copy it to edit-webapp/WEB-INF/classes/log4j.properties. After running the build script you can reload the webapplication with Tomcat’s Manager or simply restarting Tomcat.

Speed up the build script

The build script create web archive for all tomcat versions and a generic web archive for other servlet containers. If you plan to deploy to Tomcat 6 it would be enough to build the archive for Tomcat 6. To do this you must only change the target war in the build.xml:

<target name="war" depends="clean, compile" description="Packages the WAR file">
  <!-- Build the war file -->
  <jar jarfile="${dist-generic}/${name}-${version}.war">
    <fileset dir="${build.war}"/>
  </jar>
  <!-- Tomcat-6-specific .war -->
  <jar jarfile="${dist-tomcat}/tomcat-6/${name}-${version}.war">
    <fileset dir="${build.war}">
      <exclude name="WEB-INF/lib/commons-logging*.jar"/>
      <exclude name="WEB-INF/lib/log4j-*.jar"/>
    </fileset>
  </jar>
  <copy file="etc/tomcat-6-jira.xml" tofile="${dist-tomcat}/tomcat-6/jira.xml">
    <filterset>
      <filter token="JIRA_HOME" value="${basedir}"/>
      <filter token="JIRA_WEBAPP" value="${basedir}${slash}${dist-tomcat}${slash}tomcat-6${slash}${name}-${version}.war"/>
    </filterset>
  </copy>
  <echo>
--------------------------------------------------
Deployable WARs generated:
TOMCAT:  ${basedir}${slash}${dist-tomcat}${slash}${name}-${version}.war
GENERIC: ${basedir}${slash}${dist-generic}${slash}${name}-${version}.war
See http://www.atlassian.com/software/jira/docs/latest/servers/ for install instructions
--------------------------------------------------
  </echo>
</target>

Conclusion

Now your Jira is up and running. The next steps are configuration of projects and users, but this isn’t the focus of this article.

If you want to play this formats with itunes you can install some software:

• WMA: http://www.microsoft.com/…/player/wmcomponents.mspx
• OGG: http://www.xiph.org/
• FLAC: http://blowintopieces.com/fluke/

This works only for iTunes. If you want to play such items on your iPad/iPhone you need a converter to convert is to mp3. For this approach your can use Switch.

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…

• Filter internal stacktraces
• Importing GMaven projects

You can read here the New and Noteworthy. If you like you are be able to update your Eclipse installation with this update site: http://dist.springsource.org/release/GRECLIPSE/e3.5/

In diesem Artikel habe ich das Groovy Eclipse Plugin vorgestellt. Inzwischen ist der Artikel auch online verfügbar:

http://it-republik.de/jaxenter/artikel/Nahtlose-Integration-von-Java-und-Groovy-2951.html

Wer sich einen kurzen Überblick verschaffen will sollte dort einen Blick hineinwerfen.

This is very nice since the version 2.0.1 offers much of the features you know from the Java Editor:

• Syntax Highlighting
• Code Completion
• Refactoring
• Navigation
• Compile as you type
• and much more…

If you are interested and understand the german language you can read my article about the Groovy Eclipse Plugin published at Jaxenter.

• 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