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.

Legacy-Code-Probleme sind überall bekannt

„Nirgends werden tote Pferde so weit geritten wie in der Software-Entwicklung“ heißt es auf meiner Website. Nicht von ungefähr. Denn als Trainer und Dozent im Bereich der Software-Qualität kann ich infrage kommende Code-Stellen, die nach Robert C. Martin gerne als „Code smells“ bezeichnet werden, auch ohne die Unterstützung von Software sehr schnell ausfindig machen. Zudem sind sie unter Webdevelopern durchaus bekannt. Aber sie werden aus Zeitgründen umschifft.

Dabei ist Legacy Code längst kein Problem mehr, welches nur auf den Backend-PHP-Teil betrifft. Denn da heute Webapplikationen geschrieben werden, ist der Anteil von Javascript beträchtlich – und in den kommenden Jahren wird sich das noch weiter verschieben: API-Schnittstellen, Webservices und Microservices werden den Teil des Backends in der Applikation darstellen und unterschiedlichste Clients im Frontend die bereitgestellten Daten verarbeiten. Mit Technologien wie React und AngularJS zeichnet sich hier ein sehr klares Bild des zukünftigen Webdevelopments ab.

Legacy-Code-Nester in Webdevelopment-Projekten

Bei den Frontend-Teilen eines Webprojekts braucht man gar nicht lange zu suchen. Große Ansammlungen sind hier z. B. main.css, style.css und natürlich script.js und app.js. Das sind große und historisch gewachsene Files, die immer nur erweitert werden und selten ein Code-Refactoring gesehen haben. Auch im Bereich der Backend-Entwicklung wird trotz Software-Design und Patterns oft nicht sauber gearbeitet.

Eben dort ist PhpStorm eine große Hilfe: Code, der offensichtlich nicht verwendet wird, wird farbig ausgegraut und kann so recht zuverlässig entfernt werden. Aber auch hier ist große Vorsicht geboten: Ohne automatisierte Tests ist es nahezu unmöglich, effektiv zu arbeiten. Fakt aber ist, dass durch die gewachsene Komplexität und die schlechte Lesbarkeit viel Zeit und Motivation verloren gehen. Wenn man da überhaupt noch durchsteigt. Dann wird gerne kapituliert, was sogar bis zur Krankmeldung gehen kann. Hier Licht reinzubringen, ist, wenn man es nicht regelmäßig macht, ein immenser, unausweichlicher und stetig wachsender Kostenfaktor.

Legacy Code verursacht weitaus höhere Projektkosten

Webdevelopment-Projekte sind in einem schlechten Software-Zustand nicht mehr wartbar, zumal nach und nach immer mehr Bugs ans Tageslicht kommen. Das richtet großen Schaden in sämtlichen Bereichen einer Firma an und kann diese sogar in den Ruin treiben.

Auch Kunden ist das mittlerweile klar geworden: Rund 30 Prozent Mehrkosten sind als On-Top-Budget für Software-Qualität längst eine feste kalkulatorische Größe. Damit werden dann beispielsweise automatisierte Tests eingeführt, um den Entwicklungsprozess optimieren zu können.

Legacy Code verhindert die Weiterentwicklung der Berufssparte

Wenn die verfügbaren Ressourcen eines Webdevelopment-Teams völlig aufgebraucht werden, leiden darunter Weiterbildung und Motivation sowie die Bereitschaft, sich mit Herzblut in seine Arbeit einzubringen. Code wird dann sprichwörtlich hingerotzt. Dabei ist gerade bei der heutigen Programmierung ein enorm hohes und komplexes Wissen gefragt. Das kann nicht mal eben mit einer einzelnen PHP-Schulung abgebildet werden.

Zudem wird es Junior-Webdevelopern auf diese Weise nahezu unmöglich gemacht, sich in die vorhandenen Strukturen zu integrieren. Hinzu kommt die vertane Zeit. Denn sich mit Problemen aus einer „anderen technischen Epoche“ auseinandersetzen zu müssen, ist nicht zielführend. Innovationen und Sprünge in der Entwicklung sind so nicht machbar. Man steckt im Sumpf der Legacy-Projekte fest.

Refactoring ist der Anfang vom Ende des Legacy Codes

Software-Qualität entsteht durch Refactoring von Quellcode. Man spricht hier auch von „Aushärten“. In allen Arbeitsbereichen wird dabei noch einmal über die bestehende Arbeit geschaut, um diese zu korrigieren und zu verbessern. Sogar ein einfacher Blog-Artikel wie dieser hier bekommt dadurch mehr als zehn Revisionen.

Betrachtet man hingegen Code-Stellen, bleibt man im unteren einstelligen Bereich. Hier muss wesentlich mehr Zeit investiert und eingeplant werden. Dies ist dann zugleich eine Investition in das eigene Webdevelopment-Team. Denn warum sollte man sich schwieriger und langsamer in Projekten bewegen, bloß weil der Kunde an diesem Punkt keinen Bedarf sieht …? Schließlich geht es nicht zuletzt um die eigene Software-Qualität – und damit letztlich auch um Lebensqualität.

Wir können Software-Projekte nicht neu schreiben

Noch immer gibt es die Illusion, dass eine Website alle paar Jahre komplett neu gemacht werden muss. Selbst auf Internetseiten, die an Werbekampagnen gebunden sind, soll dies zutreffen. Doch in „Wegwerf-Seiten“ wurde in aller Regel keine aufwendige Business-Logik implementiert – wie etwa in Bereichen des E-Commerce. Insofern ist es purer Wahnsinn, zu denken, man könne mit den vorhandenen personellen Ressourcen parallel einfach mal eine neue Seite entwickeln. Das ist der falsche Weg.

„Same old thinking – same old result“ ist hier ein Problem an sich. Es verhindert, dass sich Entwickler mit neuem Wissen frisch ans Werk machen können, zumal dadurch alte Probleme am Ende nur neu verpackt werden. Zudem ergeben sich beträchtliche Spannungen, wenn ein Teil des Teams neue Software schreiben muss, während der andere Teil den bestehenden Teil weiterpflegt. So kommt nur unnötige Unruhe auf, die dem Teamgeist schadet und das Projekt behindert. Allerdings ist es ohne Weiteres möglich, bestimmte Routen eines Projekts neu zu erstellen und somit sukzessiv Teile zu erneuern. Zu diesem Thema beraten wir gerne.

Mit Pair Programming Probleme erkennen und lösen

Vor allem Refactoring im Team bietet eine hervorragende Möglichkeit, mit Pair-Programming anzufangen. Nutzt man diese Chance, so bildet man gleich auch das Webdevelopment-Team weiter und spart eine ganze Menge Zeit, die sonst für Absprachen und Konventionen nötig wäre. Gerade der „doppelte Blick“ ist ja der Schlüssel dafür, Probleme zu erkennen und aus einem anderen Blickwinkel betrachten zu können. Wir bieten Schulungen mit genau diesem Ziel an. Da der Start mit Pair Programming jedoch nicht immer ganz einfach ist, ist eine externe Meinung umso wichtiger, damit es hier nicht zum Kompetenzgerangel kommt.

Legacy Code und der innere Schweinehund

Sport ist gut für die Gesundheit, gesunde Ernährung ohnehin, und Bewegung tut ihr Übriges. Ein gesunder Körper kann am Ende immer auf einen gesunden Geist zählen. Und halten wir zur Genüge daran? Nein. Wir verfügen über einen regelrechten Ausreden-Katalog, der von täglichen Problemen bis hin zum Wetter immer eine passende Ausrede für uns parat hält. Und dabei ist es doch einfach nur eine Kopfsache.

So ist es auch in der Software-Entwicklung. Hier verhalten wir uns aus mehreren Gründen unvernünftig. Wobei oft gar nicht erst nach Gründen gesucht, sondern ebenso wie beim Thema Sport & Gesundheit bei jeder Gelegenheit der „Keine-Zeit-Joker“ ausgespielt wird. Einfach mal mit einem festen Termin über zwei Stunden in der Woche freitags ab 16 Uhr starten! Das kommt auch erstmal gut an. Aber hier sind Ausdauer und Disziplin gefragt!

Wenn der Budget-Plan keine Software-Qualität zulässt

Investitionen in die Software-Qualität und in das Personal sind dringend notwendig. Aber oft lässt der Budget-Plan dies nicht zu. Doch wie weit kommt man mit einem Auto mit brennender Motorleuchte, ohne einen Motorschaden zu riskieren …? Schlimmstenfalls bis zum Totalschaden. Gleichermaßen riskant ist ein solch „blindes“ Vorgehen in der Software-Entwicklung. Und noch einmal: Darunter leidet immer auch die Stimmung in der gesamten Firma.

In puncto Software-Qualität muss also die richtige Entscheidung getroffen werden! Es gilt, konsequent Ziele zu beschließen und zu erreichen. Der Prozess muss kontrolliert und überwacht werden.

Mit zu viel Legacy Code werden Entwickler verheizt

Als Webentwickler mit Berufserfahrung findet man derzeit in jeder Stadt Arbeitgeber und kann sofort eine Stelle besetzen. Die Stellen selbst sind dabei, auch wenn die Gehälter einander entsprechen, höchst unterschiedlich. Wird der Entwickler gefordert und gefördert – oder doch nur verheizt? Etwa durch zu viel Legacy Code. Letzteres findet man überall. Ersteres vielleicht in den vier großen Städten. Vor allem Berlin zeigt, wie es geht. Und gerade deshalb gibt es dort auch so tolle Erfolgsstories.

Der Ruf der Entwicklungsabteilung und der Software-Qualität im Unternehmen ist ein zunehmend wichtiges Entscheidungskriterium für die Karriere. Daher gilt auch hier: Ist der Ruf erst ruiniert … Treffen Unternehmen indes die richtigen Entscheidungen, so festigt man die bestehenden Strukturen und macht sich attraktiv für neue Bewerber.

Mein Fazit zum Thema Legacy Code

Legacy Code ist nach wie vor ein großes Problem, das sich nur mit Arbeit lösen lässt. Doch ist man diesen Weg einmal gegangen, dann lohnt er sich. Denn klar ist:

• Die Software-Qualität steigt.
• Die Kunden sind zufriedener.
• Die Abteilungen können effektiv arbeiten.
• Der Spaß kehrt zurück an den Arbeitsplatz.

So betrachtet ist die gezielte und intensive Beschäftigung mit Legacy Code ein notwendiges Übel. Denn niemand mag es, ständig aufzuräumen und Ordnung zu halten. Für Profis gehört aber genau das nun einmal dazu.

Welche Erfahrungen hast du mit Legacy Code gemacht? Du kannst gerne das Kommentarfeld unter diesem Beitrag nutzen, um deine Erfahrungen mit anderen zu teilen.

Der Beitrag Legacy Code – Entstehung, Ursache und Auswirkung 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.