Sessions at gearconf - Software entwickeln im Team on Tuesday 26th June

Your current filters are…

  • Von Continuous Integration zu Continuous Delivery

    by Eberhard Wolff

    Früher war die Integration von Projekten zeitaufwändig, komplex und fehleranfällig. Mittlerweile hat sich Continuous Integration etabliert.
    Indem man die Projekte ständig integriert, können Fehler frühzeitig
    aufgedeckt und behoben werden. Aber hier darf man nicht stehen bleiben, denn heute ist die Installation von Anwendungen komplex und fehleranfällig. Oft ist die Produktivstellung eines Releases selber schon ein Projekt. Mit Continuous Delivery wird auch dieser
    Prozessschritt ständig wiederholt, so dass das Risiko sinkt und die
    Prozesse einfach wiederholbar sind. Der Vortrag gibt eine Einführung in Continuous Delivery, konkrete technische Ansätze für das Vorgehen und schließlich einen Einblick, wie Continuous Integration und Delivery zusammenspielen.

    At 9:00am to 9:45am, Tuesday 26th June

    Coverage slide deck

  • 20 Gründe, warum man keine Architekten braucht

    by Pavlo Baron

    Entwickler wollen nichts von Architekten hören. Manager wollen keine Architekten haben. Consultants wären gerne Architekten, dürfen aber nicht. Software-Architekten wollen nur entwickeln. Enterprise-Architekten wollen nur verwalten. Chef-Architekten können nur managen. Scheint, als ob es gar keine "echten" Architekten gäbe. Genau! Und man braucht sie auch nicht - hier sind 20 Gründe, warum.

    At 10:15am to 11:00am, Tuesday 26th June

    Coverage slide deck

  • Build Pipelining mit Jenkins/Hudson und Maven

    by Martin Eigenbrodt

    An Continuous Integration gibt es zwei Anforderungen, die in Konkurrenz zueinander stehen: Einerseits soll der Entwickler möglichst schnell Feedback bekommen, um Fehler frühzeitig zu erkennen und behandeln zu können.
    Andererseits wächst die Zahl der Aufgaben eines Buildservers ständig: Neben Bauen und dem Ausführen von Unit-Tests gehören heute auch Integrationstests und das Deployen auf Test-, Staging- oder Produktionssystemen dazu.
    Eine Antwort auf diese scheinbar widersprüchlichen Anforderungen ist das Build Pipelining.
    Dieser Vortrag stellt vor, welche Möglichkeiten es gibt, Build Pipelining in der Praxis mit Jenkins und Maven zu realisieren.

    At 10:15am to 11:00am, Tuesday 26th June

  • Rediscovering Modularity

    by Chris Chedgey

    The principles of modularity have been applied to engineering projects since Gorak built the wheel, and Thag the barrow of the world's first wheelbarrow. Thag's barrow didn't care that the wheel was first hewn from rock, and later upgraded to a lighter, wooden one, and the same wheel design was reused for the world's first chariot.

    Analogous principles of modularity are taught in Software Engineering 101 - information hiding, interfaces, clear responsibility, high internal cohesion, low external coupling, etc., and we apply these routinely as we develop, and continuously refactor the code encapsulated within classes.

    However when the number of classes reaches some threshold, higher level abstractions are needed in order to manage the complexity of the growing codebase. This limit is usually overshot and the team is soon drowning in an ocean of classes. At this point it is time to restructure the code-base into a hierarchy of modules above the class level, or watch the team's frustration continue to rise, and productivity plummet.

    This talk will introduce strategies for improving the modularity in an existing codebase, with minimum impact on the code itself. The importance of "levelization" as a first step in this process will be explained, as well as the benefits of top-down vs. bottom-up approaches. Examples will be presented. This material is based on experience in helping many development teams through the restructuring process.

    At 11:15am to 12:00pm, Tuesday 26th June

    Coverage slide deck

  • Unit- und Integrationstest mit Maven

    by Karl Heinz Marbaise

    Die Problematik in der Entwicklung ist, dass Tests geschrieben und ausgeführt werden müssen. Wie sieht die Unterstützung von Maven im Bereich Unit- und Integrationstests aus? Ist es notwendig ein eigenes Modul zu erstellen oder kann man Unit-/Integrationstests auch in ein vorhandenes Modul integrieren? Welche Möglichkeiten bietet hier Maven? Es kommt auch hin und wieder vor, dass man ein Maven Plugin entwickeln möchte womit sich dann die Frage nach der Testunterstützung stellt.
    Wie kann man Unit- und Integrationtests für ein Maven Plugin erstellen?
    Der Vortrag möchte unterschiedliche Möglichkeiten und "Best-Practices" aufzeigen Unit- und Integrationstests in einen Maven Build zu integrieren und auszuführen. Dabei geht es um Unitests, Wiederverwendung von Unitests, Integrationstests, beispielsweise für eine Web-Anwendung, usw.

    At 11:15am to 12:00pm, Tuesday 26th June

    Coverage slide deck

  • The Unknown Creature: Maven

    by Karl Heinz Marbaise

    Im Rahmen des Workshops (ca. 1,5 Std.) wird der gesamte Life-Cycle einer Anwendung beleuchtet. Das geht von der Initiierung
    über die Entwicklung, die Release Erstellung bis hin zur Wartung eines Projektes.

    Wie kann hier Maven helfen, die unterschiedlichen Lebenszyklen zu unterstützen? Wie wird die Entwicklung unterstützt? Wie kann man Unit- und Integrationstests integrieren? Welche Möglichkeiten bietet Maven, um Auslieferungen zu erstellen ? Wie kann die Zusammenarbeit zwischen unterschiedlichen Projekten durch den Einsatz von Maven vereinfacht werden?

    At 1:00pm to 2:45pm, Tuesday 26th June

  • Feature Flags mit Togglz

    by Christian Kaltepoth

    Die Begriffe Continuous Delivery und Continuous Deployment sind heute in aller Munde. Und das zu Recht. Schließlich erlauben sie es, den Benutzern Bugfixes und neue Features in kürzester Zeit zu Verfügung zu stehen. Anwenden lassen sich diese Verfahren jedoch nur dann, wenn die Applikation stets in einem für die Produktionsumgebung geeigneten Zustand ist. Togglz ist eine Java Implementierung des Feature Flags Patterns und hilft dieses Ziel zu erreichen. Togglz erlaubt es Teilaspekte der Applikation zur Laufzeit ein- oder auszuschalten. Dabei ist es sogar möglich, neue Features nur für eine eingeschränkte Benutzergruppe freizuschalten. In diesem Vortrag wird Togglz vorgestellt und anhand einer echten Applikation demonstriert, wie leicht sich Togglz in eigene Projekt integrieren lässt.

    Christian selbst hat Togglz entwickelt. Die Idee zu diesem Projekt ist ihm auf der WJAX 2011 gekommen. Inspiriert von den Vorträgen zu DevOps hat er nach einer Möglichkeit gesucht, das Feature Flags Pattern auch in seinen Projekten zu nutzen. Leider gab es keine existierende Bibliothek, die seinen Vorstellungen entsprach. Heute setzt er und sein Team Togglz bereits in mehreren Kundenprojekten erfolgreich ein. Christian denkt, dass dieser Vortrag besonders für Personen interessant sein könnte, die daran interessiert sind, erste Schritte in Richtung Continuous Delivery zu gehen.

    At 2:00pm to 2:45pm, Tuesday 26th June

    Coverage video

  • Clean Code: Von der Schule in den Alltag

    by Dr. Reik Oberrath

    Seit einiger Zeit geistert der Begriff Clean-Code durch die IT-Welt. Die Grundlage dazu lieferte das gleichnamige Buch aus dem Jahre 2010 von Robert C. Martin. Darin stehen die Lesbarkeit und Verständlichkeit an oberster Stelle, um während der Entwicklung, insbesondere aber in Wartungsphasen, Zeit und somit Geld einzusparen.

    Die Clean-Code-Developer-Bewegung (CCD) geht noch ein Stück weiter und nimmt sogenannte Praktiken wie die Pfadfinderregel, automatisierte Builds, Code-Metriken, etc. mit in ihr Konzept auf. Um diesen hehren Zielen näher zu kommen, appelliert die CCD in erster Linie an das Bewusstsein (an die mentale Einstellung) des Software-Entwicklers.

    Wir glauben, dass ein solcher Appell gegen unseren "innere Schweinhund" nicht wirklich ankommt. Wir stellen einen teamorientierten Prozess vor, mit dem die Entwickler "auf Augenhöhe" und auf zuvor gemeinschaftlich abgestimmter Weise sich gegenseitig überwachen: das Clean-Team-Coding.

    At 3:15pm to 4:00pm, Tuesday 26th June

  • Enterprise Testing mit Spock

    by Igor Drobiazko

    Spock ist ein Groovy-basiertes Testing-Framework für Java und Groovy. Entworfen für die Zukunft, erlaubt Spock die Tests in einer ausdrucksstarken DSL zu schreiben. Spock verzichtet auf Assertion API, Record-and-Replay Mocking API und konzentriert sich auf das Wesentliche. In dieser Session wird vorgestellt, wie Spock das Testing von Groovy and Java Anwendungen zum Spaß macht.

    At 3:15pm to 4:00pm, Tuesday 26th June

    Coverage video