Hauptmerkmale des SilkCentral Test Managers

• Der SCTM unterstützt Testteams bei der Erstellung, Organisation und Verwaltung von Testplänen. Wobei es sowohl manuelle als auch automatisierte Testfälle berücksichtigt. Mit dem hierarchischen Ansatz kann man Testpläne in einer strukturierten Weise erstellen, sodass Testteams leicht Prioritäten setzen und Testfälle nach Modulen oder Funktionen gruppieren können.

• Man kann damit Testfälle erstellen und die Schritte, die zur Durchführung des Tests erforderlich sind und die erwarteten Ergebnisse dokumentieren. Auch die Verknüpfung der Testfälle mit Anforderungen sowie Defekten sind möglich. Dies schafft die Möglichkeit einer lückenlosen Nachverfolg- und Rückverfolgbarkeit.

• Bei der Testausführung selbst ermöglicht der SCTM den Testteams, sowohl manuelle als auch automatisierte Testfälle auszuführen. Dadurch kann man Fortschritte und Ergebnisse besser verfolgen. Testmanager können Testläufe planen und steuern während man die Testausführung nach Bedarf anpassen kann. Integrationsmöglichkeiten mit anderen Testautomatisierungstools wie Silk Test und Selenium erweitern die Automatisierungsfähigkeiten des SCTM.

• Der SCTM verwaltet Testdaten zentral und stellt sicher, dass alle Testergebnisse und -daten an einem Ort gespeichert und zugänglich sind. Testmanager können auf Testdaten und -ergebnisse zugreifen, um schnell Probleme zu erkennen und entsprechende Maßnahmen zu ergreifen.

• Umfangreiche Berichts- und Analysefunktionen, helfen dabei, Erkenntnisse aus Testaktivitäten zu gewinnen und die Qualität der Softwareprodukte kontinuierlich zu verbessern. Vorgefertigte Berichte und Dashboards ermöglichen es Testmanagern, den Fortschritt und die Ergebnisse von Testaktivitäten leicht zu visualisieren und zu kommunizieren.

• Man kann den SCTM mit einer Vielzahl von Tools und Plattformen integrieren, um Testteams bei der Einrichtung eines nahtlosen Testprozesses zu unterstützen. Integrationen mit Anforderungsmanagement-, Fehlerverfolgungs-, Versionskontroll- und Testautomatisierungstools ermöglichen eine lückenlose Zusammenarbeit und verbessern die Transparenz und Effizienz des gesamten Testprozesses. 

Einige der wichtigsten Integrationen sind:

a. Anforderungsmanagement-Tools: Durch die Integration mit Anforderungsmanagement-Tools wie Jira, TFS oder VersionOne können Testteams Anforderungen erfassen, verwalten und verfolgen und diese direkt mit Testfällen verknüpfen. Diese Verknüpfung verbessert die Rückverfolgbarkeit und erleichtert die Identifizierung von Abhängigkeiten zwischen Anforderungen und Testfällen.

b. Fehlerverfolgungs-Tools: Die Integration mit Fehlerverfolgungssystemen wie Bugzilla, Mantis oder Jira ermöglicht es Testteams, Defekte direkt aus dem SCTM heraus zu melden und zu verwalten. Dadurch kann man gegebenenfalls die Kommunikation zwischen Testern, Entwicklern und Stakeholdern verbessern und die Zeit zur Behebung von Fehlern verkürzen.

c. Versionskontrollsysteme: Durch die Integration mit Versionskontrollsystemen wie Git, Subversion oder Mercurial können Testteams ihre Testartefakte verwalten, versionieren und nachverfolgen. Diese Integration unterstützt die Zusammenarbeit und Kontrolle über die Testdokumentation, was zu einer verbesserten Qualitätssicherung führen kann.

d. Testautomatisierungstools: SCTM bietet Integrationen mit einer Vielzahl von Testautomatisierungstools wie Silk Test, Selenium, JUnit, NUnit und anderen. Durch die Integration dieser Tools können Testteams ihre Testfälle automatisieren, Testläufe planen und die Testabdeckung erhöhen, um die Softwarequalität weiter zu verbessern.

Fazit

Der SilkCentral Test Manager ist ein leistungsstarkes Testmanagement-Tool, das Testteams bei der Planung, Durchführung und Verwaltung von Testaktivitäten unterstützt. Mit der umfassenden Palette von Funktionen und Integrationen hilft der SCTM-Testteams, ihre Testprozesse zu optimieren, die Softwarequalität zu verbessern und die Kommunikation und Zusammenarbeit zwischen den verschiedenen Mitgliedern eines Softwareentwicklungsteams zu stärken. Insgesamt ist der SCTM ein wertvolles Werkzeug für Testteams.

Doch wie bei jedem Testmanagement-Tool gibt es auch beim SilkCentral Test Manager (SCTM) einige Makel oder Nachteile, die potenzielle Anwender berücksichtigen sollten. Da SCTM eine Vielzahl von Funktionen und Einstellungsoptionen bietet, kann es für neue Benutzer schwierig sein, sich zurechtzufinden. Die Lernkurve kann steil sein und es kann einige Zeit dauern, bis sich Benutzer mit der Benutzeroberfläche und den verschiedenen Funktionen vertraut gemacht haben. Darüber hinaus ist SCTM nicht das günstigste Testmanagement-Tool auf dem Markt. Je nach Bedarf und Größe des Testteams kann die Investition in eine SCTM-Lizenz eine erhebliche finanzielle Verpflichtung darstellen, insbesondere für kleinere Unternehmen oder Start-ups.

Die umfangreiche Funktionspalette von SCTM kann für manche Benutzer überwältigend sein, insbesondere wenn man nicht alle Funktionen benötigt. Die Komplexität des Tools kann dazu führen, dass einige Benutzer Schwierigkeiten haben, effektive Testprozesse einzurichten und zu verwalten. Obwohl SCTM in vielen Bereichen anpassbar ist, sind die Anpassungsmöglichkeiten möglicherweise nicht so umfassend wie bei einigen anderen Testmanagement-Tools. Dadurch kann es schwierig sein, das Tool an bestimmte Arbeitsabläufe oder Anforderungen eines Testteams anzupassen.

Aus Onlineforen geht hervor, dass Benutzer manchmal von unzureichendem oder langsamem Kundensupport seitens des Herstellers berichten. Dies kann frustrierend sein, wenn Testteams auf Probleme stoßen, die sie ohne Unterstützung nicht lösen können. Trotz dieser Makel bleibt SCTM ein leistungsstarkes Testmanagement-Tool mit einer Vielzahl von Funktionen und Integrationen, die für viele Testteams von großem Nutzen sein können. Bei der Auswahl eines Testmanagement-Tools sollten potenzielle Benutzer jedoch die spezifischen Anforderungen ihres Testteams sowie ihr Budget und ihre Ressourcen berücksichtigen. Es kann auch hilfreich sein, mehrere Tools zu evaluieren, um herauszufinden, welches am besten zu den Bedürfnissen des Teams passt.

Der Beitrag SCTM – Sicherheitsbewusstes Testmanagement für vertrauenswürdige und robuste Softwarelösungen erschien zuerst auf CEOsBay.

Features

Im Wesentlichen unterscheiden sich die beiden Versionen im Funktionsumfang. Hierzu von der Ultimate Version unterstützte Sprachen: Java, Groovy, Kotlin, Scala, Python and Jython, Cython, Ruby and JRuby, Rust, PHP, Go, Dart, SQL, HTML, XML, JSON, YAML, XSL, XPath, Markdown, JavaScript, TypeScript, CSS, Sass, SCSS, Less, Haml, Slim, Liquid

Wobei zu beachten ist, dass die Ultimate Edition von IntelliJ IDEA neben den nativ unterstützten Sprachen, einige der Sprachen lediglich durch den Einsatz von PlugIns unterstützt. In der Community Edition sind auch einige Sprachen gar nicht berücksichtigt. Eine explizite bzw. genaue Differenzierung möchte ich in diesem Beitrag nicht vornehmen. Also sind die Angaben bzgl. der Features mit Vorsicht zu genießen.

Auch ist zu beachten, dass lediglich die Ultimate Edition von IntelliJ IDEA die umfangreiche Framework Unterstützung mitbringt. Im Enterprise Umfeld sind diese in der Regel unabdingbar.

Auch bei den Build Tools gibt es Unterschiede. Besonders auffällig ist dabei die Tatsache, dass npm zwar in der Ultimate Edition läuft, jedoch nicht in der Community Edition. Ich habe es auch in der Community Version zum Laufen gebracht. Dennoch ist dies mit Vorsicht zu genießen, da ich aufgrund von Fehlern dennoch auf die Ultimate Edition geswitched bin.

Versionskontrolle

Auf die Funktionsfähigkeit bei der Versionskontrolle bzw. bei Cloud-basierten Diensten wie Git, GitHub, Subversion, Mercurial und Team Foundation Server kann man sich verlassen. Bei Perforce ist man zumindest in der Community Edition verlassen.

Deployment

Während die Community Edition lediglich Docker für das Deployment unterstützt sind es mit der Ultimate Edition Kubernetes, Java Applications Servers als auch Docker.

Codevervollständigung

Die Codevervollständigung ist eine Funktion, die vor allem Programmieranfängern sehr entgegenkommt. Nur wenige werden als Coder geboren, oder!? Da vergisst man schon mal schnell eine import-Anweisung, IDEA aber nicht. Meistens weist IntelliJ einen auf den Fehler hin und schlägt Korrekuren vor. Dies gilt auch für nicht verwendete Importe, die IntelliJ entsprechend einer manuellen Zustimmung entsorgt.

Es nimmt einem den Grossteil der Tipparbeit ab, damit man sich dem Programmdesign widmen kann und nicht über korrekt formulierte JAVA-Anweisungen nachdenken muss. Ich muss gestehen, dass ich mich bisher noch nicht wirklich mit JAVA auseinandergesetzt habe. Doch dies hole ich derzeit nach und auch darüber gibt es in der nahen Zukunft einen Beitrag.

Code Layout Manager

Den Code Layout Manager weiß man spätestens dann zu schätzen, wenn man im eigenen Quelltext nicht mehr durchblickt oder fremden Quelltext bearbeiten muss. Dann kann man Text markieren und von IDEA neu formatieren lassen. Dies geht relativ intelligent von statten.

Refactoring

Auch die Refactoringfähigkeiten von IntelliJ sind nicht zu unterschätzen. Wer die Funktionen einmal in Aktion erlebt hat, der möchte sie nicht mehr missen. Dazu gehören u.A. das Renaming, Move, Introduce Explaining Variable, Extract Method usw.

Fazit

Ich arbeite noch nicht lange mit dem Programm. Doch IntelliJ hat scheinbar in enger Kooperation mit den Anwendern ein relativ gutes Produkt entwickelt, mit dem man gut im Enterprise Umfeld arbeiten kann. Besonders die große PlugIn Bibliothek als auch die individuelle Erweiterbarkeit durch eine offen gelegte API haben mir persönlich sehr gefallen. Dadurch ist es auch möglich eigene PlugIns für IntelliJ zu schreiben und diese zu selbst zu implementieren.

Der Beitrag IntelliJ IDEA – Die intelligente und leistungsstarke Entwicklungsumgebung erschien zuerst auf CEOsBay.

Kurze Zeitreise

Bis zum Aufkommen der Microservice-Architekturen wurde Software klassischerweise als Monolith entworfen. Dabei gab es keinerlei interne Schnittstellen, da alle Informationen im Monolithen weitergereicht werden konnten. Dementsprechend konnte man sich im Testing nur auf die Stufen Unittests, Integrationstests und End-to-End-Tests konzentrieren. Mit dem Aufkommen der Microservice-Architekturen existiert nun eine Vielzahl an internen Schnittstellen und damit entsteht die Notwendigkeit, diese zu testen. Die Kommunikation der Services untereinander geschieht dabei nicht zufällig, sondern folgt klar definierten Regeln, den sogenannten Schnittstellen-Contracts.

Was ist Contract Testing?

Wie bereits angesprochen, wurde die korrekte Zusammenarbeit von API und Consumer meist durch Integrationstests sichergestellt. Da diese allerdings eine lauffähige Systemlandschaft benötigen, können Fehler erst relativ spät erkannt werden. Bei der Entwicklung ist es jedoch von Vorteil, das Feedback so früh wie möglich zu erhalten. Hinzu kommt, dass Integrationstests eigentlich zum Prüfen der Fachlichkeit dienen. In heutigen Testlandschaften stellen sie strenggenommen „nur nebenher“ fest, wenn es technische Probleme an der Schnittstelle gibt. Das kann sowohl bedeuten, dass der Aufwand bei der Fehlersuche steigt, weil neben fachlichen Problemen auch technische Ursachen zum Fehlschlag des Tests führen können, als auch der Wartungsaufwand der Tests sich erhöht.

Macht also Sinn, dedizierte Tests zu nutzen, um Fehler an Schnittstellen zu finden. Hier bietet sich Contract Testing, genauer gesagt, Consumer Driven Contract Testing (CDCT) an. Verträge für Softwarekomponenten. Der Zusatz „Consumer Driven“ bedeutet, der Consumer bestimmt den Vertrag (Aus diesem Grund nennt man es auch Consumer Contract) und das sich die API nach dessen Vorgaben richten muss.

Neben Consumer Contracts gibt es die etwas verbreiteteren Provider Contracts wie WSDL-/XML-Schemata von SOAP-APIs oder Werkzeuge wie Swagger im Kontext von REST-Services.

Auch wenn sich die Funktionsweise von Framework zu Framework unterscheidet, bleibt die Idee dahinter gleich. Der Provider erfüllt den vom Consumer definierten Vertrag.

Der Vertrag enthält die API samt Parameter und die erwartete (minimale) Antwort. Dabei kann die Beschreibung der Parameter durch den Einsatz von regulären Ausdrücken beliebig präzise sein. So kann der Consumer erwarten, beim Aufruf der API einen unbestimmten String-Parameter oder einen bestimmten String-Parameter aus einem vordefinierten Set zu übergeben. Der zweite Fall ist äußerst hilfreich, wenn der Provider diesen String-Parameter in einen Enum-Wert übersetzt.

Der Consumer Test mit Pact

Sämtliche Verträge zwischen dem Consumer und dem Provider werden in einer JSON-Datei, auch Pact-Datei genannt, definiert. Der Consumer generiert diese Pact-Datei beim Ausführen seiner Pact-Tests und veröffentlicht sie auf dem Pact-Broker. Bei den Tests handelt es sich um gewöhnliche Unit-Tests und sie basieren auf einem der vielen von Pact unterstützen Test-Frameworks wie JUnit oder Jest. In dem Test ruft der Consumer die zu testende API inklusive Parameter auf. Der Aufruf wird von einem Mock-Provider, der vom Pact-Framework zur Verfügung gestellt wird, entgegengenommen. Der Mock-Provider prüft, ob dieser Aufruf mit dem Aufruf aus dem Vertrag übereinstimmt. Sind keine Abweichungen gefunden, antwortet der Mock-Provider mit der minimalen Antwort, die ebenfalls aus dem Vertrag stammt. Der Consumer empfängt in seinem Test die Antwort und vergleicht sie mit seiner Erwartung. Stimmen sie überein, ist der Test erfolgreich. Auf diesem Weg stellt der Pact-Test sicher, dass der Consumer den Aufruf tätigen und die Antwort verarbeiten kann.

Der Pact-Broker ist ein Webserver, der sowohl vom Consumer als auch vom Provider erreichbar sein muss. Er verwaltet die Verträge, indem er sie versioniert ablegt, sie dem Provider zur Verfügung stellt und die Testergebnisse speichert. Die Art und Weise wie der Consumer die Verträge auf dem Pact-Broker veröffentlicht, ist abhängig von der eingesetzten Programmiersprache der Tests und/oder dem eingesetzten Dependendency-Management. Für Maven beispielsweise gibt es ein spezielles Pact-Plugin, das den publish-Goal anbietet, für JavaScript existiert hingegen eine spezielle Pact-Version mit dem Namen Pact-js.

Der Provider Test

Analog zum Consumer-Test ist der Provider-Test auch ein Unit-Test und wird im Rahmen der restlichen Unit-Tests ausgeführt. Hierbei werden alle Verträge, die der Provider mit seinen Consumern abgeschlossen hat, vom Pact-Broker heruntergeladen. Der Aufruf der APIs erfolgt lokal, sodass ein Aufruf durch den Consumer simuliert wird. Der Provider verarbeitet den Aufruf und generiert seine Antwort, die mit der erwarteten Antwort aus dem Vertrag verglichen wird. Sollten sie gleich sein, hat der Provider den Pact-Test bestanden. Ansonsten gilt der Test als fehlgeschlagen und das Artefakt des Providers kann nicht ordnungsgemäß gebaut werden. Die Ursache für Fehlschläge sind in den meisten Fällen Code-Änderungen am Provider ohne den Consumer entsprechend angepasst zu haben oder die Erwartungshaltung des Consumers ist fehlerhaft. In beiden Fällen wird durch CDCT ein Missstand aufgedeckt, der erst zur Laufzeit bemerkbar gewesen wäre.

Alternativen zu Pact

Natürlich ist Pact nicht das einzige Framework zum Implementieren von CDCT, wenn auch aktuell eines der am weitesten verbreiteten. Neben Pact existieren noch ein paar weitere Möglichkeiten für das vertragsbasierte Testen wie Postman, Spring Cloud Contract Project oder Dredd, auf die ich noch in zukünftigen Beiträgen eingehen werde. Aus diesem Grund erfolgt auch das Fazit erst, wenn ich ein paar Vergleiche aufstellen kann.

Der Beitrag Pact.io – Für die nahtlose Integrationstestautomatisierung durch Contract Tests erschien zuerst auf CEOsBay.

Maven vereinfacht den Softwareerstellungsprozess, bietet ein einheitliches System für die Entwicklerarbeit, hochwertige Projektinformationen, Richtlinien für das Festlegen von Best Practices und erleichtert die Migration zu neuen Funktionen durch mehr Transparenz. Es beschreibt sowohl, wie Software gebaut wird, als auch deren Abhängigkeiten. Apache hilft sowohl bei der Verwaltung von Projekten und dient als Tool zum Verständnis. Es hilft also dabei, den Zustand eines Projekts zu organisieren und relativ schnell darzustellen.

Primär wird das Programm von Entwicklern und Projektmanagern bei Java-Anwendungsprojekten verwendet. Das Tool kann nützlich sein, um den Zustand eines Projektes auf einem Blick für technisch weniger versierte Personen, wie Führungspersönlichkeiten und Investoren, zusammenzufassen und gleichzeitig, um einige Prozesse bei der Softwareentwicklung zu automatisieren.

Maven basiert auf dem Objektmodell. Projekte werden als eine Pom.xml-Datei gespeichert. Das Tool verwaltet Projekt-Builds, Reportings und Dokumentationen aus einer zentralen XML-Informationsbasis. Mit der Standard-Plug-in-Architektur kann man es über den Standard-Input mit so gut wie jeder Anwendung nutzen und kollaborieren. Es vereinfacht den Prozess für das Erstellen von Java-Anwendungen erheblich, sodass der Nutzer den Status des Projektes viel einfacher einschätzen kann.

Der Name Maven kommt aus dem Jiddischen und bedeutet so viel wie „Sammler des Wissens“.

Kurze Zeitreise

Maven entstand in der Apache Software Foundation aus Frust über den Build-Prozess von Turbine. Es wurde bald zum Top-Level-Projekt aufgrund der Notwendigkeit, die Builds der vielen unterschiedlichen Projekte der Apache Software Foundation möglichst zu vereinheitlichen und somit auch zu vereinfachen.

Durch die vereinheitlichten Strukturen konnten Mitglieder unterschiedlicher Entwicklungsteams zwischen den einzelnen Teilprojekten wechseln und produktivere Arbeitsergebnisse erzielen. Dank der projektübergreifenden Standardisierung war es nicht mehr notwendig, sich in komplizierte Prozesse einzuarbeiten, um das Projekt ausführen und testen zu können.

Die Entwicklung von Maven 1 wurde im Jahr 2003 begonnen und am 13. Juli 2004 als Version 1.0 veröffentlicht. Die Umsetzung wurde jedoch sehr schnell realisiert, sodass einige Eigenheiten nicht bedacht wurden. Beispielsweise gab es Probleme bei der Performance sowie einen Überschuss an Konfigurationsdateien und -angaben, die es zu beherrschen galt. 2014 wurde das End of Life (EoL) von Maven 1 verkündet. Die letzte veröffentlichte Version ist 1.1 vom 25. Juni 2007.

Im Jahr 2005 wurde parallel damit begonnen, Maven 2 zu entwickeln, welches mit Version 2.0 am 19. Oktober 2005 fertiggestellt wurde. Mit dem Major-Release 2 wurde Maven von Grund auf überarbeitet und bekannte Probleme aus der Vorgängerversion wurden behoben. Aus diesem Grund sind Maven 1 und Maven 2 untereinander inkompatibel. Am 18. Februar 2014 wurde das End of Life von Maven 2 kommuniziert. Die letzte veröffentlichte Version ist 2.2.1 aus November 2009.

Die Entwicklung von Maven 3 begann im Jahr 2008, bei der man sich insbesondere auf die Kompatibilität zwischen Maven 2 und 3 konzentrierte.

In der zweiten Hälfte des Jahres 2021 wurden die Arbeiten an Maven 4 begonnen. Eine wesentliche Verbesserung ist die stark optimierte Unterstützung von Multi-Modul-Projekten.

Wie funktioniert Maven?

Maven benötigt zur Ausführung eine Java virtuelle Maschine (JVM) und ist aufgrund dieses Umstandes plattformunabhängig. Aus diesem Grund kann es auf jedem Betriebssystem ausgeführt werden, für das eine Java VM verfügbar ist.

Der Kern von Maven ist mit wenigen Megabyte als Paket kompakt gehalten. Die interne Struktur ist modular aufgebaut. Sämtliche Funktionen werden über Erweiterungen, sogenannte Plugins, bei der erstmaligen Verwendung über ein öffentliches im Internet verfügbares Repository, Maven Central genannt, nachgeladen und in einem lokalen Repository abgelegt.

Maven ist deklarativ und basiert auf zwei wesentlichen Paradigmen. Zum einen auf „Don’t Repeat Yourself“ (DRY bzw. Wiederhole dich nicht selbst) bedeutet sinngemäß im Kontext von Maven, dass man nicht bei jedem Projekt dieselben Build-Schritte neu definiert muss. Und auf „Convention over Configuration“ (CoC bzw. Konvention vor Konfiguration). Dies bezieht sich auf die Konfigurationsdatei (POM), mit denen Maven-Projekte beschrieben werden. Durch festgelegte Konventionen haben möglichst viele Konfigurationseinträge gemeingültige Vorbelegungen (Default-Werte), die für die meisten Anwendungsfälle bereits die erwünschten Ergebnisse produzieren.

Maven folgt den beiden beschriebenen Paradigmen über den gesamten Zyklus der Softwareerstellung konsequent. Eine wichtige Voraussetzung für eine erfolgreiche Automatisierung der einzelnen Schritte des Softwareerstellungsprozesses sind strikte Vereinheitlichungen, wie sie durch die beiden Paradigmen DRY und CoC geschaffen werden.

Obwohl Maven bereits sehr viele Vorgaben liefert, können Projekte diese Vorgaben an ihre tatsächlichen Bedürfnisse anpassen. Sowohl für künftige neuere Versionen von Maven als auch bei der Anbindung von Drittanbieterprodukten ist es eine bewährte Praxis, möglichst nahe am Maven-Standard zu bleiben.

Wichtige Begriffe bei der Arbeit mit Maven

Im Zusammenhang mit Maven werden wichtige Begriffe verwendet, mit denen man vertraut sein sollte, um effektiv damit zu arbeiten:

• Artifacts (Artefakte) Diese werden in Maven sowohl Plugins als auch Abhängigkeiten zu externen Programmbibliotheken und die selbst erstellten binären Programmdateien des eigenen Softwareprojektes bezeichnet.
• Lifecycles (Lebenszyklen) Dies kann auch als Workflow oder Prozess verstanden werden. Maven kennt drei Lifecycles: „clean“, „site“ und „build“.
• Phases (Phasen) In diesen werden die einzelnen Schritte innerhalb eines „Lifecycles“ bezeichnet, die in festgelegter linearer Reihenfolge durchlaufen werden. Der Build-Lifecycle Default kennt 23 Schritte.
• Goals (Ziele) Sind einzelne Aktionen bzw. Funktionalitäten, die in einem Plugin bereitgestellt werden.
• Archetypes (Archetypen) In diesen können Gerüste für unterschiedlichste Arten von Softwareprojekten erstellt werden, deren Struktur dem Standard von Maven entspricht. Was auch als ein wesentliches Merkmal von Maven-Projekten ist. Die einheitliche Verzeichnisstruktur, auf die ich nachfolgend eingehen werde.

Verzeichnisstruktur

my-project/ – Wurzelverzeichnis

pom.xml – Projektbeschreibung (Build-Logik)

src/ – alle Eingabedateien

main/ – Eingabedateien für die Erstellung des eigentlichen Produkts

java/ – Java-Quelltext-Dateien

resources/ – Projektdateien, die kein Java-Quellcode sind, aber für die Übersetzung oder zur Laufzeit benötigt werden, z. B. Bilder, SQL, Java-Properties-Dateien etc.

test/ – Eingabedateien, die für automatisierte Testläufe benötigt werden

java/ – Testfälle, die als Java-Quellcode vorliegen, z. B. JUnit-Testfälle

resources/ – Zusätzliche Ressourcen für Testfälle

target/ – Alle durch Maven während des Build-Vorgangs erstellten Dateien

classes/ – kompilierte Java-Klassen

Die Konfigurationsdatei „pom.xml“

Die Konfigurationsdatei für Maven-Projekte hat die offizielle Bezeichnung „Project Object Model (POM)“und ist als pom.xml im Wurzelverzeichnis des Projektes abgelegt. Im Kontext des Build-Managements ist die pom.xml die Build-Logik, die von externen Werkzeugen wie dem Automatisierungsserver Jenkins aufgerufen wird. Über Jenkins habe ich bereits geschrieben.

Die zwingenden Basisangaben für ein Projekt innerhalb einer POM sind die sogenannten GAV-Parameter, zuzüglich des Packagetyps. GAV steht für (G) = GroupID, (A) = ArtifactId und (V) = Version. Die GAV-Koordinaten müssen für jedes Projekt eindeutig sein und dürfen nicht mehrfach Verwendung finden.

Abhängigkeiten bzw. (Dependency Management)

Einer der wichtigsten Faktoren für den Erfolg von Maven ist der einfache Umgang mit fremden Abhängigkeiten, sogenannten 3rd Party Libraries. Externe Abhängigkeiten werden in der pom.xml notiert und über ihre GAV-Koordinaten eindeutig und transitiv aufgelöst. Die definierten Abhängigkeiten werden nicht physisch in die Versionsverwaltung mit aufgenommen, sondern während des Buildvorgangs im Projekt-Ausgabeverzeichnis target bereitgestellt.

Bei der Verwendung eines Artefaktes prüft Maven, ob es bereits lokal im Repository vorhanden ist. Das lokale Repository ist ein verstecktes Verzeichnis mit der Bezeichnung .m2/repository und findet sich im home-Verzeichnis des am Betriebssystem angemeldeten Nutzers.

Wird von Maven das angeforderte Artefakt im lokalen Repository nicht gefunden, wird in einem öffentlichen Remote-Repository danach gesucht. Bei erfolgreicher Suche wird das Artefakt im lokalen Repository verfügbar gemacht. Das Wichtigste öffentlich frei verfügbare Repository für Java-Artefakte lautet „Maven Central“ und wird von dem Unternehmen Sonatype betrieben.

Es besteht die Möglichkeit, einen eigenen Repository-Server zu betreiben, um selbst erstellte Artefakte im Unternehmen bzw. im Intranet für andere Projekte bereitzustellen oder diese über das Internet zur Verfügung zu stellen.

Wichtige Implementierungen zum Hosten eigener Artefakte sind Sonatype Nexus OSS oder JFrog Artifactory, für die es sowohl freie Community Versionen als auch kommerzielle Enterprise-Varianten gibt. Diese Lösungen können neben den verschiedenen Java-Artefakten auch andere Formate wie beispielsweise Docker Images, RubyGems, .NET nuget oder NPM verwalten. Maven Central, das größte Open-Source-Repository, wird mit Nexus OSS betrieben.

Maven-Lebenszyklen (Lifecycles)

Wie bereits vorher erwähnt, kommen in einem Maven Workflow verschiedene Lebenszyklen zum Einsatz. Diese sind:

• clean (Zum Löschen von Ergebnissen vorheriger Builds, mit den Phasen pre-clean, clean, post-cl
• build (default) (Zum Erstellen eines Projekts im Rahmen der verschiedenen Phasen
• site (Zum Erstellen von Webseiten zur Projektdokumentation und Reports, mit den Phasen pre-site, site, post-site, site-deploy.

Maven geht dabei jeweils von einem Zyklus aus, der bei der Softwareerstellung im Allgemeinen durchlaufen wird. Es muss aber nicht jedes Softwareprojekt alle Phasen des im Folgenden verkürzt dargestellten Default-Zyklus verwenden. Die Standardfunktionalität kann durch die Einbindung von zusätzlichen Plug-ins an die entsprechende Phase erweitert werden.

• validate bzw. validieren (Es wird überprüft, ob die pom.xml und die Projektstrukturen vollständig, valide und gültig sind.
• compile bzw. kompilieren (In dieser Phase wird der Quellcode kompiliert.
• test bzw. testen (Hier wird der kompilierte Code durch das eingebundene Unit-Test-Framework (z. B. JUnit, TestNG) getestet. Maven berücksichtigt dabei in späteren Zyklen, dass Testklassen normalerweise nicht in der auszuliefernden Software vorhanden sind.
• package bzw. verpacken (Das Kompilat wird – ggf. mit anderen nicht kompilierbaren Dateien – zur Weitergabe verpackt. Häufig handelt es sich dabei um eine JAR-Datei.
• integration-test bzw. Integrationstests (Bereitstellen der programmatisch erstellten Integrationstests mittels Behavior Driven Development (z. B. Cucumber, jGiven).
• verify bzw. Gültigkeitsprüfung des Softwarepakets (Überprüfung der Artefakte, ob die festgelegten Spezifikationen erfüllt wurden, D.H. die bereitgestellten Integrationstests werden ausgeführt.
• install bzw. das Kopieren in die lokale Maven-Repository (Kopiert das Softwarepaket ins lokale Maven-Repository, um es dann in anderen lokalen Maven-Projekten verwenden zu können. Dies ist insbesondere für modulare Projekte von Bedeutung.
• deploy bzw. anwenden (Lädt das Softwarepaket in ein entferntes Maven-Repository hoch, wonach es auch anderen Entwicklern global zur Verfügung steht.

Fazit

Hierbei kann man sich relativ kurzfassen. Ein Software-Projekt sollte stehts mit einem vernünftigen Buildmanagement ausgestattet sein. Das Open-Source-Tool bietet sich dabei vor allem bei Java-Projekten an, zumal es selbst auf Java basiert. Es ist ebenso möglich, Maven durch selbst entwickelte Plugins zu erweitern. Aufgrund dieser Eigenschaft wird es auch als Plugin Execution Framework bezeichnet. Man kann damit die Kollaboration bei der Entwicklung durch Programmierer und Projektmanager mit verschiedensten Skill-Sets wesentlich erleichtern bzw. vereinfachen.

Der Beitrag Apache Maven – Projekte inklusive Abhängigkeiten mühelos verwalten erschien zuerst auf CEOsBay.

Git wurde ursprünglich von Linus Torvalds im Jahr 2005 für die Entwicklung des Linux-Kernels entwickelt, wobei andere Kernel-Entwickler zur anfänglichen Entwicklung wesentliche Beiträge geleistet haben. Seit 2005 ist Junio Hamano der Hauptverantwortliche. Wie bei den meisten anderen verteilten Versionskontrollsystemen und im Gegensatz zu den meisten Client-Server-Systemen ist jedes Git-Verzeichnis auf jedem Computer ein vollwertiges Repository mit einer vollständigen Historie und vollständigen Versionsverfolgungsfunktionen, unabhängig vom Netzwerkzugang oder einem zentralen Server. Git ist, wie Anfangs angesprochen, freie und Open Source Software, die unter der GPL-2.0-Lizenz vertrieben wird.

Eine kurze Anekdote über Git und dessen Abbreviatur

Linus Torvalds witzelte sarkastisch über den Namen git (was im britischen Slang „unangenehme Person“ bedeutet): „Ich bin ein egoistischer Mistkerl und benenne alle meine Projekte nach mir selbst. Erst „Linux“, jetzt „Git“. Die Manpage beschreibt Git als „the stupid content tracker“ Die Read-me-Datei des Quellcodes führt weiter aus:
„Git“ kann alles Mögliche bedeuten, je nach Laune (Ich werde dies in der englischen Sprache belassen, da es so wahrscheinlich mehr Sinn macht 😉 ).

• Random three-letter combination that is pronounceable, and not actually used by any common UNIX command. The fact that it is a mispronunciation of „get“ may or may not be relevant.
• Stupid. Contemptible and despicable. Simple. Take your pick from the dictionary of slang.
• „Global information tracker“: you’re in a good mood, and it actually works for you. Angels sing, and a light suddenly fills the room.
• „Goddamn idiotic truckload of sh*t“: when it breaks.

Um Git zu verstehen sind im Prinzip 8 Begriffe relevant. Repository (Kurz: Repo), die Versionskontrolle, Fork bzw. Forking (Gabel bzw. Gabelung), Branch (Verzweigung), Stage (Phase oder Stadium), Modified (modifiziert), Commit (Verbindlichkeit) und Merge (Zusammenführung). Diese Begriffe werde ich nachfolgend beschreiben.

Was ist eine Repository?

Eine Repository, kurz Repo genannt, ist ein Speicherort für Softwarepakete. Oft wird auch ein Inhaltsverzeichnis zusammen mit Metadaten (Metainformationen bzw. -daten sind strukturierte Daten, die Informationen über Merkmale anderer Daten enthalten) gespeichert. Eine Software-Repository wird in der Regel von Source-Control-Managern (SCM) oder Repository-Managern (Ein Repository-Manager ist eine dedizierte Server-Anwendung, die für die Verwaltung von Repositories mit binären Komponenten entwickelt wurde) verwaltet – Dazu teilweise mehr in der Versionskontrolle und in späteren Beiträgen. Paketmanager ermöglichen die automatische Installation und Aktualisierung von Repositories (Deshalb auch „Pakete“ genannt).

Viele Organisationen und Softwarehersteller unterhalten zu diesem Zweck Server im Internet, teilweise kostenlos oder gegen eine Gebühr. Repositories können können verschiedene Programmiersprachen, Betriebssysteme, Spiele oder andere Anwendungen sowie Dokumente und Daten beherbergen. Die Betreiber solcher Repositories stellen in der Regel ein Paketverwaltungssystem zur Verfügung. Folglich Werkzeuge, mit denen Softwarepakete aus den Repositories gesucht, installiert und anderweitig bearbeitet werden können. Viele Linux-Distributionen (Der Begriff Distribution stammt aus dem Lateinischen „distributio“ und hat im Zusammenhang mit Software zwei unterschiedliche Bedeutungen: Softwarepaketierung und Softwareverteilung) verwenden z. B. das Advanced Packaging Tool (APT), das häufig in Debian-basierten Distributionen zu finden ist oder yum in Red Hat-basierten Distributionen. Es gibt auch mehrere unabhängige Paketverwaltungssysteme, wie z. B. pacman, dass in Arch Linux verwendet wird und equo, welches in Sabayon Linux zu finden ist. Ich bin primär mit Debian-basierten Distributionen unterwegs. Werde ich aber in zukünftigen Beiträgen ausführlicher thematisieren.

Was ist Versionskontrolle?

Die Versionskontrolle unterstützt Entwickler bei der Verfolgung und Verwaltung von Änderungen am Quellcode eines Softwareprojekts. Wenn ein Projekt und die Anzahl der Programmierer wachsen, wird die Versionskontrolle unabdingbar. Doch in der Regel kommen sowohl bei kleineren als auch größeren Softwareprojekten mehrere Personen zum Einsatz, die gemeinsam an dem Quellcode arbeiten. Wenn man beispielsweise als Core-Entwickler an einem bestimmten Teil der Codebasis arbeiten möchte, ist es nicht förderlich oder effizient, wenn der Quellcode direkt bearbeitet wird, da zeitgleich noch andere die an dem Projekt beteiligt sind und daran arbeiten. Dies kann am Ende des Tages für ein enormes Durcheinander sorgen 😀

Da man auf dieses Durcheinander gut verzichten kann, arbeitet man als Entwickler mit einer Versionskontrolle „sicher“ durch branching (Verzweigungen) und merging (Zusammenführungen). „Sicher“ in Anführungszeichen, da es auch da einige Stolpersteine gibt 😉

Beim branching dupliziert ein Entwickler den Teil des Quellcodes (Das so genannte Repository bzw. die Repo), der für ihn relevant ist und kann die Änderungen genau an diesem Teil des Codes vornehmen, ohne den Rest des Projekts zu beeinträchtigen. Sobald der Entwickler seinen Teil des Codes ordnungsgemäß fertiggestellt hat, kann er diesen Code wieder in den Hauptquellcode mergen (einbinden), um es offiziell zu machen. All diese Änderungen werden protokolliert, kommentiert und können bei Bedarf eingesehen, kontrolliert oder rückgängig gemacht werden.

Was ist Fork. bzw. Forking?

Ein Fork ist eine Kopie einer Repository. Das Forken einer Repository ermöglicht es, frei mit Änderungen zu experimentieren, ohne das Originalprojekt zu beeinträchtigen. Dieser Begriff wird auch anderweitig genutzt, doch darauf werde ich jetzt nicht weiter eingehen 😀

Was ist Branch bzw. Branching?

Ein Branch (Zweig) ist ein hervorstehender Teil eines Baumes. Etwas, dass aus einem Hauptteil herausragt. So, auch in unserem Kontext. Ein Zweig stellt eine unabhängige Entwicklungslinie dar. Zweige dienen als Abstraktion für den Prozess der Bearbeitung (Stage/Commit). Man kann sie sich als eine Möglichkeit vorstellen, ein neues Arbeitsverzeichnis, einen Bereitstellungsbereich und/oder einen Projektverlauf anzufordern.

Was ist Modified bzw. Modifying?

Modified (Geändert) bedeutet, dass die Datei(en) geändert wurden aber noch nicht in die Datenbank bzw. Repository übertragen wurden.

Was ist Stage bzw. Staging?

Staged (Phase/Stadium) bedeutet, dass eine geänderte Datei in ihrer aktuellen Version markiert wurde, um sie in dem nächsten Commit-Snapshot (Schnappschuss) zu übernehmen.

Was ist Commit bzw. Committing ?

Commits (Verbindlichkeiten) sind die zentralen Bausteineinheiten einer Git-Projektzeitleiste. Sie können als Schnappschüsse oder Meilensteine entlang der Zeitachse eines Git-Projekts betrachtet werden. Commits werden mit dem Befehl „git commit“ erstellt, um den Zustand eines Projekts zu diesem Zeitpunkt festzuhalten. Im Endeffekt wie das Zwischenspeichern mit F5 bei Spielen oder Strg + S bei der regulären Arbeit am Computer. In der Betrachtungsweise einiger interessanter und manchmal nervtötender Zeitgenossen – Lediglich etwas fundamentaler 😉

Merge

Mit dem Merging-Befehl fügt Git einen geforkten (aufgegabelten) Verlauf wieder zusammen. Mit dem Befehl „git merge“ kann man die unabhängigen Entwicklungslinien, die mit dem Befehl „git branch“ erstellt wurden, in einen einzigen Zweig integrieren.

Fazit

Alles in allem sollte dies für eine kurze Erklärung reichen. In naher Zukunft werde ich auch ein Tutorial über die Nutzung von Git schreiben. Sicherlich gibt es heutzutage auch kommerzielle Cloud-Lösungen wie GitHub oder GitKraken, die diese Schritte auf wenige Mausklicks reduzieren und so eine nahtlosere Zusammenarbeit ohne etwaige Vorkenntnisse ermöglichen, doch dies werde ich auch in zukünftigen Beiträgen thematisieren.

Der Beitrag Git – Die Codeverwaltung für effiziente Zusammenarbeit revolutionieren erschien zuerst auf CEOsBay.