Agile Softwareentwicklung - Nützliche Tricks für den Git-Alltag

In den Beiträgen Agile Softwareentwicklung - Software im Team entwickeln hatte ich mich mit den allgemeinen Begriffen (Contributor, Maintainer, Pull Request / Merge Request, Commit und Issue) beschäft und GitHub Flow kurz erklärt.

In der c't 17/2025 gibt es einen guten Beitrag zum Thema "Git-Stolperfallen im Alltag". Siehe https://www.heise.de/select/ct/2025/17/2519512434440349082.

Dabei werden folgende nützliche Tricks für den Git-Alltag gegeben:

• Wie kann ich verhindern, dass sensible Daten versehentlich in einem Commit landen?
• Stelle sicher, dass Dateien mit sensiblen Informationen (z.B. .env, config.json) in der .gitignore Datei aufgeführt sind.
  
• Wie finde ich heraus, welche Code-Zeile von welchem User kommt?
• git blame <dateiname>
• Für detaillierte Historie:
• git log -L :functionName:<dateiname>
• Für eine bestimmte Zeilenrange:
• git log -L 10,20:<dateiname>
  
• Wie behebe ich einen missratenen Commit vor dem Push? Ich vergesse häufig Dateien oder vertippe mich in der Commit-Nachricht. 
• git commit --amend
  
• In einem Projekt pflegen wir zahlreiche Branches und verlieren häufig den Überblick. Was können wir besser machen? 
• Ein konsistentes Namensschema hilft sofort beim Erkennen des Zwecks eines Branches
• feature/<ticket-id>-<beschreibung>
• bugfix/<ticket-id>-<beschreibung>
• hotfix/<beschreibung>
• release/<version>
  
• Ich habe ein Projekt gestartet, an dem nun weitere Leute mitwirken sollen. Wie sollten die Commits idealerweise aussehen, damit das Projekt wartbar bleibt?
•  Ein guter Commit sollte kurz, präzise und aussagekräftig sein. Ideal ist ein zweigeteilter Aufbau:
• Kurze Zusammenfassung (max. 50 Zeichen)
• Optional: ausführlichere Beschreibung (max. 72 Zeichen/Zeile)
• Ich habe zahlreiche unterschiedliche Änderungen an einer Datei vorgenommen, wie reiche ich diese in mehreren Commits ein? 
• Datei nicht direkt committen, sondern Änderungen stagen
• git add -p <dateiname>
  
• Ein Git-Repository soll auf einen anderen Server verschoben werden. Wie geht das am einfachsten? 
• Repository klonen und auf neuen Server pushen
• git clone --bare <url-zum-alten-repo>
• cd <repo-name>.git
• git remote add new-origin <url-zum-neuen-repo>
• git push --mirror new-origin

 

Datenbank - Warum Transaktionen?

In meinem Beitrag Überblick über Datenbankmanagementsysteme (DBMS) habe ich PostgreSQL im Zusammenhang mit dem Transaktionsverfahren erwähnt. Ich werde kurz erklären, für was Transaktionen im Datenbankumfeld hilfreich sind.

Transaktionen helfen dabei dass Änderungen vollständig und dauerhaft in der Datenbank gespeichert werden. Dies nennt man auch ACID-Kriterien.

Am Besten lässt sich dies mit einem Beispiel aus dem Bankensektor beschreiben "Es soll eine Überweisung von einem Konto auf ein anderes durchgeführt werden":

1. Es wird der Kontostand des einen Kontos um 100 Euro vermindert und soll durch das Programm  später auf dem anderen Konto erhöht werden.
2. Es kommt zu einem Fehler und der Server stürzt genau während dieser Aktion ab.
3. In diesem Fall muss der komplette Vorgang zurück abgewickelt werden, damit keine fehlerhaften Daten in der Datenbank verbleiben.

Die einzelnen Punkte in dem Programm müssen eine TRANSACTION gehüllt werden. Gibt es am Ende  keine Probleme führt man zum Ende den COMMIT Befehl aus. Somit wird sichergestellt, dass immer nur alles oder nichts geändert. Bei Problemen kommt es zu einem ROLLBACK.

Datenbank - Überblick über Datenbankmanagementsysteme (DBMS)

Nach einem Datenbank Artikel zum Thema Universally Unique Identifier (UUID) als Primärschlüssel verwenden, möchte ich in diesem Beitrag einen kurzen Überblick über Datenbankmanagementsysteme (DBMS) geben.

Einen guten Überblick bekommt man durch die Webseite db-engines.com, sie stellt Bestenlisten bereit und berechnet die Popularität von Datenbanken anhand von Suchergebnissen.

Die Oracle-Datenbank, MySQL und Microsofts SQL Server sind die Top 3 der relationalen Datenbanken und sind die erste Wahl für viele Anwendungen.

Möchte man schnell einen ersten Prototypen entwickeln (ohne Administration einer Entwicklungsinstanz mit einer Datenbank hochzufahren), bietet sich zu SQLite an. Eine Bibliothek, die ein DBMS imitiert, aber keinen Serverdienst hochfährt. Die Daten liegen hier in in einer lokal gespeicherten Datei. Siehe auch mein Beitrag SQLite - Import CSV File - existing or new table.

PostgreSQL ist auch eine relationale Datenbank, unterstützt zum Beispiel das Transaktionsverfahren und den Datentyp JSON. Die Daten werden im JSON-Format abgelegt und sind durchsuch- und manipulierbar (ohne reguläre Ausdrücke verwenden zu müssen). Auch bieten die Funkionen LISTEN und NOTIFY eine Event-Driven-Architecture.

Beim Thema NoSQL (schemalose dokumentengestützte Datenbanken) kommt oft MongoDB zum Einsatz. Für ein Objekt was gespeichert werden soll muss somit keine Tabelle mit Spalten und Datentypen angelegt werden. Gleiche oder ähnliche Datenobjekte speichert man hier in einer Collection.

Elasticsearch verwendet man, wenn man große Datenmengen mit viel Text durchsuchbar speichern möchte z.B. für eine Suchmaschine.

REST Webservice - Mittels Postman HTTP-APIs testen

HTTP-Schnittstellen (z.B. REST oder SOAP) werden in fast allen modernen Webanwendungen verwendet. So ist es möglich über eine API Datensätze zu erstellen (PUT), zu lesen (GET), zu ändern oder zu löschen (siehe auch HTTP Request Methods). Fehler in der API sollten mittels Tests (Unittests) schnell gefunden werden, da Fehlfunktion fatale Auswirkungen haben können. Zusätzlich bieten sich aber auch Integrationstests mit Hilfe von Postman an. Auf diese Funktion gehe ich kurz in diesem Artikel ein. Nur so kann sichergestellt werden, das eine Software wie erwartet funktioniert.

Mit Hilfe von Postman kann man die APIs bequem testen und gleichzeitig Funktionen für automatische Tests verwenden.

Der Download von Postman erfolgt unter https://www.postman.com .

Es muss natürlich eine öffentliche REST-API zur Verfügung stehen, ich verwende hier als Beispiel https://www.predic8.de/rest-beispiel.htm, ein Projekt der predic8 GmbH an .

Hilfreich ist zudem die Postman-Dokumentation https://learning.postman.com/docs/introduction/overview/ .

Postman-Collection anlegen

GET https://api.predic8.de/shop/v2/products

Testen kann man jetzt den Request mit einem Klick auf "Send", jetzt wird eine Liste von  Produkten angezeigt.

GET https://api.predic8.de/shop/v2/products/13 => Einzelnes Produkt
GET https://api.predic8.de/shop/v2/vendors/3 => Einzelner Hersteller
GET https://api.predic8.de/shop/v2/orders/4 => Eine Bestellung
POST https://api.predic8.de/shop/products/ => Anlegen eines Produkt

Beispiel Response

{
    "meta": {
        "count": 19,
        "start": 1,
        "limit": 10,
        "next_link": "/shop/v2/products?start=11&limit=10"
    },
    "products": [
        {
            "id": 19,
            "name": "Grapes2,",
            "self_link": "/shop/v2/products/19"
        },
        {
            "id": 18,
            "name": "Grapes1,",
            "self_link": "/shop/v2/products/18"
        },
...
    ]
}

Mit Postman wurde die jeweiligen Endpunkte der API aufgerufen und es gab auch eine Antwort (Response) vom Server, aber ist dies jetzt auch die Antwort welche man erwartet hat?

Integrationstests mit Postman

Beim Aufruf von GET products wird ein Test hinterlegt (Prüfung Statuscode = 200).

• Tab "Tests" anklicken
• JavaScript Code hinzufügen (Postman zeigt im rechten Bereich bereits einige Vorschläge an)

pm.test("Status code is 200", function () {
    pm.response.to.have.status(200);
});

Diese Methode lässt sich einfach erweitern unnd mann den HTTP Status inkl. der zurückgegebenen Daten mit den zu erwarteten Werten abgleichen. 

Auch lassen sich Tests der einzelnen Endpunkte umsetzen und so eine "Reise" eines User nachbauen. Der folgende Test nimmt die ID des Response-Body eines neu angelegten products und schreibt diese in die Variable productId.

const body = JSON.parse(responseBody); pm.collectionVariables.set("productId", body.id);

In den nachfolgenden Requests, kann man diese Variable jetzt mit doppelt geschweiften Klammern verwenden /products/{{productId}} .

Quelle: https://stackoverflow.com/a/58325002

Agile - Argumentationswippe (Pro- und Kontra-Liste)

Gerade bei Retros im Team bzw einer größeren Gruppe werden Pro- und Kontra-Listen an einer Moderationswand gesammelt. Siehe auch zum Beispiel Siehe auch Agile - "Lifehack" Sammlung => Team-/Projekt Retrospektiven.

Eine digitale Alternative ist die Argumentationswippe (https://argumentationswippe.de). 

Die Retro-Teilnehmer sammeln ihre Argumente und können sie so auf die eine oder andere Seite der "Wippe" sortieren.

JSON Crack - Besserer Überblick für komplexe JSON-Daten

Mit Hilfe der JavaScript Object Notation (JSON) ist z.B. ein Datenaustausch zwischen Servern und Applikationen möglich. Die JSON-Daten sind bereits relativ gut strukturiert und in einem Editor lesbar. Verwendet man aber eine Vielzahl von Objekten, kann man dennoch die Übersicht schnell verlieren. Mit Hilfe des Open-Source-Tool JSON Crack kann man den Code sehr schnell in übersichtliche Grafiken umwandeln.

Für JSON Crack ist keine Registrierung erforderlich! Mann öffnet den https://jsoncrack.com/editor im Browser und ersetzt den Beispiel-JSON-Code im linken Teil des Bildschirms durch seinen eigenen oder importiert eine beliebige Datei. Rechts sieht man sofort die Visualisierung des JSON-Codes.

Die aktuelle Grafik kann man als PNG-Datei herunterladen. Dies kann sehr hilfreich sein, um die Visualisierung anderen zu zeigen.

Agile - Open Practice Library (Softwareentwicklung, Produktentwicklung und Teamkultur)

Die Innovation Labs des Softwareherstellers Red Hat betreiben die Website "Open Practice Library". Hierbei geht es um iterative Vorgehensmodelle zur schnellen Entwicklung digitaler Produkte. Das Team dokumentiert hier verschiedene Praktiken und Prinzipien, welche die Softwareentwicklungsprozesse vorantreiben.

Die Einträge sind anhand der Prinzipien Discovery, Options, Delivery und Foundation organisiert:

Quelle: Red Hat Open Innovation Labs - https://openpracticelibrary.com

Discovery-Praktiken beginnen mit dem aktuellen Ist-Zustand und sollen helfen, wichtige Fragen zu Ergebnissen zu stellen.

• Warum tust du das? Welche Probleme versuchen Sie zu lösen und für wen? Wie werden Sie die Ergebnisse messen?
• Siehe z.B. Why, How, What - The golden circle von Simon Sinek
  

Options-Praktiken untersuchen, wie man Erkenntnisse abwägen und möglicherweise die Richtung ändern kann.

• Welche Möglichkeiten hat das Team? Was benötigen Sie möglicherweise, um Ihre Zielergebnisse zu erreichen?
• Siehe z.B. How-Now-Wow Prioritization (Matrix)
  

Bereitstellungs-Praktiken konzentrieren sich darauf, die Optionen bereitzustellen, für die man sich entschieden hat, und Feedback von den Benutzern und Interessenvertretern einzuholen.

• Was war die gemessene Wirkung? Was hast du gelernt?
• Siehe z.B. Canary Release - Exposing a small number of real users to a new version

Grundlegende-Praktiken konzentrieren sich auf die Schaffung einer Teamkultur, Umgebungen für die Zusammenarbeit und technische Praktiken.

• Diese unterstützen schnelle und iterative Reisen durch die anderen Teile der Schleife.
• Ohne die Grundlage können Teams keine nachhaltige, kontinuierliche Bereitstellung erreichen.
• Siehe z.B. Daily Standup - A short time-boxed synchronization of the team activities that occurs in a cadence determined by the team

 

Lasttest - k6 Open Source load testing tool

Bei einem Lasttest werden bei dem zu testenden System Lasten erzeugt. Hierbei wird das Ziel verfolgt zu sehen, ob die Apllikation oder das System diese Last bewältigen kann. So sollte eine Webseite mehreren Besuchern gleichzeitig in akzeptabler Zeit eine Antwort (response) schicken können.

Einen einfachen Einstieg in Lasttests bietet K6, siehe https://k6.io/open-source/ .

Mit dem folgenden Beispiel werden bis zu 1.000 VUs innerhalb 30 sec erstellt:

import http from 'k6/http';
import { sleep } from 'k6';

export const options = {
  stages: [
    { duration: '10s', target: 50 },
    { duration: '10s', target: 100 },
    { duration: '10s', target: 500 },
    { duration: '30s', target: 1000 },
    { duration: '10s', target: 500 },
    { duration: '15s', target: 0 },
  ],
};

export default function () {
 http.get('http://localhost:8080');
 //sleep(1);
}

Quelle: https://github.com/jamct/php-performance/blob/main/load.js

Viele weitere Beispiele und Tutorials finden sich hier https://k6.io/docs/examples/ .

Agile Softwareentwicklung - Software im Team entwickeln (Glossar)

In dem Beitrag "Agile Softwareentwicklung - GitHub Flow notwendig?" habe ich den "GitHub Flow" kurz erklärt. Etwas näher möchte ich auf die allgemeinen Begriffe (Contributor, Maintainer, Pull Request / Merge Request, Commit und Issue) in der Softwareentwicklung im Team eingehen.

Contributor

Wenn jemand als Entwickler etwas zu einem Projekt beiträgt, der darf sich offiziell Contributor (Mitwirkender) nennen. Dies trifft auch dann zu, wenn man nur einen kleinen Tippfehler in der Dokumentation beseitigt, was für viele der Einstieg in ein Open Source-Projekte ist. Da die meisten Softwareprojekte in Regel bei GitHub oder GitLab verwaltet werden, kann man mit einem eigenen Account dort sofort mit der Unterstützung beginnen.

Maintainer

Nicht jeder, kann aber sofort Änderungen am Quellcode oder der Dokumentation vornehmen. Jedes Entwicklungsprojekt benötigt einen oder mehrere Maintainer (Betreuer). Sie haben die Berechtigung, eingereichte Änderungen zu akzeptieren und in den Quellcode aufzunehmen. Zudem kümmern Sie sich um geplanten Funktionen für neue Versionen und legen fest wohin sich das Projekt entwickelt soll.

Pull Request / Merge Request

Möchte man Änderungen an einer Software vornehmen, muss mann zunächst einen neuen "Fork" (Verzweigung) anlegen. Dies ist eine lokale Kopie der aktuellen Code Basis. Jetzt kann man all seine geplanten Änderungen vornehmen. Anschließend kann man einen Request mit seinen Änderungen an das Originalprojekt stellen. Bei GitHub und Bitbucket heißen diese Request "Pull Request" und GitLab nennt sie "Merge Request". Der Maintainer prüft nun die Änderungen und entscheidet, ob sie für eine Übernahme geeignet sind.

Commit

Hinweis: Die Befehle "git commit" und "svn commit" haben denselben Namen, sie unterscheiden sich aber voneinander! Siehe auch https://www.atlassian.com/de/git/tutorials/saving-changes/git-commit.

Hat man seine Änderungen fertiggestellt (z.B. die Programmierung eines neuen Moduls), erzeugt man einen Commit. Dadurch werden die Änderungen als Entwicklungsschritt in die Quellcode-Chronik mit aufgenommen und mit einer kurze Nachricht versehen. Hierdurch sehen auch die anderen Entwickler diese in ihrer Chronik.

Datenbank - Universally Unique Identifier (UUID) als Primärschlüssel anstatt Integer verwenden

Die Verwendung von Tabellen, Spalten, Primärschlüsseln und Sekundärschlüsseln sind die Grundlagen für den Aufbau eines Datenbanksystems. Um die Datensätzen für Verarbeitung-, Zugriffs- und Speicherungszwecken nutzen zu können, werden in der Regel Tabellen  mit einer ID als Primärschlüssel und Sekundärschlüssel angelegt. Als Datenformat verwendet man meistens ein 32-Bit-Integer und aktiviert das automatische Inkrementieren für die ID mit jeder neu angelegten Zeile. Die Verwendung eines 32-Bit-Integer kann aber in bestimmten Situationen zu Problemen führen, welche sich mit Hilfe von einer anderen universell eindeutigen Kennung (UUID) umgehen lässt.

Anhand dem folgenden Beispiel der Tabelle "Raumtechnik", vergibt die Datenbank immer automatisch eine freie ID.

CREATE TABLE Raumtechnik (Id INT NOT NULL AUTO_INCREMENT, Typ VARCHAR(255) NOT NULL, Beschreibung VARCHAR(255), PRIMARY KEY (Id));

Beispiel für ein logisches Datenbankkonzept.

Integer (UNSIGNED INT / BIGINT)

Eine Möglichkeit der Optimierung wäre hier einen vorzeichenlosen Integer (UNSIGNED INT) zu verwenden. Siehe auch "Im Dezember 2014 übertraf die Aufrufzahl von Psys Video „Gangnam Style“ auf YouTube das 32-Bit-Integer-Limit von 2 147 483 647."

Id UNSIGNED INT NOT NULL AUTO INCREMENT,

So lässt sich der Zahlenraum für IDs verdoppeln von 0 bis 4 294 967 295. Für sehr große Projekte sollte daher der 64-Bit-Integer UNSIGNED BIGINT verwendet werden. Aufpassen sollte man hier aber bei Web Applikationen (JSON Format), denn JavaScript-Engines der Browser haben hier irgendwann Probleme.

Probleme von Auto-Increments

Auto-Increments können bei der Verwendung von Datenbank Clustern ggf. ein Problem werden. Denn hier erhält jeder Node einen Schreibauftrag. Damit sie sich nicht bei jedem Insert auf die nächste ID einigen müssen erhöhen die Nodes die ID nicht um +1, es wird um die Anzahl der Nodes im Cluster erhöht.

Verwendet man in seiner Applikation Import- und Export-Funktionen, kann dies in einer relationalen Datenbank (über Schlüssel mit anderen Tabellen verknüpft) beim Importieren von Datensätze aus einer anderen Datenbank zu Problemen führen. So können Einträge bereits existieren und IDs sich doppeln, die Einträge müssten somit neue IDs bekommen und in allen anderen relevanten Tabellen müssen die Fremdschlüssel aktualisiert werden. Je nach dem wie groß der Import ist, kann es hier zu sehr großen verketteten Abhängigkeiten kommen.

Verwendet man IDs in seiner WebAPI (uni.org/klausurergebnis/123), kann dies schnell zum Sicherheitsproblem innerhalb der Anwendung führen. So lassen sich IDs sehr einfach erraten und ggf. fremde Ergebnisse abrufen.
 

UUIDs Universally Unique Identifier

UUIDs können in einer Datenbank als Alternative zum Integer verwendet werden und können die oben beschriebenen Probleme beim Importieren von Daten und Zusammenführen der Datensätze verhindern.

Die UUID (Request for Comments 4122) besteht aus einer 16-Byte-Zahl, ist hexadezimal notiert und in fünf Gruppen unterteilt:

550e8400-e29b-11d4-a716-446655440000

Microsoft nennt dieses Verfahren anders, nämlich GUID (Globally Unique Identifier).

Erzeugen lassen sich die UUIDs unter PostgreSQL mit Hilfe von gen_random_uuid () und bei Microsoft SQL Servern verwendet man beim Anlegen der Tabelle den UNIQUE IDENTIFIER.

CREATE TABLE Raumtechnik (unique_id UUID DEFAULT gen_random_uuid (), Typ VARCHAR(255) NOT NULL, Beschreibung VARCHAR(255), PRIMARY KEY (unique_id));

Zukünftige Konflikte sollten mit der Verwendung von UUIDs so gut wie ausgeschlossen sein, denn eine UUID ist einzigartig und kann nur einmal vergeben werden.

Agile - Priorität und Qualität vom Shopify CEO (Tobias Lütke) lernen

In dem Artikel "Zeitmanagement - MoSCoW Priorisierung / Prinzip" habe ich beschrieben, wie man mit Hilfe des MoSCoW-Prinzip seine Aufgaben priorisieren kann. In dem Artikel "Shopify-Gründer Tobi Lütke: CEOs müssen die Hüter der Qualität sein" beschreibt Tobi Lütke welche Prioritäten man als guter CEO setzen soll.

Shopify bietet für kleine, mittelständische Händler und mittlerweile auch Konzerne ein einfach einzurichtendes Online-Shopsystem samt Hosting und Bezahldiensten.

Lütke empfiehlt die folgende Prioritätenliste, damit CEOs den Fokus auf die Qualität des Produktes setzen:

1. "Lasst uns das bestmögliche Produkt bauen."
2. "Wir müssen ab und zu Geld verdienen, damit wir Prio eins finanzieren können."
3. "Niemals Prio eins und zwei verwechseln."

"Ich finde es interessant, wie häufig Firmen das falsch herum machen. Das ist bis heute eigentlich mein Hauptjob bei Shopify: Herumrennen und jeden daran erinnern, dass es das Wichtigste ist, ein gutes Produkt zu machen. CEOs müssen die Hüter der Qualität sein."

Aus meiner Sicht kann man diese Prioritätenliste auch in der Softwareentwicklung anwenden, wenn es z.B. um "Softwaretest bei agiler Entwicklung durch Testautomatisierung" geht.

Cloud - Open-Source Software im Cloudumfeld

Nach der Vorstellung von "Cloud - Basics (Konzepte, Werkzeuge und Methoden)" gehe ich kurz auf die Open-Source Software im Cloudumfeld ein. Siehe auch CNCF Cloud Native Interactive Landscape.

Docker

• Freie Software der Firma Docker Inc. zur Containervirtualisierung.
  
  

Ansible und Terraform

• Mit Ansible werden die "Rezepte" erstellt, um Cloud Server bestellen und konfigurieren zu können und fungiert als Admin Kommandozeilenwerkzeug. Terraform eignet sich für die Bestellung der Cloud Server bei den Anbietern.
• 
  
  

Git, GitHub und GitLab

• Git ist eine Software zur Versionsverwaltung von Dateien, es lassen sich dabei verschiedene Entwicklungspfade zu verfolgen und so können mehrere Entwickler parallel entwickeln. Siehe auch Agile Softwareentwicklung - GitHub Flow notwendig?.
• GitHub ist einer der weltweit am bekanntesten Hoster für Git-Repositories inklusive Continuous Integration (CI) / Continuous Delivery (CD) Lösungen.
  
• GitLab ist eine Webanwendung zur Versionsverwaltung für Softwareprojekte auf Git-Basis, welche man selber hosten kann.
  
  

Kubernetes (k8s)

• Automatisiert den Betrieb von Container, sprich Kubernetes verwaltet somit die Cluster von Servern, die wiederum Container ausführen.
  
  

OpenStack

• Ist der "Baukasten" für Cloudserver und soll Unternehmen dabei unterstützen den Aufbau eigener Clouds zu erleichtern um die eigene digitale Souveränität zu gewährleisten.
  
  

S3 (Simple Storage Service)

• S3 wurde von Amazon entwickelt und kann man als Blockspeicherplatz-Angebot beschreiben. Dateien werden in Buckets (Ordner ohne Verschachtelung) abgelegt. Der Zugriff erfolgt über HTTP / HTTPS. Es ist sehr gut skalierbar und somit wird es gerade von Dropbox oder auch Netflix zum Ablegen von Dateien aller Art verwendet.
  
  

Cloud Native Computing Foundation (CNCF)

• Ein Projekt der Linux Foundation um Cloud Computing, Microservices und Containervirtualisierung zu fördern.
• Siehe auch https://github.com/cncf/landscape/blob/master/README.md#trail-map.

 

Cloud - Basics (Konzepte, Werkzeuge und Methoden)

Nach meinem Artikel "Cloud - Pizza as a Service: Was hat eigentlich "Pizza" mit Cloud Services zu tun?" gehe ich in diesem Beitrag auf die "Cloud Basics" ein. Hierbei handelt es sich um Werkzeuge und Methoden, welche vor einer möglichen Umsetzung / Einführung / Migration unbedingt bekannt sein sollten.

CI/CD (Continuous Integration/Continuous Delivery)

Release early, release often - Mit Hilfe der CI/CD-Pipelines, welche in einem agilen Softwareprojekt zwingend erforderlich sind, welche den Prozess des fortlaufenden Zusammenfügens von Komponenten hin zu einer Anwendung garantieren, müssen Änderungen am Quellcode bzw. neue Funktionen nicht mehr bis zum nächsten großen Release gesammelt werden. Siehe auch "Agile Softwareentwicklung - GitHub Flow notwendig?".

Änderungen am Quellcode, die in der Versionsverwaltung eingecheckt werden, können sofort automatisch von Skripten getestet (siehe auch Softwaretest bei agiler Entwicklung durch Testautomatisierung) und zu einem auslieferungsfähigen Paket verpackt werden.

Die Tools der Wahl sind hier zum Beispiel Jenkins (build, test, and deploy their software) oder GitHub Actions, GitLab (end-to-end software development platform with built-in version control, issue tracking, code review), Maven (build automation tool used primarily for Java projects) und Nexus (software repository manager).

Cloud-Native

Entwickler bezeichnen Software als Cloud-Native, welche die Vorteile der Cloud im eigenen Rechenzentrum (Flexibilität, Skalierbarkeit und Reproduzierbarkeit) bieten. Die Software ist daher in der Regel für den Betrieb in Containern (Raspberry Pi - Docker installieren) optimiert und kann somit auf eigenen oder auf gemieteten Servern laufen.

Container

Hier erfolgt eine Isolierung von Anwendungen mit Hilfe von Containervirtualisierung (siehe z.B. Raspberry Pi - Docker Compose installieren). Sie nutzen den Kernel des darunterliegenden Betriebssystems und blockieren somit keinen Arbeitsspeicher und haben nur eine sehr geringe Bootzeit. Alle Abhängigkeiten sind enthalten, dadurch lassen sich Container schnell starten, vervielfältigen, auf anderen Servern oder auch ganze Rechenzentren übertragen.

DevOps

Die Entwickler und der Betrieb / Service einer Software (Development und Operations) werden bei diesem Modell nicht hart getrennt, sondern arbeiten eng miteinander zusammen. Flexible Mietserver und Konzepte aus dem Cloudumfeld (zum Beispiel CI/CD) unterstützen dabei, die DevOps Methoden umzusetzen.

Hybrid 

In der Regel wird nicht die komplette Serverinfrastruktur eines vorhandenen Rechenzentrums durch Cloud-Infrastruktur ersetzt. Dies ist vor allem der Fall, wenn es um besonders sensible Daten geht. Die lokale Software sollte aber idealerweise "Cloud-Native" sein, damit Hybride Strategien gut funktionieren. Die restliche Software kann dann in der flexiblen Public Cloud betrieben werden.

laaS (Infrastructure as a Service)

Hierbei handelt es sich eigentlich um Marketing Kreation der Cloud Anbieter. Hierbei kann man Angebote oder Dienste zum Minutenpreis mieten, oft auch Platform as a Service (PaaS) genannt. 

Infrastructure as Code

Die Infrastruktur lässt sich immer wieder neu einrichten. Die jeweils gewünschte Konfiguration wird z.B. in Dateien mit YAML-Format beschrieben. Mit Hilfe von Terraform oder Ansible erfolgt dann die Umsetzung im Cloud-Umfeld.

Public Cloud & Private Cloud

Siehe hierzu auch "Hybrid" Beschreibung oben, Public Cloud sind Angebote für flexibel abgerechnete Server und weitere Dienstleistungen. Private Cloud sind eigene physische Server, welche zum Beispiel mit der Software Open Stack verwaltet werden.
Unternehmen, die idealerweise mit cloud-nativen Tools arbeiten, haben sie die Möglichkeit ihre Dienste jederzeit aus der "Private Cloud" in eine "Pubilc Cloud" zu migrieren.

 

Semantic Versioning

Es handelt sich um eine Standardisierung der Software-Versionierung. Sie besteht aus drei Zahlen (1.3.08) besteht: Die major version (1), minor version (3) und patch version (08). Siehe auch https://semver.org/lang/de/.

SaaS (Software as a Service)

Analog zu IaaS, Software wird zum Monatspreis an Kunden vermietet. Man muss sich nicht um die Administration, Updates oder Backups der Software kümmern. In der Regel laufen die Anwendungen auf Cloud-Infrastruktur wie zum Beispiel Amazon (aws).

Vendor Lock-in

Beschreibt die Befürchtung, dass man mit der Entscheidung für eine Software oder Service im Dienstleisteruniversum eingesperrt ist. Dies kann man mit der Verwendung von Open-Source-Software aus dem Cloud-Native-Umfeld umgehen. Als Beispiel ist hier Kubernetes als Plattform für seine Container und eigenen Betrieb von Open-Source-Software selbst genannt.

Scrum - Sprint / Team Retrospektive

Die Sprint Retrospektive findet am Ende des Sprints statt. Hierbei überprüft das gesamte Scrum Team seine Arbeits- und Verhaltensweise während des Sprints, um im nächsten Sprint noch effektiver und effizienter arbeiten zu können.

Ablauf

• Es sollte eine angenehme Atmosphäre für das Team geschaffen werden,
• z.B. durch den Raum, der Umgebung und dem Zeitpunkt,
• jedes Teammitglied sollte Zeit für die Vorbereitung auf den Termin haben.
• Die Daten werden vom Scrum Master gesammelt (Erkenntnisse und Einsichten) und z.B. auf einem „Board“ festgehalten.
• Abschließend werden Aktionen und Verbesserungsmöglichkeiten daraus abgeleitet.

Beispiel

• Eine Pinnwand mit den Symbole: "Gewitter", "Regen", "Sonne".

Quelle: https://cdn.pixabay.com/photo/2013/07/12/12/53/weather-forecast-146472_1280.png

• Jeder im Team bekommt 3 Karten, für jede Kategorie eine und gibt Feedback zu den folgenden Fragen:
  
• Gewitter - Was hat mich im letzten Sprint wütend gemacht hat?
• Regen - Was hat mich im letzten Sprint traurig gemacht hat?
• Sonne - Was hat mich im letzten Sprint froh gemacht hat?
  

Eine nächste (Team) Retrospektive steht an und man hat keine Ideen für einen Ablauf? Dann kann ich die Seite https://retromat.org/de/ empfehlen. Hier kann man sich zufällig Ideen für eine Retro generieren lassen.

Raspberry Pi - Temperatursensor DS18B20 - Update I

Kurzes Update für den Artikel Raspberry Pi - Temperatursensor DS18B20. Jetzt gibt es ein Python Script, welches direkt die ID des Sensors herausfindet.

Mit dem Script temperatur.py ist es nicht mehr notwendig die ID (/sys/bus/w1/devices/xx-xxxxxxxxxxxx/w1_slave) des Sensors manuell anzupassen.

Download: wget https://www.shemel.de/download/raspberry/temperatur.py

Agile Softwareentwicklung - GitHub Flow notwendig?

Ist der GitHub Flow bei einem agilen Entwicklungsteam überhaupt noch notwendig?

 

GitHub Flow kurz erklärt

Wird eine neue Funktion in einem Softwareprojekt entwickelt, dann erstellt der Entwickler in der Regel einen "neuen Branch". Ist die Entwicklung der neuen Funktion abgeschlossen, wird ein "Pull Request" erstellt und zusammen mit dem Team besprochen. Mit Hilfe von automatischen Tests (siehe auch Unit-Tets - Was ist automatisches Testen?) wird sichergestellt, dass der neue bzw. angepasste Quellcode auch funktioniert. Anschließend kann der zuvor neu erstellte "Branch" in den "Master-Branch" übernommen werden.

Siehe hierzu auch "Following the GitHub flow":

Quelle: https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/github-flow#following-the-github-flow

Continuous Integration (CI) / Continuous Delivery (CD)

Mit Hilfe der CI/CD-Pipelines, welche in einem agilen Softwareprojekt zwingend erforderlich sind, welche den Prozess des fortlaufenden Zusammenfügens von Komponenten hin zu einer Anwendung garantieren, müssen Änderungen am Quellcode bzw. neue Funktionen nicht mehr bis zum nächsten großen Release gesammelt werden. Auch das "große" gemeinsame Testen und das "Live setzen" zu einem festgelegten Termin ist nicht mehr erforderlich. Siehe auch Softwaretest bei agiler Entwicklung durch Testautomatisierung .

Kleine Anpassungen sollten immer so schnell wie möglich getestet und abgenommen werden, damit diese sofort veröffentlicht werden können. Die sogenannten "Release Branches" sind damit hinfällig.

Wenn jede kleine neue Funktion oder Korrektur von Fehlern (Bugs) nach erfolgreicher Testautomatisierung und Abnahme durch den Fachbereich im Live System zur Verfügung steht, dann werden auch keine "Hotfixes" mehr benötigt (Hotfixes = Feature). Fehlerbehebungen müssen somit nicht in einer "veralteten Version" erfolgen (Forward Fixing und nicht Rolling Back).

Was bleibt zum Schluss übrig?

Die Entwickler arbeiten nur noch mit dem "Master-" und dem "Feature-Branch".

Swagger - Interface Definition Language (IDL) für REST-APIs

Mit Hilfe des Swagger-Editor unter http://editor.swagger.io oder einem Plug-in für die Entwicklungsumgebung (z. B. für IntelliJ) kann man sehr schnell einen ersten API-Ansatz mit Hilfe der vorhanden Schnittstellenbeschreibung erstellen.

Es kann auch eine bestehende API-Dokumentation per URL importiert werden und der online Editor von Swagger zeigt rechts direkt eine Vorschau der API-Definition in einem "menschenfreundlichen" Format.

Unit-Tets - Was ist automatisches Testen?

Der Zusatzaufwand für automatische Tests lohnt sich in der Regel schon nach wenigen Releases. Die Tests helfen den Entwicklern dabei Fehler im Voraus zu vermeiden und den Quellcode gut zu strukturieren.

Manuelles Testing

Das Testing von umgesetzten Anforderungen nimmt immer eine gewisse Menge Zeit in Anspruch. Oft werden hierbei Fehler übersehen um z.B. Zeit zu sparen oder es werden nicht alle Testfälle "durchgespielt".

Dieses "manuelle" Testing hat in der Regel weitere Releases zur Folge und der gesamte Test-Zyklus muss wiederholt werden. Dies kann dann für alle Beteiligten (Anforderer, Product Owner, Entwickler usw.) eine sehr stupide Tätigkeit werden. Hieraus ergibt sich die Empfehlung für die Einführung von automatischen Tests (Unit-Test).

Unit-Tests

Unit-Tests sind kleine Programme, welche die umgesetzten Anforderungen testen und prüfen, ob sie die Erwartungen der Anforderer erfüllen. Wichtig, jeder automatische Test sollte immer nur eine Eigenschaft einer Methode überprüfen (ein zu erwartender Output). Nichts desto trotz muss natürlich die jeweilige Methode vollständig (Verzweigungen, Sonderfälle usw.) getestet werden und so werden viele kleine Tests benötigt. Man spricht hierbei auch von vielen kleinen Einheiten (Units).
Die Tests müssen zusätzlich zu den Anforderungen programmiert werden, so fallen bei einer "testgetrieben Entwicklung / Test Driven Development" höhere Aufwände an. Das Verständnis dafür sollte vorher beim Auftraggeber eingeholt werden.

Idealerweise stehen die Testfälle vorab für die Entwickler zusätzlich zu den Anforderungen (in der Regel als User Story beschrieben) bereit. So besteht die Möglichkeit zuerst die Unit-Tests zu entwickeln und im Nachgang erfolgt die Umsetzung des eigentlichen Quellcodes für die Anforderungen. Dies hilft den Entwicklern den Quellcode besser zu strukturieren und intuitive Ideen für die Umsetzung zu entwickeln. Ein weiterer Vorteil ist, dass jede Implementierung (Eincheken/Commit) bereits auf Basis der Unit-Tests überprüft wird. So können einzelne Funktionen (Features) gezielt umgesetzt werden, ohne die komplette Umsetzung der Anforderungen in Gänze in einem Schritt entwickeln zu müssen.

Werden im Anschluss die umgesetzten Funktionen in ihrer gesamten Komplexität getestet, spricht man von Integrationstests.
Siehe hierzu auch meinen Beitrag vom März 2018 "Softwaretest bei agiler Entwicklung durch Testautomatisierung".

Fazit

Wurde das Projekt mit automatischen Tests ausgestattet, ist das Entwickeln effizienter und macht mehr Spaß!

So kann man zum Beispiel beim Refactoring schon sagen, welche Anpassungen am Quellcode notwendig sind, damit dieser korrekt funktioniert. Beim Einchecken einer Codeänderung in das Versionsverwaltungssystem werden die Tests gestartet und können den Commit z.B. automatisch zurückweisen (erstellen eines Issue), wenn diese fehlschlagen.

Gerade bei größeren Softwareentwicklungsprojekten zahlt sich der anfangs zusätzliche Aufwand im Nachgang wieder aus. Entwickler und Tester sparen mit jedem weiteren Release Zeit, das Refactoring wird optimiert und es treten zwangläufig weniger Fehler auf (im Vergleich zum manuellen Testing).

Entwicklungsumgebung Thonny für Python

Hat man bereits Raspbian "Stretch" für Raspberry Pi installiert, ist vermutlich "Thonny" bereits bekannt.

Thonny ist eine integrierte Entwicklungsumgebung für Python, die für Anfänger geeignet ist. Auch für Windows und Mac kann man die IDE unter https://thonny.org/ herunterladen.

Softwaretest bei agiler Entwicklung durch Testautomatisierung

Das Testen von Software bzw. eines fertigen Teilprodukts (Product Increment) ist ein fester  Bestandteil der agilen Softwareentwicklung und somit auch ein festes Element während eines Sprints.

Gerade bei Testfällen, die sehr oft wiederholt werden, ist eine Automatisierung sinnvoll (z.B. Regressionstests, testgetriebene Entwicklung oder schwer durchführbaren Tests). Viel zu oft wird gerade bei nicht automatisierten Tests die Anwendung nicht ausgiebig genug getestet.

Folgende Grundsätze sollten daher angewendet werden:

• So viel Testautomatisierung wie möglich, damit bei vielen neuen oder sich ändernde Anforderungen ein lauffähiges System gewährleistet wird. Darunter fallen Unit Tests, System- und Akzeptanztests.

• Die Rolle "Tester" innerhalb des Entwicklungsteam verteilen, damit die Zuständigkeit innerhalb des Entwicklerteams gleich ist. Keine strikte Trennung zwischen Entwickler und Tester aufbauen!

• Teststufen des V-Modells (Einordnung von Testzyklen) aufheben, da dies innerhalb eines Sprints nicht umsetzbar ist und einen zu hohen zeitlichen Aufwand bedeutet. Die einzelnen Teststufen (Komponententest, Integrationstest usw.) sollte als kleine Einheiten innerhalb der einzelne User-Stories integriert oder teilweise als einzelne User-Story je Sprint geplant werden

• Der finale Abnahmetest (User Acceptance Test) erfolgt jeweils am Ende eines Sprints durch den eigentlichen Auftraggeber oder Product Owner.

• Continuous Integration, der Prozess des fortlaufenden Zusammenfügens von Komponenten hin zu einer Anwendung, hat das Ziel zur Steigerung der Softwarequalität. Hier erfolgt ein Zusammenspiel von einem Versionsverwaltungssystem z.B. SVN oder GIT, einem Artifactory z.B. Nexus, automatisierter Tests (z.B. JUnit) und einem Tool (z.B. Jenkins ) zur Verwaltung der Continuous Integration (bauen von Pakten und deployen der Anwendung). Dieser Prozess wird z.B. automatisch durch Einchecken einer Codeänderung in das Versionsverwaltungssystem gestartet.