Category

Blog

Agile Entwicklung, CI, CD, DevOps und Testautomatisierung: Die neuen Schlüssel zum e-commerce Erfolg!

By | Blog | No Comments

Die weltweite E-Commerce-Landschaft bewegt sich schnell und Hunderte von neuen Online-Shops werden jeden Tag entwickelt. Ein Online-Shop-Besitzer muss seine Konkurrenz genau beobachten und ständig die Benutzererfahrung verbessern. Dies beinhaltet in der Regel das Hinzufügen neuer Features zu einem Online-Shop, und zwar so schnell wie möglich und kontinuierlich.

Im E-Commerce müssen Software-Modifikationen und neue Features sehr schnell ausgeliefert werden. Um kurze Release-Zyklen zu erreichen, auch im Falle von späten Änderungen in den Anforderungen,hat sich die Agile Software-Entwicklung als sehr wertvoll erwiesen. Read More

Übersichtliche Pipelines mit Jenkins

By | Blog | No Comments

In der Praxis sehe ich viele Pipelines mit Jenkins, die nach folgender Praxis erstellt wurden: Man möchte X tun, schlägt in Beispielen nach oder in der Pipeline Steps Reference. Der entsprechende Pipeline Step, modifiziert um die eigenen Parameter landet schließlich im Jenkinsfile. Man möchte Y tun, findet wiederum den richtig parametrierten Step und trägt ihn unter Y in das Jenkinsfile.

Zum Beispiel vielleicht etwa so:
Das Refactoring wird durch das Pipeline-Gestrüpp, das auf dem/den Build-Server(n) entstehen wird, schließlich auch nicht einfacher: Wo optimiert werden kann/muss, wo (wenn überhaupt) noch nach alten Vorgaben gearbeitet wurde, ist schwer auszumachen. Und die Angst, dass Änderungen unvorhersehbare, schwer zu entdeckende Folgen und Seiteneffekte haben, ist mehr als verständlich.

Bei der Erstellung und Pflege der Pipelines mit Jenkins in unterschiedlichen Projekten und Unternehmen macht man oft diese Beobachtungen:

  • Es wird nur ein einziger SCM-Server mit einer einzigen Technologie verwendet.
  • Für die CI wird meist der gleiche User verwendet bzw. wurde eigens dafür eingerichtet.
  • Für alle Projekte wird nur ein Artefakt-Repositorium für die Uploads verwendet.
  • Es gibt es Schritte, die jedem Projekt helfen würden, wenn man sie leicht verfügbar zur Hand hat.

Daraus lassen sich Best-Practices bezüglich der Anwendung der Pipeline-Steps entwickeln:

  • Der checkout-Step kann sehr übersichtlich gekapselt werden.
  • Für den Artefakt-Upload-Step ist dies ebenfalls möglich, egal ob dieser durch Maven/Gradle/Ivy/curl/… gemacht wird.
  • Gleiches gilt für das Herunterladen von Artefakten, die für das Deployment benötigt werden.
  • Hilfsschritte wie den Aufruf eines Config-Management-Systems und das Aufräumen des Workspace nach erledigtem bzw. gescheitertem Deployment können einfach zentral gehalten werden.

Konkrete Beispiele:

wrappedCheckout(relativeURL, localDir, user = ‚jenkins‘)

wrappedUploadArtifact(package, repo = ‚snapshot‘, artifactDir = ‚standardDir‘)

wrappedGetArtifact(package, repo = ‚snapshot‘, artifactDir = ‚standardDir‘)

wrappedCheckout(relativeURL, localDir, user = ‚jenkins‘)

wrappedUploadArtifact(package, repo = ‚snapshot‘, artifactDir = ‚standardDir‘)

wrappedGetArtifact(package, repo = ‚snapshot‘, artifactDir = ‚standardDir‘)

Die Verzeichnisse, aus denen die Artefakte genommen bzw. in das sie abgelegt werden kann vereinheitlich werden (convention over configuration).

Das Befüllen der Konfigurationsdateien, die für Deployment/Provisionierung benötigt werden:

wrappedCMS(package, projectName, version)

Hier können z. B. sensible Daten nach dem Deployment automatisch aufgeräumt werden:

wrappedCleanup()

Der eigentliche Pipeline-Code kann damit auf wenige kurze Zeilen reduziert werden. Eine Ausnahme bildet der eigentliche Build-Step. Oft zeigt sich, dass es bei den Parametern und bei den Build-Werkzeugen und deren Anwendung von Projekt zu Projekt Unteschiede gibt, oft bei gleicher Technologie. Dies erschwert ein effektives Wrapping in der vorgestellten Art.

Wenn wir die Wrappers verwenden und uns an die Konventionen halten, sieht die Pipeline am Anfang dann z. B. so aus:
Der gemeinsam verwendete Code wird am besten im gleichen SCM-System an einem speziellen Ort gepflegt. Dieser kann in die Pipeline entweder durch einen eigenen Checkout, gefolgt von einem load() gebracht werden, oder man nutzt dafür die integrierte Skript-Bibliothek-Funktionalität des Jenkins. Ich werde darauf in einem späteren Beitrag eingehen.

Mythen des Softwaretestens

Die 3+1 Mythen des Softwaretestens

By | Blog | No Comments
Ein Teil der Softwareentwicklung ist auch das Softwaretesten. Softwaretesten ist der Prozess bei dem genau überprüft wird, ob die Software den definierten Anforderungen genügt, es Abweichungen gibt oder die Anforderungen unvollständig umgesetzt wurden und es zu Fehlerwirkungen kommt. Beim Testen beobachtet man also, ob das Verhalten der Software das erwartete ist. Nach ANSI/IEEE Std. 610.12-1990 ist das Testen (engl. “Testing”) “the process of operating a system or component under specified conditions, observing or recording the results and making an evaluation of some aspects of the system or component.

Softwaretesten wird sehr oft unterschätzt. Dadurch dass man als Endkunde die nötige Qualität als selbstverständlich betrachtet, übersieht man gerne welche Prozesse es gibt, bis man zur gewünschten Qualität kommt, und vergisst auch gerne, dass Softwaretesten ein wichtiger Bestandteil der Softwareentwicklung ist. Somit entstehen auch viele Mythen über das Softwaretesten. In diesem Artikel werden wir uns mit 3+1 dieser Mythen befassen und versuchen, diese Mythen zu “knacken”.

Read More