Continuous Delivery: Zwischen Null und Hundert Prozent

Moderne Projekte erfordern moderne Methoden. Continuous Delivery ist bereits fester Bestandteil. Moderne Methoden werden mit modernen Werkzeugen verknüpft. So wird Continuous Delivery oft in einem Atemzug mit Tools wie Puppet, Chef oder ähnlichen Tools aus dem Sektor “Infrastructure as Code” genannt.

Was jedoch, wenn moderne Werkzeuge nicht eingesetzt werden können oder wollen? Bevor man bei Null bleibt, gibt es immer noch andere Möglichkeiten. Ich möchte in diesem Artikel ein Beispiel zeigen, wie man mit relativ einfachen Mitteln ein Continuous Delivery umsetzen kann. Ich konzentriere mich dabei auf den Schritt “Build System”.

Build - Test - Release
Schritte im Continuous Delivery: Build – Test – Release

Continuous Delivery: Zwischen Null und Hundert Prozent weiterlesen

Umgebungsabhängige Laufzeitkonfiguration mit Profil

Softwaresysteme laufen in der Regel in mehreren Umgebungen. Bei Webapplikation sind beispielsweise Entwicklungs-, Nighly Build-, Stage- und Produktionsumgebung üblich. Während die Geschäftslogik in allen Umgebungen gleich ist, unterscheiden sich die Konfigurationen mitunter erheblich. Bei der Konzeption und Architektur der Software muss diese Rahmenbedingung daher entsprechend berücksichtigt werden.
Umgebungsabhängige Laufzeitkonfiguration mit Profil weiterlesen

Schlechter Code!? Na und?! Funktioniert doch!

“Schlechter Code? Na und? Funktioniert doch!” Solche oder ähnliche Aussagen gibt es leider sehr oft. Ich vergleiche es oft mit einigen Schreibtischen, die mir während meinen Besuchen in Firmen auffallen: Verdörrte Pflanzen, Stapel von Papier und Ordner, Essensreste, leere Gläser, Cola-Flaschen und ähnliches. Leider sieht es im Code dann genauso oder ähnlich aus. Die Kollegen lassen sich meist nicht überreden ihren Saustall zu beseitigen. Hey, das könnte ein interessantes Thema für eine Studie sein: Besteht ein Zusammenhang zwischen Schreibtischgestaltung und Arbeitsergebnisse?

Zurück zum schlechten Code: Macht nichts? “Sauber machen wir dann später, wenn wir fertig sind und dann noch Zeit haben.” Lasst mich dazu eine kleine Geschichte erzählen:

Schlechter Code!? Na und?! Funktioniert doch! weiterlesen

Implizite Qualitätserwartungen

Jeder Entwickler kennt die Situation: Die Software ist gerade fertig gestellt und ausgeliefert und sofort treffen die ersten Fehlermeldungen ein: “Die Software reagiert unter bestimmten Situationen langsam.” Jetzt schnell nachgeschlagen in den nicht funktionalen Anforderungen.. und? Findet man dort etwas? Nein? Also kein Fehler?! Es war ja nicht spezifiziert. Der Ärger ist vorprogrammiert.

Jeder Architekt kennt die Situation: Eine Aufwandsschätzung wird vorgestellt und die geschätzten Aufwände sind – wie immer – zu groß. Jetzt beginnt das Feilschen und Argumentieren. Warum sieht die Lösung so aus? Geht das nicht günstiger? Braucht man so eine Infrastruktur? Können wir das Logging nicht weglassen?

Implizite Qualitätserwartungen weiterlesen