In der Welt der Versionskontrollsysteme ist Git mit Abstand eines der effektivsten und einfachsten Tools die uns zur Verfügung stehen, um unseren Arbeitsalltag bzw. unseren Workflow zu optimieren. In diesem Artikel zeigen wir euch, wir ihr Git mit git-flow effektiver nutzt.

Git Branching

Wir gehen in unserem Beispiel davon aus, dass zwei neue Features für unser aktuelles Projekt geplant sind. Diese wollen wir, ohne uns als Entwickler gegenseitig auf die Füße zu treten, zeitgleich erledigen.

Dafür gibt es in Versionskontrollsysteme sogenannte Branches. Bei Git enthält jeder Branch eine eigene Kopie des jeweiligen Repositories zum Zeitpunkt der Erstellung des Branches. Den Verlauf einer Feature-Entwicklung im normalen Git-Workflow erklärt der nächste Absatz. Person A erstellt hier zum Beispiel eine Navigation speziell für Smartphones in unserem Projekt.

Einfacher Workflow ohne Branching-Modell:

Als erstes beziehen (clonen) wir das Git-Respository vom Server, um eine lokale Kopie des gesamten Projektes zu erhalten. In diesem wird nun auf dem Hauptbranch (Master) das Feature „Smartphone Navigation“ nach und nach programmiert. Die Schritte schliessen jeweils mit commit und anschliessendem push der Änderungen an das globale Repository ab. Die Webseite auf dem Produktions-Server wird anschliessend mit einem pull aktualisiert.

Das Problem an diesem Beispiel ist Folgendes:
Sobald eine weitere Person am selben Projekt arbeitet kann es zu Überschneidungen kommen. Angenommen Person A arbeitet an der Smartphone Navigation während Person B einen wichtigen Bugfix einspielt. Dadurch, dass Person B seinen Bugfix so schnell wie möglich auf der Live-Instanz des Projektes haben will, wird nach dem Hinzufügen des Bugfixes sofort der Master-Branch auf den neusten Stand gebracht. Das hat die Nebenwirkung zur Folge, dass auch Teile des Codes von Person A auf den Live-Server geladen werden und somit Probleme bzw. Fehler produzieren werden, da man nicht sicher sein kann, dass Person A seine Arbeit beendet hat. Und seien wir ehrlich – in Projekten mit mehr als einem Entwickler kommt es IMMER zu solchen Zuständen.

Lösungsansatz mit Git und einem einfachen Branching-Modell

Um solche Probleme zu umgehen hat man in Git die Möglichkeit einen oder mehrere Branches zu erstellen. Ein Branch ist eine Abzweigung der Codebasis zu einem bestimmten Punkt. Ab diesem Punkt kann man auf seinem Zweig (Branch) parallel zum Beispiel zum Hauptstrang in Ruhe entwicklen und erst das fertige Feature wieder zurück mergen.

Hier ein Beispiel:
Person A möchte eine Navigation für Smartphones erstellen ohne jemandem in die Quere zu kommen und geht jetzt wie folgt vor:
Git-Repository vom Server ziehen für eine lokale Kopie des gesamten Projektes. Neuen Branch erstellen mit dem Namen „develop“.
Auf diesem Branch kann jetzt unabhängig von anderen Branches weiter gearbeitet werden. Jegliche Änderung auf dem neu erstellten Branch wird zunächst keinerlei Auswirkung auf andere Branches haben. Sobald das neue Feature fertig ist, wird Person A seine Änderungen pushen und seine Änderungen in den Hauptbranch „mergen“ (zusammenführen).
Dieses Merging vom Branch „develop“ in den Hauptbranch des Projektes bewirkt, dass alle Änderungen im Smartphone Branch nun auch auf dem Hauptzweig des gesamten Projektes verfügbar sind.

Sollte während der Entwicklungszeit der Smartphone-Navigation Person B einen kritischen Bugfix in den Hauptbranch pushen, kann der Administrator ohne Einfluss der Codeänderungen für die Smartphone-Navigation den Hauptbranch updaten. Der Bugfix der auf dem Hauptbranch von Person B eingefügt wird, hat keinerlei Auswirkungen auf die Arbeit von Person A (Smartphone-Navigation Branch). Auch werden Codeänderungen von Person A keinen Einfluss auf die Arbeit von Person B haben, da beide verschiedene Branches verwenden.

Wenn dann jedoch nach der Fertigstellung der Smartphone-Navigation das gesamte Projekt diese neue Navigation erhalten soll, wird der Branch des neuen Features, in unserem Fall „develop“, einfach mit dem Hauptbranch zusammengeführt, woraufhin alle anderen Projektmitglieder die neuen Änderungen schließlich auch erhalten. Ausgenommen davon sind natürlich wieder die Projektmitglieder, die sich gerade auf einem anderen Branch befinden.

Lösungsansatz git-flow als Branching-Modell

„Git-flow“ ist ein Tool das den Workflow von Git erweitert und fest spezifiziert. Es kann per Kommandozeile oder per Tool bedient werden. So bieten zum Beispiel Sourcetree von Atlassian und PhpStorm Untersützung für git-flow. Die sehr feste Spezifizierung von git-flow hält den Workflows konstant und fördert den dezentralisierten Entwicklungsansatz. Zusätzlich zu den bekannten Hauptzweigen „master“ und „develop“ werden sogenannte Support-Branches erstellt, welche später für differenzierte Aufgaben verwendet werden. Diese werden auf verschiedene Art und Weise mit unseren Hauptzweigen „master“ und „develop“ zusammengeführt. Wir werden diese Support-Branches anhand von drei Beispielen kurz erklären.

Support-Branches bei git-flow

Derzeit haben wir in unserem Projekt zwei Zweige, „master“ und „develop“. „Master“ ist die aktuelle Live-Version des Projektes während „develop“ einen aktuellen Entwicklungsstand darstellt. „Git-flow“ fügt nun drei weitere Arten von Branches zu unserem Workflow: „release“, „feature“, und „hotfix“.

Hotfix-Branches

Der Hotfix-Branch wird von den beteiligten Entwicklern lediglich dazu benutzt Fehlerbehebungen des Live-Systems durchzuführen. Sobald ein Fehler behoben ist, wird der Hotfix-Branch geschlossen und mit „master“ und „develop“ zusammengeführt. Dieses führt auf der einen Seite zu einem sauber aktualisierten Live-System und auf der anderen Seite wird der Hotfix in die Entwicklungsschiene transferiert, da sämtliche anderen Branches vom „develop“ Branch abhängen.
Hotfix-Branch Workflow © nvie.com

Feature-Branches

Der Feature-Branch wird als Zweig zur Erstellung neuer Funktionen verwendet. Sobald eine neue Funktionalität abgeschlossen ist, wird der Feature-Branch auf mit dem Develop-Branch zusammengeführt und kann auf einer Testinstanz unabhängig von unserem Master branch getestet werden. Feature-Branches sollten in dieser Struktur lediglich lokal vorkommen.
Feature-Branch Workflow © nvie.com

Release-Branches

Der Release-Branch wird bei jedem neuen Release oder großen Codeänderung (Milestone) benutzt. Ein Release kann zum Beispiel eine Sammlung von verschiedenen Features sein, welche als Release-Branch gruppiert bzw. zusammengefasst werden, um gemeinsam deployed zu werden. Ein Release-Branch sollte immer mit „master“ als auch „develop“ zusammengeführt werden, wobei letzterer für die Qualitätssicherung inklusive Testing Vorrang hat.

Fazit

Das Arbeiten mit git-flow oder generell die korrekte Nutzung von Branching stellt eine qualitätssichernde sowie Workflow-optimierende Maßnahme da, die uns hilft sauber und getrennt voneinander unseren Aufgaben nach zu gehen, ohne die Arbeit des Anderen zu beeinträchtigen.

Der Beitrag git-flow – das Branching-Modell erschien zuerst auf Entwicklungshilfe NRW.

Die Installation

Codeception kann hier via Composer installiert werden. Jedoch wird davon in unserem Beispiel kein Gebrauch gemacht, da wir den sofortigen Einsatz von Codeception auf einer frischen VM realisieren, und somit keinen Composer installiert haben.

Mac/Linux:
Auf dem Mac bzw Linux und Unix derivaten kann Codeception auch per Command-line installiert werden.

wget http://codeception.com/codecept.phar && php codeception.phar bootstrap

mit diesem beidem Befehlen wird Codeception installiert und dessen Ordnerstruktur erstellt.

Windows:
Auf Windows muss das installationsarchiv hier manuell heruntergeladen werden von:

Nach der Installation auf Windows hat Codeception die benötigte Ordnerstruktur erstellt.

Sollte das Frontend-Testing mit Google Chrome, Firefox oder anderen Browsern durchgeführt werden, wird auch Selenium benötigt. Die Installation kann auf einem Mac/Linux per Kommandozeile mit folgenden Befehlen geschehen.

Mac:

brew install selenium-server

Linux:

apt-get install selenium-server

Auf Windows muss der Selenium Server von http://selenium.org heruntergeladen und installiert werden.

Nachdem Selenium und Codeception installiert sind, gestaltet sich der Rest der Konfiguration relativ einfach. Zunächst können im „_env“ Verzeichnis von Codeception sogenannte Testumgebungen angelegt werden, welche der Reihe nach von Codeception durchlaufen und abgearbeitet werden. Ein Beispiel für einen solche Datei sieht wie folgt aus.

In diesem .yml file wird festgelegt, dass der zu testende Browser Google Chrome sein wird.
Des Weiteren wird festgelegt, dass wir in der Auflösung 1920×1080 testen werden.
Die URL kann pro Testumgebung jeweils eine URL beinhalten, welche in unserem Testszenario momentan auf einen unserer Testserver zeigt.

Vorbereitungen für das Frontend-Testing

Nachdem wir unsere Umgebungsvariablen festgelegt haben, können wir uns der nächsten wichtigen Datei widmen. Die Datei __bootstrap.php aus dem Verzeichnis „acceptance“ wird vor jedem Test aufgerufen und erlaubt es, Variablen zu deklarieren die dann in den jeweiligen Testszenarien verwendet werden können. Diese Variablen bestehen den ganzen Test über und können von den verschiedenen Szenarien gemeinsam benutzt werden. Eine sinnvolle Verwendung dieser Datei wäre zum Beispiel eine Funktion zum erkennen des benutzten Browsers, um in den Tests darauf entsprechend reagieren zu können und die Tests für den jeweiligen Browser besser anzupassen.

Beispiel: Sollte die Funktion in __bootstrap.php ein mobiles Endgerät entdecken, kann der darauf folgende Test in seinem Testszenario darauf reagieren und zum Beispiel die mobile Navigation anstatt die normale Navigation Testen.

Hinweis: Bevor die Testszenarien durchlaufen werden können, muss Selenium entweder auf Windows mit einem Doppelklick, oder auf Mac bzw Linux/Unix derivaten mit dem Konsolenbefehl „selenium-server -p 4444“ gestartet werden.

Das Testszenario

Kommen wir nun zu den eigentlichen Tests. Jedes Testszenario das wir anlegen wollen, muss sich im „acceptance“ Verzeichnis befinden. Jede PHP datei außer __bootstrap.php wird dort für jede einzelne Testumgebung die wir im „_env“ Verzeichnis liegen haben durchlaufen. Haben wir zum Beispiel ein Testszenario wie „Navigation.php“ im „acceptance“ folder, wird dieses Szenario für chrome_1920x1080.yml aufgerufen.
Ein Beispiel eines solchen Tests sieht wie folgt aus.

amOnPage("/");
    $I->wantTo("test elements of the navigation (upper categories)");
    $I->click(".menu-button");
    $I->click("#nav-wide .level0.nav-1 a span");
    $I->moveMouseOver("#nav-wide .level0.nav-1 a span");
    $I->click(".level1.nav-1-1  a span");
?>

Der obrige test wurde mit dem Befehl „php codecept.phar run acceptance –env chrome_1920x1080“ aufgerufen. Für jede weitere Testumgebung die in die Testszenarien eingebunden werden soll, wird eine weitere –env Direktive benötigt.

Beispiel 2 Browser:

php codecept.phar run acceptance --env chrome_1920x1080 --env firefox_1920x1080

Hint: Während eines Tests der Funktionen wie $i->moveMouseOver() enthält darf die Maus nicht bewegt werden!

Je nach Generalisierung der Tests wie Beispielsweise oben beschrieben, lässt dich der Test für mehrere Anwendungszwecke verwenden. In unserem Fall ist der oben zu sehende Test für jegliches Login-Formular einer Magento-Shop Webseite einsetzbar.

Nachdem Codeception die Tests erfolgreich (oder auch nicht) beendet hat, wenden wir uns dem Verzeichnis „records“ zu. Im Verzeichnis „records“ befinden sich Screenshots von jedem einzelnen Schritt unserer Tests und dem Ergebnis. Es bleibt einem die Möglichkeit entweder die Datei „index.html“ zu öffnen und sich in einem minimalistisch gestalteten Web-interface durch die Ergebnisse zu klicken oder sich die einzelnen Fehlgeschlagenen Tests heraus zu suchen. Fehlgeschlagene Tests haben eine „.fail.“-Endung im Dateiname und sind direkt in „records“ Ordner zu finden.

Hint: Der Befehl $i->wait() veranlasst Codeception dazu, eine gewisse Zeit zu warten und einen neuen Screenshot zu erstellen.

Fazit:

Codeception ist ein effizient einsetzbares Tool mit noch kleinen Schönheitsfehlern, wie zum Beispiel das unnötige Erstellen eines Screenshots nach Verwendung des $i->wait() Befehls, die einen Entwickler jedoch keinesfalls am produktiven Einsatz des Frameworks hindern. Es stellt mit seiner einfachen Syntax und leichten Bedienbarkeit eine effektive Methode für das Frontend-Testing dar.

Der Beitrag Frontend-Testing mit Codeception erschien zuerst auf Entwicklungshilfe NRW.

In Stellenausschreibungen steht heute immer öfter die Anforderung, Git über die Command Line zu nutzen. Gerade bei Senior-Entwicklern wird dieses Wissen bereits explizit vorausgesetzt. Das Command-Line-Wissen kannst du dann auch anwenden, wenn dir kein Rechner mit Sourcetree zur Verfügung steht, weil du dich vielleicht direkt auf den Linux-Servern lokal oder remote bewegen musst.

Git Commands, die tatsächlich gebraucht werden

Es sind nicht so viele Git Commands, die für die tägliche Arbeit gebraucht werden, wie man vielleicht glaubt. Hier mal ein einfacher Task mit den Git-Commands direkt auf der Command Line.

Git Repository klonen

git clone https://url.com/example-repo

Mit dem Git Command wird das Repo in das Verzeichnis „example-repo“ geklont. Gibt man hinter der URL ein anderes Ziel oder Target an, wird ein anderer Ordner genommen. Das macht bei der späteren Anwendung keinen Unterschied, kann aber zu mehr Übersicht in der Dateistruktur genutzt werden. Mit der Angabe von „.“ wird das Repository in das aktuelle Verzeichnis geklont. Das ist zwar ein seltener Anwendungsfall, spart einem aber bei Bedarf Zeit. Dafür muss der Ordner allerdings vollständig leer sein. Auch die Verzeichnisse der PHP-IDEs, wie PhpStorm, dürfen hier nicht vorhanden sein.

Branch erstellen

git checkout -b myNewTask
Mit dem Checkout-Befehl und dem Parameter -b wird ein neuer Branch „myNewTask“ erstellt und automatisch auf diesen gewechselt. Hier ist darauf zu achten, auf welchen Branch man sich zu dem Zeitpunkt der Erstellung befindet, und natürlich auch darauf, dass man den aktuellsten Stand auscheckt – also vorher ein „git pull“ ausgeführt hat.

Developing auf dem Branch

git add . && git commit -m “#myNewBranch add css file”
oder
git add layout/mynewtask.css && git commit -m “#myNewBranch add css file”

Generell soll ja bei jeder funktionierenden Änderung ein Commit gemacht werden. Hier ist Disziplin gefragt. Grafische Tools wie Sourcetree verleiten jedoch dazu, dies zu einem späteren Zeitpunkt zu machen. Hier kann man sehr einfach einzelne geänderte Zeilen separaten Commits zuweisen. Das bedeutet leider noch lange nicht, dass der Commit tatsächlich alles tut, was er soll, und wie gewünscht funktioniert hat.

Insofern ist es besser, regelmäßig kleine Commits zu machen. Der Git-Add-Befehl dient dabei einmal für das separate File und einmal für alles seit dem letzten Commit. Auch hier gilt: Regelmäßige und sinnvolle Commits machen einem das Leben leichter und sind effektiver. Vorher ist es zudem immer sinnvoll, sich die aktuellen Änderungen mit „git status“ noch einmal anzeigen zu lassen. Denn schließlich kommt es vor, dass man etwas übersehen hat. Das trifft auch auf von der Applikation generierte Files zu, die eventuell noch über .gitignore ausgeschlossen werden müssen.

Commit Messages

Damit man die Historie einer Entwicklung nachvollziehen kann, sind Commit Messages wichtig. Diese müssen aussagekräftig sein und beinhalten idealerweise eine Ticket-ID. Denn somit können die Arbeitsschritte direkt zugeordnet werden. Nicht aussagekräftige Commit Messages indes schaden dem Team und einem selbst.

Mit Pre Hooks ist es möglich, Commits ohne Ticket-ID direkt zu unterbinden. Das kann sogar erweitert werden, dass sich das Ticket im richtigen Status befinden muss. Solche Maßnahmen einzuführen und umzusetzen, ist allerdings nicht so einfach wie deren technische Implementierung.

Es gibt einige Spaßseiten zu dem Thema wie beispielsweise Commits from last night – dabei ist das Thema doch eigentlich sehr ernst. Denn es dient der Dokumentation der eigenen Arbeit und zeigt, dass du ein Profi bist. Soll heißen: Arbeite immer möglichst professionell. Das ist wichtig und richtig.

Git-flow installieren und sofort nutzen

git flow feature start myNewBranch
git flow feature finish myNewBranch

Git-flow hat sich in vielen Projekten bewährt und wird vor allem gerne bei neuen Projekten eingesetzt. Auf dem Mac ist es schnell mit Homebrew installiert, und nach einem „git flow init“ kann es nach einigen Bestätigungen der Default-Settings sofort eingesetzt werden. Mit dem oben aufgeführten Start-Befehl wird dabei ein neuer Branch aus dem aktuellen Develop Branch erstellt. Danach kann man sein Feature entwickeln und mit dem Finish-Befehl wieder abschließen. Hier wird ein Merge zurück in den Develop Branch ausgeführt und der Feature Branch sofort gelöscht. Falls man das aber nicht unbedingt möchte, geht es auch mit Hotfixes und Releases.

Eine gute Übersicht zu all dem bietet http://danielkummer.github.io/git-flow-cheatsheet/. Ausführliche Informationen zu Git-flow gibt es außerdem unter https://github.com/nvie/gitflow. Wir haben uns im praktischen Einsatz dazu entschlossen, nach dem Git-Flow-Workflow zu arbeiten, die zusammengeführten Branches allerdings zu archivieren und zu erhalten.

Git-Workflow nur auf der Command Line

Der Git-flow ist eine Zusammenfassung von Befehlen, die man selbstverständlich auch eigenhändig und einzeln ausführen kann. In meinen Augen ist aber ein großer Nachteil, dass Branches, die zurückgemerged wurden, auch gelöscht werden.

Persönlich finde ich es zudem besser, Bugfixes auf dem Feature Branch durchzuführen und sich öfter mit dem aktuellen Stand abzugleichen. So kann man die Arbeit auf einem Feature besser dokumentieren. Das Ganze geht manuell auf der Command Line – CLI – wie folgt:

// Aktuellen Develop Branch auschecken und aktualisieren
git checkout develop
git pull

// Feature Branch für Jira Ticket SUP-123 erstellen
git checkout -b feature/SUP-123

// Commits auf das Ticket
git status
git add . && git commit -m “#SUP-123 what i have done”

// Git Pushes sollten mindestens jeden Abend durchgeführt werden – und zwar auf jeden Fall vor den Merges, egal in welche Richtung
git status
git push

// Feature Branch zurück in Develop bringen
git checkout develop
git pull
git merge feature/SUP-123
git status

// Tag setzen
git tag -a v1.2.0 -m “Version v1.2.0”
// Push mit Tags
git push && git push –tags

Die oben aufgeführten Commands in oh-my-zsh
// Aktuellen Develop Branch auschecken und aktualisieren
gco develop
gl

// Feature Branch für Jira Ticket SUP-123 erstellen
gcb feature/SUP-123

// Commits auf das Ticket
gst
gaa && gcmsg “#SUP-123 was ich gerade getan habe”
gst

// Git Push sollte mindestens jeden Abend durchgeführt werden – und zwar auf jeden Fall vor den Merges, egal in welche Richtung
gst
gp

// Feature Branch zurück in Develop bringen
gco develop
gl
gm feature/SUP-123
gst

// Tag setzen
git tag -a v1.2.0 -m “Version v1.2.0”

// Push mit Tags
gp && gp –tags

Mit oh-my-zsh sind eine Vielzahl von Git Commands als Alias abgelegt. Im praktischen Einsatz kommen in meinen Augen die oben abgebildeten zum Tragen. Allein gaa && gcmsg „my message“ bringen einem sehr viel, da sie ein häufiger Anwendungsfall sind. Auch gc für git checkout geht schnell in Fleisch und Blut über.

Probleme mit Git

Git-Konflikte sind ein großes Thema bei Git und natürlich auch Themen wie Rebase. Aber in diesem Artikel gehe ich nicht zusätzlich auf diese Themen ein. In Zukunft werden wir hier in unserem Webdevelopment-Blog das Thema Git auch in anderen Zusammenhängen aufgreifen. Auch gehe ich nicht auf Tools, wie Tig ein. Aber natürlich ist es wichtig und richtig, mit visuellen Tools zu arbeiten.

Fazit zu Git auf der Command Line CLI

Git ist in der heutigen Zeit des Webdevelopments der Quasi-Standard. Jeder Entwickler, egal ob Frontend oder Backend, muss damit umgehen können. Man braucht und darf keine Ausreden bei der Nutzung einer Command Line haben. Nur so wird man zum Profi – sonst ist man nur ein Anwender. Ein User.

In diesem Artikel ist ein einfaches Beispiel über die Entwicklung eines Feature Branches abgebildet. Man sieht ganz deutlich, dass nur wenige Commands nötig sind. Es ist wichtig, diese einfachen Vorgänge zu 100 Prozent auf der Command Line durchführen zu können und dies auch regelmäßig zu tun. Nur so lernt man Git richtig.

Unsere Git-PHP-Schulung

Git wird von vielen Webdevelopern benutzt. Sie haben es aber leider häufig nicht verinnerlicht oder verstanden, warum man damit genau so arbeitet, wie man es tut. In unserer Schulung gehen wir ganz praktisch vor und erklären Git von den Grundlagen bis zu praktischen und etablierten Workflows. Wir gehen auf die Anwendungsfehler ein und geben unsere persönliche Erfahrung direkt an die Teilnehmer weiter. Es ist eine sehr individuelle Intensiv-Schulung. Alle Informationen zu dem Thema gibt es auf
http://www.entwicklungshilfe.nrw/seminare/git-flow-git-branching-model-fuer-agile-software-projekte/

Wie nutzt du Git bislang? Hast du es schon mal per Command Line versucht, und wie sind da ggf. deine Erfahrungswerte?

Der Beitrag Git auf der Command Line CLI einsetzen erschien zuerst auf Entwicklungshilfe NRW.

Voraussetzungen für einen erfolgreichen Workflow

Grundlage für den hier gezeigten Workflow sind PhpStorm als IDE mit installiertem git-flow-Plugin sowie ein funktionierendes Ticketsystem Redmine. Natürlich gibt es Alternativen zu dieser Kombination. PhpStorm arbeitet mit sehr vielen Systemen zusammen, und auch andere IDEs haben ähnliche Funktionen. Der Workflow im Versionskontrollsystem basiert auf unserer git-flow-Präsentation und ist aus meiner Sicht zwar im Feinen anpassbar, im Groben aber alternativlos.

Ticketsystem Redmine richtig einstellen

Das Ticketsystem sollte von außen erreichbar sein. Der zur Verknüpfung benutzte User sollte im Ticketsystem aktiv sein und Projekte und Tasks – im Weiteren auch Issues genannt – zugewiesen haben. Zusätzlich muss die REST-Api in der Konfiguration des Ticketsystems aktiviert sein.

In PhpStorm geht es weiter

In PhpStorm geht man zunächst über die Tastenkombi cmd+“,“ (Mac) in die Einstellungen und navigiert zu Tools -> Tasks -> Servers. Dort setzt man nach Auswahl des Ticketsystems die URL und Zugangsdaten zu seinem Ticketsystem.

Ein Klick auf den Test-Button liefert das Ergebnis:

Im zweiten Reiter stellt man die Commit-Einstellungen ein. Das Ticketsystem Redmine ist in der Lage, Commit-Nachrichten auszulesen und darauf zu reagieren. Eine sinnvolle Einstellung zur Automatisierung spart hier wertvolle Zeit.

Optimaler Workflow in PhpStorm mit dem Ticketsystem Redmine

Die Voraussetzungen sind hier ein Projekt im ausgecheckten develop-Branch, ein vorhandenes Ticket und eine eingerichtete Entwicklungsumgebung.

Die Steuerungsleiste für das Taskmanagement befindet sich im rechten oberen Bereich.

Über das Dropdown kommt man in den „Task öffnen“-Dialog.

Nach erfolgreichem Öffnen eines Tasks sollte man eine für den Task eingerichtete Changelist in PhpStorm und auf Ebene der Versionskontrolle einen Feature-Branch ausgecheckt haben.

Sollte man seine relevanten Entwicklungen lokal abgeschlossen haben, kommt der Zeitpunkt, an dem man seinen Code committet. Durch die Nutzung der taskrelevanten Changelisten ist dies selbst bei Bearbeitung mehrerer Issues in einem Projekt durchschaubar. Zudem verringern die voreingestellten Informationen aus dem Ticketsystem die manuell einzugebenden Informationen.

Vor dem anschließenden Push zeigt PhpStorm eine Zusammenfassung der Änderungen.

Als Abschluss muss man das Feature leider noch manuell über das git-flow-Plugin schließen, aber ich hoffe, dass das in naher Zukunft automatisiert wird.

Als Meldung sollte PhpStorm einblenden, dass der Feature-Branch erfolgreich zurückgemerged wurde.

Es kann zudem vorkommen, dass PhpStorm die Changelist nicht löscht. Um die Ordnung nicht zu verlieren, hilft das manuelle Löschen.

Außerdem kann es helfen, bei zu vielen Issues in der Liste auch diese manuell zu löschen.

Überprüfung in der Versionskontrolle und im Ticketsystem Redmine

Wer ähnlich wie wir Redmine mit gitolite und dem redmine git hosting nutzt, kann jetzt in seinem Projekt bei Redmine im Projektarchiv seinen neuen Workflow überprüfen.

Weiterführende Informationen zum Beispiel vom PhpStorm-Hersteller Jetbrains bekommt ihr hier.

Nutzt ihr in euren PHP-Projekten eine andere Kombination von Ticketsystem, Versionskontrolle und IDE? Wenn ja, dann schreibt uns hier doch bitte mal, welche das sind. Denn von einem solchen Know-how-Austausch profitieren ja letztlich alle. Die oben beschriebene Kombination schulen wir übrigens auch.

Der Beitrag PhpStorm mit dem Ticketsystem Redmine nutzen erschien zuerst auf Entwicklungshilfe NRW.

Continuous what?

Als Dozent für die PHP-Schulungen von Entwicklungshilfe NRW interessiere ich mich über die reine PHP-Entwicklung hinaus für das Thema Continuous Integration (CI). Neben der lokalen Entwicklung mit Tools wie Vagrant und PhpStorm zur schnellen und guten Programmierung an PHP-Applikationen ist eine stabile Pipeline zum Testen und Ausliefern (Deployment) des Codes Gold wert. Funktionierende Automatisierung spart immer Zeit und Geld. Wenn zusätzlich dabei noch getestet wird, schlafe ich als Entwickler direkt ruhiger. CI-Tools machen genau das: Sie testen in einer Entwicklungsumgebung euren Code. Jeder Durchlauf eines Prozesses wird dabei „Build“ genannt. Ziel ist es, durch automatisierte Tests und die vorherige saubere Entwicklung einen fehlerfreien Build auszuliefern.

Vielen Entwicklern wird Jenkins (bzw. Hudson) ein Begriff sein. Wer andere Erfahrungen mit ähnlichen Tools gemacht hat, kann das gerne als Kommentar hier mit einbringen.

PHPCI als Continuous Integration Tool

Heute gebe ich eine kleine Einführung in PHP Continuous Integration, kurz PHPCI. Als PHP-Entwickler habe ich zwar gute Erfahrungen mit Jenkins gemacht – ich finde aber den Ansatz von PHPCI besser, als CI-Tool für PHP-Projekte in PHP geschrieben zu sein. So verstehe ich als Entwickler das Tool besser. Obwohl PHPCI noch ein recht junges Projekt ist, finde ich die derzeitige Funktion schon brauchbar, und es macht Spaß, damit zu experimentieren. Das Github-Projekt findet ihr hier. Doch vor dem Vergnügen kommt erstmal kurz die Arbeit, sprich die Installation. Als Voraussetzung wird hier von einem Debian-basierten Webserver mit installiertem Apache und MySQL-Server ausgegangen. Paketinstallationen auf einem Server sowie das Tool composer sollten euch geläufig sein.

Installation von PHPCI

Zunächst wechseln wir in das Webverzeichnis des Servers (default /var/www):

cd /var/www

Nun erstellen wir per composer das PHPCI-Projekt. Bei dem letzten Befehl solltet ihr eure Datenbank-Zugangsdaten zur Hand haben.

composer create-project block8/phpci phpci --keep-vcs --no-dev
cd phpci && composer install
./console phpci:install

Das Ergebnis sollte so aussehen:

Eine einfache Vhost-Konfigurationsdatei, die dem Apache hinzugefügt und aktiviert wird, reicht zum Aufrufen unseres neuen Tools zur Continuous Integration:

    ServerAdmin __ADMIN__@__SERVER__
    ServerName phpci.__SERVER__
    DocumentRoot /var/www/phpci/public
    
        DirectoryIndex index.php
        Options Indexes FollowSymlinks MultiViews
        Require all granted
        AllowOverride All
        
    LogLevel warn

Solltet ihr nicht mit einer Seite wie dieser hier empfangen werden, schaut bitte in die Installationshilfe auf der PHPCI-Seite nach oder schreibt uns hier.

Wenn ihr jetzt die eingetragene URL aufruft, seht ihr die Startseite eures neuen CI-Tools, und ihr könnt euch einloggen.

Dieser komplette Installationsvorgang dauert keine 30 Minuten. PHPCI ist eine kostenlose, quelloffene Variante, die euch in die Lage versetzt, sehr schnell eine eigene Build-Pipeline als Grundlage für eine Continuous-Integration-, Continuous-Delivery- oder Continuous-Deployment-Strategie aufzubauen. Um die beiden letztgenannten Punkte geht es an dieser Stelle allerdings nicht.

Weitere Posts zum Thema Continuous Integration

Ich versuche, hier so schnell wie möglich weitere Anleitungen über PHPCI zu posten. Geplant sind derzeit auf jeden Fall:

• Aufsetzen eines versionskontrollebasierten PHP-Projektes in PHPCI
• Unit-Tests mit PHPCI
• Acceptance-Tests mit Codeception in PHPCI
• Weitere Tests wie Mess Detection und Code Coverage

Ich hoffe, meine kurze Anleitung war hilfreich für euch. Wenn ihr noch Fragen dazu habt, könnt ihr diese gerne unter Verwendung der Kommentarfunktion stellen. Ansonsten verlinke ich relevante Posts hier.

Einen detaillierten Überblick über unsere PHP-Schulungen für Webentwickler findet ihr übrigens auf der Website von Entwicklungshilfe NRW.

Der Beitrag Continuous Integration: Eine Einführung in PHPCI erschien zuerst auf Entwicklungshilfe NRW.

Änderungen wie “Git ignore file mode” gehören dazu, da man diese Git-Einstellung nicht in jedem Projekt neu setzen muss. Es gibt mehrere Anwendungsfälle, die wir auch in unseren Git-Schulungen vorstellen werden. Es ist sinnvoll, die Einstellung global vorzunehmen – den Befehl sollte man aber dennoch auswendig kennen, falls man mal auf einem anderen System unterwegs ist.

Git ignore file mode global setzen

git config --global core.filemode false

Die oben abgebildete Zeile setzt durch den –global-Parameter die Einstellung global für den eingeloggten User. Das ist sehr praktisch, da die Einstellung in allen Projekten benötigt wird.

Git ignore file mode lokal setzen

git -c core.filemode=false diff

Neben der globalen Konfiguration ist es in Git natürlich auch möglich, die Einstellung nur für das aktuelle Projekt vorzunehmen. Der oben abgebildete CLI-Befehl setzt die Konfiguration nur für das aktuelle Projekt Verzeichnis.

Git filemode

Es kommt vor, dass durch Benutzerrechte Änderungen im lokalen Workspace entstehen und Git diese Änderungen als Change erkennt und committen möchte. Das ist zwar technisch richtig, häufig jedoch unerwünscht. Hierfür kann man ein Setting in der Git-Konfiguration setzen. Das lässt sich lokal oder global machen. Dessen sollte man sich immer bewusst sein und wissen, dass in Zukunft eventuell berechtigte Änderungen an den Zugriffsrechten nicht wirksam werden, wenn man das Setting global gesetzt hat. Für Änderungen in diesem seltenen Fall sollte man das Repo noch einmal explizit auschecken und die gewünschten Änderungen dort vornehmen und in das Remote Repository bringen. So spart man sich das lästige Hin- und Herkonfigurieren.

Weiterführende PHP-Schulung zum Thema Git

Wenn ihr euch gezielt zum Thema Git weiterbilden und viele praktische Tipps für eure Arbeit erhalten möchtet, könnte euch unsere entsprechende PHP-Schulung interessieren. Infos dazu findet ihr hier. Insgesamt zielen die Seminare und Workshops von Entwicklungshilfe NRW – ebenso wie unser Blog – darauf ab, Webentwicklern die Arbeit zu erleichtern und dadurch für mehr Spaß und Motivation zu sorgen. Wenn ihr euch übrigens gerade fragt, wie ihr eure Vorgesetzten vom Nutzen einer Weiterbildung überzeugen könnt, dann hilft euch vielleicht dieser Beitrag hier weiter.

Falls ihr noch Fragen zum Thema Git ignore file mode habt, dann könnt ihr diese gerne in den Kommentaren stellen. Wir werden euch so schnell wie möglich antworten.

Der Beitrag Git ignore file mode global oder lokal setzen? erschien zuerst auf Entwicklungshilfe NRW.

Redmine 3 mit Gitolite 3 installieren

Eine gelungene, kostenfreie Kombination für ein Ticketsystem mit Versionskontrolle bieten Redmine als Ticketsystem und git als Versionskontrolle. Gitolite dient dabei als Mittler, um Nutzer des Ticketsystems gegenüber dem eigenen Git-Server zu authentifizieren und so die Versionskontrolle über das Ticketsystem steuerbar zu machen. Mehr dazu gibt es im neuen Jahr in einem eigenen Blog-Beitrag, den ich dann hier verlinke.

Voraussetzungen für die neue Infrastruktur

Dieser Artikel ist eine Anleitung, wie man auf einem eigenen, dafür geeigneten Server diese Kombination aufsetzt.
Ausgegangen wird hier von Debian als Betriebssystem, und der eingeloggte User ist root. Es wird vorausgesetzt, dass man Pakete installieren und einen einfachen Editor wie vim oder nano benutzen kann.

Zunächst installiert man die grundlegenden Softwarepakete, die benötigt werden:

apt-get install rubygems gitolite3 build-essential libssh2-1 libssh2-1-dev cmake libgpg-error-dev mysql apoache2

Anschließend werden dem System zwei User für git („git“) und Redmine („redmine“) hinzugefügt:

adduser --system --shell /bin/bash --gecos 'Git Administrator' --group --disabled-password --home /opt/gitolite git
adduser --system --shell /bin/bash --gecos 'Redmine Administrator' --group --disabled-password --home /opt/redmine redmine

Da das Ticketsystem später die Kontrolle über die Versionskontrolle ausüben soll, legen wir einen SSH-Key für den User redmine an:

su redmine
ssh-keygen -t rsa -N '' -f ~/.ssh/redmine_gitolite_admin_id_rsa
exit

Versionskontrolle kontrollieren

Nun kann Gitolite mit

dpkg-reconfigure gitolite3

neu konfiguriert werden, da die Konfiguration bei Installation ein paar Settings anders setzt, als wir es gerne hätten. Die Parameter zur Konfiguration sind:
user: git
repos path: /opt/gitolite
admin ssh-key: /opt/redmine/.ssh/redmine_gitolite_admin_id_rsa.pub

Redmine und Gitolite benötigen teilweise sudo-Rechte für den jeweilig anderen User, Redmine für die Installation temporär sogar darüber hinaus. Dazu konfigurieren wir unseren Server für das Ticketsystem mit Versionskontrolle mit

visudo

Folgendes wird zusätzlich eingetragen:

# temp – *REMOVE* after installation
redmine ALL=(ALL) NOPASSWD:ALL

# redmine gitolite integration
redmine ALL=(git) NOPASSWD:ALL
git ALL=(redmine) NOPASSWD:ALL

Installation des Ticketsystems Redmine

Jetzt wird Redmine installiert. Dazu loggen wir uns als User redmine ein und wechseln in sein Home-Verzeichnis.

sudo su - redmine
cd ~

Wir befinden uns jetzt in /opt/redmine, wo wir den aktuellen Code über github ziehen.

git init
git remote add origin https://github.com/redmine/redmine.git
git fetch -p

Da wir uns im Home-Verzeichnis befinden, schließen wir noch ein paar Verzeichnisse und Dateien aus:

vim .gitignore

Auszuschließende Items sind zum Beispiel:
.ssh/
.bash_history

Als nächstes checken wir die aktuelle stabile Version aus.

git add .gitignore
git commit -m 'local gitignore'
git checkout 3.1-stable

An dieser Stelle kann man jetzt noch die Quelle vom Original zu einer eigenen Quelle verschieben.

git remote rm origin
git remote add origin __URL__

Wir benutzen Redmine mit einer MySQL-Datenbank. Sollte noch kein MySQL-Server installiert sein, bitte nachholen. Ansonsten mit

mysql -u root -p -v -e "CREATE DATABASE redmine CHARACTER SET utf8; CREATE USER '__USER__'@'localhost' IDENTIFIED BY '__PASSWORD__'; GRANT ALL PRIVILEGES ON redmine.* TO '__USER__'@'localhost';"

__*__ bitte mit geeigneten Werten ersetzen.

Das oben erstellte Login verwenden wir nun zur Konfiguration von Redmine. Wir kopieren die Config-Templates und editieren diese:

cd /opt/redmine/config
cp database.yml.example database.yml
cp configuration.yml.example configuration.yml

vim database.yml
vim configuration.yml

Erweiterte Erläuterungen zur Konfiguration gibt es hier für die Datenbank und hier für Generelles.

Danach wechseln wir zurück ins Home-Verzeichnis und beginnen mit der Installation. Zur eigentlichen Installation von Redmine müssen wir im Gemfile noch eine Anpassung vornehmen.

cd ~
sudo gem install bundler
nano Gemfile

Hier ändern wir die mysql2-Version auf 4.2.0, wenn man Percona als MySQL-Server in der Version 5.6 benutzen möchte.

Jetzt wird endlich installiert:

bundle install --without development test postgresql sqlite
rake generate_secret_token
RAILS_ENV=production rake db:migrate

Plugins für das Ticketsystem

Nachdem Redmine grundlegend installiert wurde, kümmern wir uns jetzt um die Plugins:

cd ~/plugins
git clone https://github.com/jbox-web/redmine_bootstrap_kit.git
git clone https://github.com/jbox-web/redmine_git_hosting.git
cd redmine_bootstrap_kit/
git checkout 0.2.4
cd ../redmine_git_hosting/
git checkout 1.2.0
cd ~
bundle install --without development test
bundle exec rake redmine:plugins:migrate RAILS_ENV=production NAME=redmine_git_hosting

Der eingangs erstellte SSH-Key wird jetzt in das Plugin verlinkt:

ln -s /opt/redmine/.ssh/redmine_gitolite_admin_id_rsa /opt/redmine/plugins/redmine_git_hosting/ssh_keys/redmine_gitolite_admin_id_rsa
ln -s /opt/redmine/.ssh/redmine_gitolite_admin_id_rsa.pub /opt/redmine/plugins/redmine_git_hosting/ssh_keys/redmine_gitolite_admin_id_rsa.pub

Das Ticketsystem mit Versionskontrolle überprüfen

Wir wechseln jetzt auf die Seite des Users git und überprüfen Gitolite.

sudo su - git
sed -i 's/$GL_GITCONFIG_KEYS = ""/$GL_GITCONFIG_KEYS = ".*"/g' /opt/gitolite/.gitolite.rc
exit
ssh -i .ssh/redmine_gitolite_admin_id_rsa git@localhost info

Dabei sollte eine Antwort ähnlich wie diese hier kommen:
hello admin, this is git@__SERVER__ running gitolite3 3.6.1-2 (Debian) on git 2.1.4

R W gitolite-admin
R W testing

Als letztes wird nun Redmine mittels des Passenger-Moduls zum Laufen gebracht. Es wird vorausgesetzt, dass ein entsprechender vhost-Eintrag existiert, der auf /opt/redmine/public verweist. Das Passenger-Modul installiert man mit

passenger-install-apache2-module

und trägt danach die in der Installation erzeugten Pfade in die apache-Konfiguration ein.

Bei mir hat diese Anleitung zum Aufsetzen eines Ticketsystems mit Versionskontrolle bisher immer sehr gut funktioniert. Wenn ihr Probleme habt, schreibt bitte in die Kommentare, damit diese Anleitung ständig verbessert werden kann. Gleichzeitig können wir durch den regen Ausstausch mit euch aber auch die Qualität unserer PHP-Schulungen für Webentwickler noch weiter erhöhen.

Quellen und weiterführende Links:
Redmine
Gitolite
Redmine und Gitolite
Apache Passenger
Redmine git hosting
Redmine git hosting Plugin-Seite

Der Beitrag Ticketsystem mit Versionskontrolle erschien zuerst auf Entwicklungshilfe NRW.

„WordPress ohne FTP updaten (oder installieren)“ ist eine vielgenutzte Phrase bei der Google-Suche – kein anderes bekanntes CMS-System nutzt diese Art für die Installation und die Aktualisierungen bei Plugins. Insofern ist es immer wichtig, im Vorfeld Sicherheitsmaßnahmen zu definieren und dann vor allem auch umzusetzen. Regelmäßige Updates sind ebenfalls von zentraler Bedeutung für die Sicherheit in Open-Source-Anwendungen. Das WordPress-Backend macht zuverlässig und übersichtlich auf Aktualisierungen aufmerksam.

Plugins: WordPress ohne FTP updaten

Damit die Installationen von WordPress ohne FTP (File Transfer Protocol) vorgenommen werden können, ist es nötig, ein Setting in der wp-config.php hinzuzufügen.

define('FS_METHOD', 'direct');

Mit dem oben abgebildeten Setting ist es möglich, als eingeloggter User alle Aktualisierungen von WordPress im Backend vorzunehmen. Nach den Aktualisierungen kann man die Zeile dann wieder auskommentieren. Generell sind Updates nur durchzuführen, wenn man vorher ein vollständiges Backup erstellt hat. Zu dem Thema habe ich bereits einen Gastbeitrag in einem Online-Fachmagazin veröffentlicht.
http://www.zielbar.de/blogger-erfolgreich-wordpress-einsetzen-4251/

FTP und die Frage der Sicherheit

Das FTP wird gerade bei einfachen Hosting-Lösungen häufig eingesetzt. In dem Artikel FTP: Die unterschätzte Sicherheitslücke findet man eine Auflistung möglicher Schwachstellen. (WordPress-)Updates ohne FTP sind nur eine davon. Grundsätzlich gibt es in puncto Sicherheit keinen 100-prozentigen Schutz, und außerdem gilt noch immer der Leitsatz: „Statistische Sicherheit: Ein System wird dann als sicher bezeichnet, wenn für den Angreifer der Aufwand für das Eindringen in das System höher ist als der daraus resultierende Nutzen. Deshalb ist es wichtig, die Hürden für einen erfolgreichen Einbruch möglichst hoch zu setzen und damit das Risiko zu reduzieren„. Denn ist der Aufwand für den Angreifer zu hoch, so lässt er schnell ab. Näheres dazu (und mehr Wissenswertes zum Thema) findet man in dem Wikipedia-Eintrag zu Informationssicherheit.

Daher hat WordPress FTP als Sicherheitsbarriere eingebaut. So kann auch ein Administrator keine Plugins installieren oder aktualisieren, ohne einen FTP-Zugang zu haben. Das gibt es in anderen CMS-Systemen wie TYPO3 nicht. Professionelle Hosting-Lösungen arbeiten mit einem SSH-Zugriff. In Kombination mit einem SSH Key hat man die Zugriffe sehr gut unter Kontrolle und kann sie gegebenenfalls sofort wieder entfernen. Zudem wird auch protokolliert, wer die Änderungen durchgeführt hat. Bei FTP-Zugängen von Webhosting-Paketen gibt es in der Regel nur einen Zugang, den dann mehrere Personen nutzen. Änderungen bedeuten also zusätzlichen Kommunikationsaufwand.

WordPress Hosting Backups

Auch der Verlust eines privaten Hobby-Blogs ist sehr schmerzhaft. Man muss aber kein Sicherheitsexperte werden, damit man einen Blog erfolgreich und sicher betreiben kann. Wichtig ist aber in jedem Fall ein zuverlässiges Backup, damit man jederzeit den Stand von gestern oder vorgestern wiederherstellen kann. Das beseitigt zwar nicht das Sicherheitsloch an sich, aber es begrenzt schon mal erheblich den entstandenen Schaden. Denn so geht dann maximal die Arbeit von 24 oder 48 Stunden verloren – das ist zwar immer noch ziemlich ärgerlich, aber letztlich noch überschaubar. Achtet bei euren Hosting-Anbietern also genau auf die Backup-Strategie! Wichtig sind Frequenz, Menge und Ausmaß. Hingegen nur die Datenbank zu sichern, reicht nicht aus.

Entwicklungshilfe bei WordPress-Blogs

Fragen zum Thema WordPress & Hosting beantworten wir gerne und leisten auch tatkräftig Unterstützung. Nehmt dazu einfach Kontakt mit uns auf.

Der Beitrag Plugins: WordPress ohne FTP updaten erschien zuerst auf Entwicklungshilfe NRW.