Git: Überblick für Entwickler

Mai 23 @ 09:00 Mai 24 @ 16:00

Schulung / Training / Kurs / Seminar – 2 Tage remote

In dem Seminar “Git für Entwickler” erlernen Sie die Grundlagen und die Verwendung von Git, dem führenden Versionskontrollsystem für Softwareentwicklung. Git ist für fast alle Sprachen nutzbar und kostenlos verwendbar.

Durchführungs-Garantie: der Kurs wird auch bei nur einem Teilenmenden durchgeführt

Kurs buchen: https://www.gfu.net/seminare-schulungen-kurse/testmanagement_sk92/git-fuer-entwickler_s2556.html

Jeder Teilenmende erhält eine gedruckte Ausgabe des Buches: Marco Schulz, CI mit Jenkins, Rheinwerk, 2021

Sollten Sie zu den angebotenen Terminen nicht können, beziehungsweise für Ihr Team einen individuellen Termin wünschen, um beispielsweise in einer geschlossenen Runde auf konkrete Problemstellungen eingehen zu können, besteht die Möglichkeit zusätzliche außerplanmäßige Termine zu vereinbaren. Nutzen Sie bitte hierzu mein Kontaktformular unter der Angabe welchen Kurs Sie wünschen, mit Terminvorschlägen und der zu erwartenden Teilnehmerzahl.

Weitere Termine:

  • 15.08 – 16.08.2024
  • 21.11 – 22.11.2024
  • 23.09.-27.09.2024
  • 21.11.-22.11.2024
  • 10.02.-11.02.2025
  • 19.05.-20.05.2025
  • 04.08.-05.08.2025

README – gewusst wie

README Dateien haben in Softwareprojekten eine lange Tradition. Diese ursprünglich reinen Textdateien enthielten Lizenzinformationen und Anweisungen wie aus dem Quellcode das entsprechende Artefakt kompiliert werden konnte oder aber wichtige Hinweise zu Installation des Programms. Es gibt keinen wirklichen Standard wie man eine solche README Datei aufbauen sollte.

Seit dem GitHub (2018 von Microsoft übernommen) als kostenfrei Code Hosting Plattform für Open Source Projekte seinen Siegeszug angetreten ist, gab es schon recht früh die Funktion, dass die README Datei als Startseite des Repositories anzuzeigen. Dazu muss lediglich eine einfach Textdatei mit der Bezeichnung README.md im Hauptverzeichnis des Repository erstellt werden.

Um die README Dateien übersichtlicher strukturieren zu können wurde eine Möglichkeit für eine einfache Formatierung gesucht. Schnell hatte man sich für die markdown Notation entschieden, da diese einfach zu nutzen ist und auch recht performant gerendert werden kann. Somit sind die Übersichtsseiten besser für Menschen zu lesen und können als Projekt Dokumentation genutzt werden.

Es ist möglich mehrere solcher markdown Dateien als Projektdokumentation miteinander zu verknüpfen. Somit erhält man eine Art Mini WIKI das im Projekt enthalten ist und außerdem auch über Git versioniert wird.

Das ganze wurde so erfolgreich, das Selfhosting-Lösungen wie GitLab oder das kommerzielle BitBucket diese Funktion ebenfalls übernommen haben.

Nun stellt sich aber die Frage welche Inhalte man am besten in solch eine README Datei schreibt, damit diese für Außenstehende auch einen wirklichen Mehrwert darstellen. Dabei haben sich im Laufe der Zeit folgende Punkte etabliert:

  • Kurzbeschreibung des Projektes
  • Bedingungen unter denen der Quellcode verwendet werden darf (Lizenz)
  • Wie ist das Projekt zu verwenden (z.B. Anweisungen zum Compilieren oder wie wird die Bibliothek in eigene Projekte eingebunden)
  • Wer sind die Autoren des Projekte und wie kann man sie erreichen
  • Was ist zu tun wenn man das Projekt unterstützen möchte

Mittlerweile sind sogenannte Badges (Sticker) sehr populär. Diese referenzieren oft auf externe Dienste wie beispielsweise der freie Continuous Integration Server TravisCI. Diese helfen ausstehenden die Qualität des Projektes zu beurteilen.

Auf GitHub gibt es auch diverse Vorlagen für README Dateien. Man muss allerdings auch ein wenig auf die tatsächlichen Gegebenheiten des eigenen Projektes schauen und beurteilen welche Information für Nutzer bzw. Anwender wirklich relevant sind. Solche Vorlagen helfen aber sehr dabei herauszufinden ob man möglicherweise eine Punkt übersehen hat.

Das mittlerweile ziemlich jeder Hersteller von Source Control Management Serverlösungen die Funktion die README.md Datei als Projektstartseite für das Code Repository anzuzeigen integriert hat, bedeutet das eine README.me auch für kommerzielle Projekte eine sinnvolle Sache sind.

Auch wenn der Syntax für markdown leicht zu erlernen ist kann es bei umfangreichen Editierungen solcher Dateien durchaus komfortabler sein direkt eine MARKDOWN Editor zu nutzen. Dabei sollte man darauf achten, das die Vorschau auch korrekt dargestellt wird und nicht nur ein einfaches Syntaxhighligting angeboten wird.

Links sind nur für eingeloggte Nutzer sichtbar.

Links sind nur für eingeloggte Nutzer sichtbar.

Das Neueste wird nicht immer das Beste sein

Seit über einem Jahrzehnt hat sich die Erkenntnis durchgesetzt, das Computersysteme aktuell gehalten werden sollten. Wer regelmäßig Updates einspielt verringert das Risiko auf seinem Computer Sicherheitslücken zu haben, die Missbraucht werden könnten. Immer in der Hoffnung das Hersteller von Software stets in ihren Updates auch Sicherheitsmängel beheben. Microsoft hat beispielsweise seit der Einführung von Windows 10 seinen Nutzern ein Update-Zwang auferlegt. Grundsätzlich war die Idee durchaus begründet. Denn ungepatchte Betriebssysteme ermöglichen Hackern leichten Zugriff. Also hat sich vor sehr langer Zeit der Gedanke: ‚Latest is greatest‘ durchgesetzt.

Windowsnutzer habe hier wenig Freiräume. Aber auch auf mobilen Geräten wie Smartphones und Tabletts sind in der Werkseinstellung die automatischen Updates aktiviert. Wer auf GitHub ein Open Source Projekt hostet bekommt regelmäßige E-Mails um für verwendete Bibliotheken neue Versionen einzusetzen. Also auf den ersten Blick durchaus eine gute Sache. Wenn man sich mit der Thematik etwas tiefer auseinandersetzt kommt man sehr schnell zu dem Schluß das latest nicht wirklich immer das beste ist.

Das bekannteste Beispiel hierfür ist Windows 10 und die durch Microsoft erzwungenen Update Zyklen. Das Systeme regelmäßig auf Sicherheitsprobleme untersucht werden und verfügbare Aktualisierungen eingespielt werden müssen ist unumstritten. Das die Pflege von Rechnersysteme auch Zeit in Anspruch nimmt ist ebenfalls Einsichtig. Problematisch ist es aber wenn durch den Hersteller eingespielte Aktualisierungen einerseits das gesamte System lahmlegen und so eine Neuinstallation notwendig wird, weil das Update nicht ausreichend getestet wurde. Aber auch im Rahmen von Sicherheitsaktualisierungen ungefragt Funktionsänderungen bei den Nutzer einzubringen halte ich für unzumutbar. Speziell bei Windows kommt noch hinzu, das hier einiges an Zusatzprogrammen installiert ist, die durch mangelnde Weiterentwicklung schnell zu einem Sicherheitsrisiko werden können. Das bedeutet bei aller Konsequenz erzwungene Windowsupdates machen ein Computer nicht sicher, da hier die zusätzlich installierte Software nicht auf Schwachstellen untersucht wird.

Wenn wir einen Blick auf Android Systeme werfen, gestaltet sich die Situation weitaus besser. Aber auch hier gibt es genügend Kritikpunkte. Zwar werden die Applikationen regelmäßig aktualisiert, so das tatsächlich die Sicherheit markant verbessert wird. Aber auch bei Android bedeutet jedes Update in aller Regel auch funktionale Veränderungen. Ein einfaches Beispiel ist der sehr beliebte Dienst Google StreetMaps. Mit jeden Update wird die Kartennutzung für mich gefühlt unübersichtlicher, da eine Menge für mich unerwünschter Zusatzinformationen eingeblendet werden, die den bereits begrenzten Bildschirm erheblich verkleinern.

Als Nutzer ist es mir glücklicherweise noch nicht passiert, dass Applikationsupdates unter Android das gesamte Telefon lahmgelegt haben. Was also auch beweist das es durchaus möglich ist Aktualisierungen ausgiebig zu testen, bevor diese an die Nutzer ausgerollt werden. Was aber nicht heißt das jedes Update unproblematisch war. Probleme die hier regelmäßig beobachtet werden können sind Dinge wie ein übermäßig erhöhter Batterieverbrauch.

Reine Android Systemupdates wiederum sorgen regelmäßig dafür das die Hardware nach knapp zwei Jahren so langsam wird, das man sich oft dazu entscheidet ein neues Smartphone zu kaufen. Obwohl das alte Telefon noch in gutem Zustand ist und durchaus viel Länger genutzt werden könnte. So ist mir bei vielen erfahrenen Nutzern aufgefallen, das diese nach circa einem Jahr ihre Android Updates ausschalten, bevor das Telefon durch den Hersteller in die Obsoleszenz geschickt wird.

Wie bekommt man ein Update-Muffel nun dazu seine Systeme trotzdem aktuell und damit auch sicher zu halten? Mein Ansatz als Entwickler und Konfiguration Manager ist hier recht einfach. Ich unterscheide zwischen Feature Update und Security Patch. Wenn man im Release Prozess dem Semantic Versioning folgt und für SCM Systeme wie Git ein Branch by Release Modell nutzt, lässt sich eine solche Unterscheidung durchaus leicht umsetzen.

Aber auch der Fragestellung eine versionierbaren Konfigurationseinstellung für Softwareanwendungen habe ich mich gewidmet. Hierzu gibt es im Projekt TP-CORE auf GitHub eine Referenzimplementierung die in dem zweiteiligen Artikel Treasue Chest ausführlich beschrieben wird. Denn es muss uns schon klar sein, dass wenn wir bei einem Update die gesamte vom Nutzer vorgenommene Konfiguration auf Werkseinstellung zurück setzen, wie es recht oft bei Windows 10 der Fall ist, können ganz eigene Sicherheitslücken entstehen.

Das bringt uns auch zu dem Punkt Programmierung und wie GitHub Entwickler durch E-Mails dazu motiviert neue Versionen der verwendeten Bibliotheken in ihre Applikationen einzubinden. Denn wenn es sich bei einem solchen Update um eine umfangreiche API Änderung handelt ist das Problem der hohe Migrationsaufwand für die Entwickler. Hier hat sich für mich eine ebenfalls recht einfache Strategie bewährt. Anstatt mich von den Benachrichtigungen über Aktualisierungen von GitHub beeindrucken zu lassen, prüfe ich regelmäßig über OWASP ob meine Bibliotheken bekannte Risiken enthalten. Denn wird durch OWASP ein Problem erkannt, spielt es keine Rolle wie Aufwendig eine Aktualisierung werden kann. Das Update und ein damit verbunden Migration muss zeitnahe umgesetzt werden. Dies gilt dann auch für alle noch in Produktion befindlichen Releases.

Um von Beginn an der Update Hölle zu entrinnen gilt allerdings eine Faustegel: Installiere beziehungsweise nutze nur das was du wirklich benötigst. Je weniger Programme unter Windows installiert sind und je weniger Apps auf dem Smartphone vorhanden sind, um so weniger Sicherheitsrisiken entstehen. Das gilt auch für Programmbibliotheken. Weniger ist aus Sicht der Security mehr. Abgesehen davon bekommen wird durch den Verzicht unnötiger Programme noch eine Performance Vermessung frei Haus.

Sicher ist für viele privaten Anwender die Frage der Systemaktualisierung kaum relevant. Lediglich Neue unerwünschte Funktionen in vorhanden Programmen, Leistungsverschlechterungen oder hin und wieder zerschossene Betriebssysteme verursache mehr oder weniger starken Unmut. Im kommerziellen Umfeld können recht schnell erhebliche Kosten entstehen, die sich auch auf die gerade umzusetzenden Projekte negativ auswirken können. Unternehmen und Persone die Software entwickeln können die Nutzerzufriedenheit erheblich verbessern, wenn sie bei Ihren Release Veröffentlichungen zwischen Security Patches und Feature Updates unterscheiden. Und ein Feature Update sollte dann entsprechend auch allen bekannten Security Aktualisierungen enthalten.

Lo último no siempre es lo mejor

Desde hace más de una década, está ampliamente aceptado que los sistemas informáticos deben mantenerse actualizados. Quienes instalan actualizaciones con regularidad reducen el riesgo de tener brechas de seguridad en su ordenador de las que se podría hacer un mal uso. Siempre con la esperanza de que los fabricantes de software corrijan siempre en sus actualizaciones también los fallos de seguridad. Microsoft, por ejemplo, ha impuesto una obligación de actualización a sus usuarios desde la introducción de Windows 10. En el fondo, la idea tenía fundamento. Porque los sistemas operativos sin parches facilitan el acceso a los hackers. Así que el pensamiento: “Lo último es lo mejor” prevaleció hace mucho tiempo.

Los usuarios de Windows tenían poco margen de maniobra. Pero incluso en dispositivos móviles como smartphones y tabletas, las actualizaciones automáticas están activadas en los ajustes de fábrica. Si alojas un proyecto de código abierto en GitHub, recibirás regularmente correos electrónicos sobre las nuevas versiones de las bibliotecas utilizadas. Así que, a primera vista, esto es algo bueno. Sin embargo, si profundizas un poco más en el tema, llegarás rápidamente a la conclusión de que lo último no siempre es lo mejor.

El ejemplo más conocido es Windows 10 y los ciclos de actualización impuestos por Microsoft. Es indiscutible que los sistemas deben comprobarse periódicamente para detectar problemas de seguridad e instalar las actualizaciones disponibles. También es comprensible que el mantenimiento de los sistemas informáticos lleve su tiempo. Sin embargo, resulta problemático cuando las actualizaciones instaladas por el fabricante paralizan todo el sistema y se hace necesaria una nueva instalación porque la actualización no ha sido suficientemente probada. Pero también en el contexto de las actualizaciones de seguridad sin pedir cambios de función al usuario para traer en considero irrazonable. Especialmente con Windows, hay un montón de programas adicionales instalados, que pueden convertirse rápidamente en un riesgo para la seguridad debido a la falta de un mayor desarrollo. Eso significa con todas las consecuencias forzadas actualizaciones de Windows no hacen un equipo seguro, ya que aquí el software instalado adicionalmente no se examina en busca de puntos débiles.

Si echamos un vistazo a los sistemas Android, la situación es mucho mejor. Sin embargo, aquí también hay bastantes puntos criticables. Las aplicaciones se actualizan con regularidad, por lo que la seguridad mejora notablemente. Pero también con Android, cada actualización suele implicar cambios funcionales. Un ejemplo sencillo es el muy popular servicio Google StreetMaps. Con cada actualización, el uso del mapa se vuelve más confuso para mí, ya que se muestra mucha información adicional no deseada, lo que reduce considerablemente la ya limitada pantalla.

Como usuario, afortunadamente todavía no me ha ocurrido que las actualizaciones de aplicaciones en Android hayan paralizado todo el teléfono. Lo que también demuestra que es bastante posible probar exhaustivamente las actualizaciones antes de lanzarlas a los usuarios. Sin embargo, esto no significa que todas las actualizaciones estén exentas de problemas. Los problemas que se pueden observar aquí con regularidad son cosas como un aumento excesivo del consumo de batería.

Las actualizaciones puras del sistema Android, por otro lado, hacen que regularmente el hardware se vuelva tan lento después de casi dos años que a menudo se decide comprar un nuevo smartphone. Aunque el teléfono antiguo todavía esté en buenas condiciones y se pueda utilizar mucho más tiempo. He observado que muchos usuarios experimentados desactivan las actualizaciones de Android al cabo de un año aproximadamente, antes de que el fabricante envíe el teléfono a la obsolescencia.

¿Cómo consigue un silenciador de actualizaciones mantener sus sistemas al día y seguros? Mi planteamiento como desarrollador y gestor de configuración es bastante sencillo. Distingo entre actualización de características y parche de seguridad. Si sigues el versionado semántico en el proceso de publicación y utilizas un modelo de rama por publicación para sistemas SCM como Git, esa distinción puede aplicarse fácilmente.

Pero también me he dedicado a la cuestión de una configuración versionable para aplicaciones de software. Para ello, existe una implementación de referencia en el proyecto TP-CORE en GitHub, que se describe en detalle en el artículo en dos partes Treasue Chest. Después de todo, debemos tener claro que si restablecemos toda la configuración realizada por el usuario a los valores de fábrica durante una actualización, como ocurre con bastante frecuencia con Windows 10, pueden surgir vulnerabilidades de seguridad bastante singulares.

Esto también nos lleva al punto de la programación y cómo GitHub motiva a los desarrolladores a través de correos electrónicos para que incluyan nuevas versiones de las librerías utilizadas en sus aplicaciones. Porque si dicha actualización supone un cambio importante en la API, el problema es el elevado esfuerzo de migración para los desarrolladores. Aquí es donde me ha funcionado una estrategia también bastante sencilla. En lugar de dejarme impresionar por las notificaciones sobre actualizaciones de GitHub, compruebo regularmente a través de OWASP si mis bibliotecas contienen riesgos conocidos. Porque si OWASP detecta un problema, no importa lo costosa que pueda ser una actualización. La actualización y la migración asociada deben aplicarse con prontitud. Esto también se aplica a todas las versiones que todavía están en producción.

Para evitar el infierno de las actualizaciones desde el principio, sin embargo, hay una regla de oro: sólo instalar o utilizar lo que realmente se necesita. Cuantos menos programas se instalen en Windows y menos aplicaciones haya en el smartphone, menos riesgos de seguridad habrá. Esto también se aplica a las bibliotecas de programas. Menos es más desde el punto de vista de la seguridad. Aparte de eso, al prescindir de programas innecesarios, también obtenemos una medida de rendimiento gratuita.

Ciertamente, para muchos usuarios privados la cuestión de las actualizaciones del sistema apenas es relevante. Sólo las nuevas funciones no deseadas en los programas existentes, la degradación del rendimiento o, de vez en cuando, el bloqueo de los sistemas operativos causan un disgusto más o menos fuerte. En el entorno comercial, pueden surgir con bastante rapidez costes considerables, que también pueden repercutir negativamente en los proyectos que se ejecutan. Las empresas y las personas que desarrollan software pueden mejorar considerablemente la satisfacción de los usuarios si distinguen en sus versiones entre parches de seguridad y actualizaciones de características. Y una actualización de características debería contener también todas las actualizaciones de seguridad conocidas.

Versionsverwaltung mit Expressions

Im Umgang mit Source-Control-Management-Systemen (SCM) wie Git oder Subversion haben sich im Lauf der Zeit vielerlei Praktiken bewährt. Neben unzähligen Beiträgen über Workflows zum Branchen und Mergen ist auch das Formulieren verständlicher Beschreibungen in den Commit-Messages ein wichtiges Thema.

(c) 2018 Marco Schulz, Java PRO Ausgabe 3, S.50-51

Ab und zu kommt es vor, dass in kollaborativen Teams vereinzelte Code-Änderungen zurückgenommen werden müssen. So vielfältig die Gründe für ein Rollback auch sein mögen, das Identifizieren betroffener Code-Fragmente kann eine beachtliche Herausforderung sein. Die Möglichkeit jeder Änderung des Code-Repository eine Beschreibung anzufügen, erleichtert die Navigation zwischen den Änderungen. Sind die hinterlegten Kommentare der Entwickler dann so aussagekräftig wie „Layout-Anpassungen“ oder „Tests hinzugefügt“, hilft dies wenig weiter. Diese Ansicht vertreten auch diverse Blog-Beiträge [siehe Weitere Links] und sehen das Formulieren klarer Commit-Messages als wichtiges Instrument, um die interne Kommunikation zwischen einzelnen Team-Mitgliedern deutlich zu verbessern.

Das man als Entwickler nach vollbrachter Arbeit nicht immer den optimalen Ausdruck findet, seine Aktivitäten deutlich zu formulieren, kann einem hohen Termindruck geschuldet sein. Ein hilfreiches Instrument, ein aussagekräftiges Resümee der eigenen Arbeit zu ziehen, ist die nachfolgend vorgeschlagene Struktur und ein darauf operierendes aussagekräftiges Vokabular inklusive einer festgelegten Notation. Die vorgestellte Lösung lässt sich sehr leicht in die eigenen Prozesse einfügen und kann ohne großen Aufwand erweitert bzw. angepasst werden.

Mit den standardisierten Expressions besteht auch die Möglichkeit die vorhandenen Commit-Messages automatisiert zu Parsen, um die Projektevolution gegebenenfalls grafisch darzustellen. Sämtliche Einzelheiten der hier vorgestellten Methode sind in einem Cheat-Sheet auf einer Seite übersichtlich zusammengefasst und können so leicht im Team verbreitet werden. Das diesem Text zugrundeliegende Paper ist auf Research-Gate [1] in englischer Sprache frei verfügbar.

Eine Commit-Message besteht aus einer verpflichtenden (mandatory) ersten Zeile, die sich aus der Funktions-ID, einem Label und der Spezifikation zusammensetzt. Die zweite und dritte Zeile ist optional. Die Task-ID, die Issue-Management-Systeme wie Jira vergeben, wird in der zweiten Zeile notiert. Grund dafür ist, dass nicht jedes Projekt an ein Issue-Management-System gekoppelt ist. Viel wichtiger ist auch die Tatsache, dass Funktionen meist auf mehrere Tasks verteilt werden. Eine Suche nach der Funktions-ID fördert alle Teile einer Funktionalität zu tage, auch wenn dies unterschiedlichen Task-IDs zugeordnet ist. Die ausführliche Beschreibung in Zeile drei ist ebenfalls optional und rückt auf Zeile zwei vor, falls keine Task-ID notiert wird. Das gesamte Vokabular zu dem nachfolgenden Beispiel ist im Cheat-Sheet notiert und soll an dieser Stelle nicht wiederholt werden.

[CM-05] #CHANGE ’function:pom’
<QS-0815>
{Change version number of the dependency JUnit from 4 to 5.0.2}

Projektübergreifende Aufgaben wie das Anpassen der Build-Logik, Erzeugen eines Releases oder das Initiieren eines Repositories können in allgemeingültigen Funktions-IDs zusammengefasst werden. Entsprechende Beispiele sind im Cheat-Sheet angeführt.

Configuration Management
[CM-00] #INIT, #REVIEW, #BRANCH, #MERGE, #RELEASE #BUILD-MNGT

Möchte man nun den Projektfortschritt ermitteln, ist es sinnvoll aussagekräftige Meilensteine miteinander zu vergleichen. Solche Punkte (POI) stellen üblicherweise Releases dar. So können bei Berücksichtigung des Standard-Release-Prozesses und des Semantic-Versionings Metriken über die Anzahl der Bug-Fixes pro Release erstellt werden. Aber auch klassische Erhebungen wie Lines-of-Code zwischen zwei Minor-Releases können interessante Erkenntnisse fördern.

Resourcen

Links sind nur für eingeloggte Nutzer sichtbar.

Article / Research Paper