eBizTalk - Berichten, Unterhalten, Weiterbilden
Ob Branchendiskurs, Fachartikel oder ein Blick hinter die Unternehmenskulissen: eBizTalk ist die Plattform, die uns auffordert, unsere Leser über Events und Projekte auf dem Laufenden zu halten. Und uns gegenseitig natürlich auch.

DevOps - eine schöne neue Welt?

Veröffentlicht am 17.04.2017 von Florian Hieber , DevOps , ALM

Die DevOps Welt ist recht neu und mit agilen Ansätzen versehen. Theoretisch klingt das sehr gut, aber wie sieht es in der Praxis aus? Wie gut ist das Produkt, dass dabei herauskommt? Wo liegen die Schwierigkeiten? Ich versuche mich einmal an einer Betrachtung.

Microsoft propagiert seit Neustem die Prinzipien von DevOps – also dem Schulterschluss zwischen Softwareentwicklern (Developer) und IT-Betrieb (Operations). Noch vor einem Jahr gab es auf der Technical Summit 2015 Empfehlungen, die auf der diesjährigen Tech Summit wieder verworfen wurden. DevOps ist dieses Jahr das Trendthema schlechthin. Es gab sehr viele Vorträge, eine Keynote und eine Diskussionsrunde zu dem Thema. SCRUM, Canban oder gar klassische Vorgehensmodelle wurden noch nicht einmal angesprochen. Als zertifizierter Projektleiter und SCRUM Master bin ich naturgemäß an neuen Vorgehensmodellen interessiert. Dementsprechend verfolge ich den DevOps-Ansatz schon über ein Jahr mit Interesse.

Deshalb habe ich mich unter anderem auch dazu entschlossen, an der Tech Summit in Darmstadt teilzunehmen und dort einige Veranstaltungen zu diesem Thema zu besuchen. Gerade die Diskussionsrunde war sehr spannend, da auch einige Teilnehmer dabei waren, für die DevOps nicht nur graue Theorie war, sondern gelebtes Verhalten. Zwei Teilnehmer waren sogar aus der mittleren Führungsebene, die DevOps in ihr Unternehmen gebracht haben und die ihre Erfahrungen ebenfalls bereitwillig geteilt haben. Ein weiterer Teilnehmer war Administrator und konnte seine Erfahrungen mit DevOps ebenfalls vorbringen. Um es vorweg zu nehmen, es gab niemanden, der DevOps lebte und unzufrieden war. Aber was ist DevOps überhaupt?

DevOps ist eine Methodik, die Softwareentwicklung unter agilen Gesichtspunkten ansieht.

  • Entwickelt werden Produkte, es geht nicht um Projekte
  • Produkte werden durch Funktionen beschrieben
  • Projekte dagegen werden durch Kosten, Zeit und Annahmen der Funktionen beschrieben
  • Projekte dagegen beziehen den Auftraggeber nur sehr eingeschränkt ein
  • Zum Team gehören Betreiber und Entwickler des Produktes
  • Release-Zyklen sind sehr kurz (bis zu mehrmals täglich)

Die Idee, Betrieb und Entwicklung als zusammengehörige Einheiten zu betrachten, ist sicherlich gut, erfordert aber ein Umdenken im gesamten Unternehmen und nicht zuletzt bei den Beteiligten. Ein Prozess, der bislang auch in den Aussagen der Beteiligten noch nicht abgeschlossen ist. Der Gedanke, Produkte zu entwickeln und nicht Projekte zu definieren ist nicht neu, sondern wird bei allen agilen Methoden genutzt. Die Nachteile (keine Kostenschätzung möglich, keine Kontrolle des Funktionsumfangs möglich, etc.) sind immer noch in den Köpfen der meisten Mitarbeiter und der Führungsebene fest verankert. Dieses Denken steht der DevOps Methode auch entgegen. Neue Ansätze, wie eine engere Zusammenarbeit zwischen Betrieb und Entwicklung finden sicher schnell Gefallen im Unternehmen, mehrmals am Tag ein produktives System neu zu releasen aber ganz sicher nicht. Unternehmen, die DevOps einsetzen, stellen mehrmals am Tag ein Release ein. Damit der Prozess aber von anderen Abteilungen akzeptiert wird, nennen sie den Vorgang dann „Update“.

Ein „Release“ hatte bislang immer eine Besonderheit inne. Nicht nur aus der Gefahr, Fehler in den produktiven Betrieb zu bringen, sondern auch aus Marketing Gesichtspunkten. Ein Release war eine Neuerung, die vielleicht sogar preisliche, sicher aber funktionale Änderungen beinhaltete, die es wert waren, angekündigt zu werden. Auch das fällt mit DevOps weg.

Besonders die sehr kurzen Zyklen zur Bereitstellung neuer Funktionen am Produkt werfen aber die Frage auf, wie man in so kurzer Zeit verlässlich Testen kann. Um es vorweg zu nehmen, keine der beteiligten Parteien und auch die anderen Beiträge brachten mir da eine wirklich befriedigende Antwort.

In der Diskussion kamen viele Stimmen auf, die meinten, Tests (von Unit bis Systemtests) würden nichts bringen und nur Zeit und Geld kosten, deshalb hätten sie das Testen auf Akzeptanztests reduziert. Diesen Ansatz halte ich für problematisch, auch wenn es bislang laut der Anwesenden zu keinen großen Problemen gekommen sei. Die Gefahr, dass es zu solchen Problemen kommen kann, ist doch sehr hoch. Ganz zu schweigen davon, dass weder Qualitätskontrollen noch Zertifizierungen möglich sind. Quality Gates sind in den Köpfen vieler Menschen keine Kostenfresser, sondern unerlässlich, wenn man ISO-zertifizierte Qualität liefern will.

Auch sollen nach der Meinung von Microsoft keine Branches zu Testzwecken im Code Repository genutzt werden. Nach der Entwicklung (und Test) auf dem lokalen Entwicklerrechner geht es in die Produktion. Richtig ist das Argument der DevOps-Verfechter, dass normalerweise keine großen Änderungen in den Zyklen gemacht werden und deshalb ein auftretender Fehler auch schnell rückgängig gemacht werden kann. Was ist jedoch mit schleichenden Fehlern, die erst sehr spät auffallen, da sie sich auf Bereiche im Produkt auswirken, die man nicht im Fokus hatte? Ein Fehler, der erst nach Wochen, also nach mehreren Zyklen, auffällt ist durchaus möglich und nicht nur Theorie. Ob man dann auch noch so schnell reagieren kann?

Bislang konnte ich keine Person ausfindig machen, die wirklich negative Erfahrungen mit DevOps gemacht und die Methodik dann wieder verworfen hat. Insofern scheinen meine Zweifel nicht berechtigt, dennoch werde ich sie nicht los. Meine Berufserfahrung scheint meiner Gutgläubigkeit etwas entgegenzustehen.

Trotz meiner Zweifel bezüglich Test und Dokumentation finde ich die Methodik sehr interessant und würde gerne einmal eine Produktentwicklung mit DevOps unterstützen.

google_about_ebiz fb_about_ebiztwitter_about_ebizxing_about_ebiz
ebiz_consulting_expertise

Wir haben auch noch Schoki da!

Veröffentlicht am 28.02.2017 von Clemens Kruse , DevOps , Cloud , Event

Rub a little DevOps on it - “Delivering Value to our Customers. That’s what it is about.”

Donovan Brown hat mich auf der Technical Summit durchaus beeindruckt. Trotz der fortschrittlichen Inhalte seiner Keynotes lag das aber vor allem daran, dass er schlichtweg ein Entertainer ist. Dies trifft nicht nur auf Donovan zu.

Mein Gesamteindruck der Technical Summit 2016 ist ein Mix aus Entertainment, Werbung und sehr guten Ideen. Ich bekam zahlreiche Eindrücke, wie gewisse Probleme angegangen werden können - die Methoden dazu gibt es aber nicht erst seit gestern. Der Fokus der meisten Vorträge lag auf dem Thema „Microsoft ❤ Open Source“. So auch der von Donovan, der ein Szenario aus Ubuntu + aspnet core + Docker + yeoman + Visual Studio Code präsentierte, um die Nachricht der neu entdeckten Affinität von Microsoft zu Open Source Software zu verbreiten.

Erste Tutorials mit ähnlichen Szenarien gibt es allerdings schon seit Februar 2016 (beispielsweise dieses hier: https://blogs.infosupport.com/build-deploy-test-aspnetcore-docker-linux-tfs2015/ oder hier: http://blog.codingtimes.com/2016/06/29/net-core-mvc-web-application-at-ubuntu-16-04-with-yeoman-docker-and-visual-studio-code/). Ich wollte einigen Impulsen folgen und das ein oder andere Tutorial nachbauen und habe recht schnell gemerkt, wie umständlich das ganze Prozedere ist. Bisher habe ich in Visual Studio nur ein Projekt-Template gewählt, programmiert und nach getaner Arbeit schließlich via Rechtsklick die Solution bereitgestellt. Jetzt fühlt es sich so an, als hätte man den Ferrari gegen einen Lada eingetauscht, weil der Lada-Verkäufer so charmant gewesen ist.

Meinen persönlichen Höhepunkt hatte die Ferrari-Lada-Metapher im Vortrag „Yo ASP.NET – was ist neu und was bleibt mit ASP.NET Core 1.0“. DOTNET ist mit Core nun modular geworden. Das ist schön. Da Microsoft ja mittlerweile Open Source liebt, wurde auch in diesem Vortrag alles mit Ubuntu und VS Code umgesetzt. Das heißt im Klartext: alles zu Fuß. Das funktioniert sicherlich irgendwie (wenngleich die Demo etwas holprig verlief), hat aber meiner Ansicht nach nichts mit Fortschritt zu tun. Um das Publikum während des Vortrages bei Laune zu halten, wurden die Schokoladen-Reste vom Nicolaus verteilt. „Wenigstens gab es Schoki“ wird der ein oder andere Besucher am Ende der Veranstaltung gedacht haben.

Fazit aus Perspektive des Studenten: Um sich Impulse zu holen war die Technical Summit 2016 in Darmstadt sehr gut geeignet. Auch das Essen war deutlich besser, als das was man aus der Mensa gewohnt war. Und zwischendurch gab es auch richtig gute Vorträge. „Machine Learning for Developers“ von und mit Seth Juarez war einer davon. Richtig in die Tiefe gehen muss man jedoch immer noch selbst. Immerhin haben mich die zwei Tage dazu gebracht, mich mehr mit Docker und Microservices auseinanderzusetzen. Wenngleich ich auch dort in meinem Mini-Projekt (WCF-Service in einem Container) in der begrenzten Zeit nur an der Oberfläche kratzen konnte.

google_about_ebiz fb_about_ebiztwitter_about_ebizxing_about_ebiz
ebiz_consulting_expertise