Aufrufe
vor 4 Jahren

Netzwoche 10/2016

  • Text
  • Unternehmen
  • Schweiz
  • Netzmedien
  • Schweizer
  • Devops
  • Webcode
  • Swisscom
  • Digitalisierung
  • Digitalen
  • Zudem

Bild: iStock Dossier

Bild: iStock Dossier DevOps In Kooperation mit Digicomp Harmonie über Abteilungsgrenzen hinweg mur. Gartner prophezeit, dass DevOps dieses Jahr zu einer Mainstream-Strategie für Firmen aufsteigen wird. 25 Prozent der von Forbes gekürten Global-2000-Unternehmen sollen die Philosophie bis dahin anwenden. DevOps setzt sich aus den englischen Wörtern Development und Operations zusammen. Bei dem Ansatz geht es darum, Schnittstellen zwischen Softwareentwicklung und IT-Betrieb zu optimieren. Etwa durch bessere Kommunikation, enge Kooperation und schlaue Automatisierung. Diese Massnahmen sollen dazu führen, dass IT-Lösungen schneller und kostengünstiger in die Produktion überführt werden können. Diese Erklärung greift aber zu kurz, denn hinter DevOps steckt noch viel mehr – es ist eine Kultur, eine Denkweise, eine neue Art, Projekte anzupacken. Was der Begriff beinhaltet, verrät Marc Müller, Principal Consultant für Microsoft-ALM-, .Net- und Windows-Azure-Lösungen bei 4tecture, in diesem Dossier. In einem Fachbeitrag erläutert er, was DevOps genau bedeutet, warum es auch für Unternehmen in der Schweiz sinnvoll ist, und worauf diese bei der Umsetzung achten müssen. Müller stellt sich zudem den Fragen der Redaktion. Im Interview verrät er etwa, was Entwickler und Engineers tun müssen, um bei Dev Ops am Ball zu bleiben. Und Unternehmen gibt er Tipps, wie sie mit dem sehr umfassenden Thema umgehen können. 10 / 2016 www.netzwoche.ch © netzmedien ag

In Kooperation mit Digicomp DevOps DOSSIER 29 DevOps – die nächste Evolutionsstufe der agilen Entwicklung? DevOps ist derzeit in aller Munde und das Schlagwort schlechthin in Entwicklungsabteilungen. Was verbirgt sich hinter diesem Begriff, und wie bringt man sein Entwicklungsteam und Unternehmen dorthin, DevOps zu leben und zu betreiben? DevOps kombiniert die Entwicklung (Development) und den Betrieb (Operations), doch es verbirgt sich weitaus mehr dahinter. der autor Marc Müller arbeitet als Principal Consultant für Microsoft ALMsowie .NET-/Windows-Azure- Lösungen bei 4tecture. Der Autor ist Keynote- Speaker am DevDay 2016 am 22. Juni bei Digicomp. Der Softwaremarkt und die Erwartungshaltung der Kunden haben sich in den letzten Jahren stark verändert. Die alten Methoden, Software zu entwickeln, die mit langen Planungsphasen und Entwicklungszeiten verbunden waren, funktionieren nicht mehr. Die Organisationen, die flexibel sind und neue Features zu den Kunden bringen, werden sich durchsetzen und überleben. Ein wenig anders formuliert heisst dies, dass eine Organisation mit ihrer Softwareentwicklung kontinuierlich Kundennutzen liefern und somit den Kunden beziehungsweise den Stakeholder ins Zentrum ihrer Tätigkeiten setzen soll. Vielen, die schon seit längerem agil Software entwickeln, dürfte diese Aussage bekannt sein. DevOps ist nicht etwas komplett Neues, sondern basiert auf agilen Methoden und reichert diese mit neuen Möglichkeiten an. Die wichtigste Erkenntnis, wenn wir uns als Unternehmen DevOps auf die Fahne geschrieben haben, ist, dass wir nicht einen DevOps- Verantwortlichen einstellen können und nun auf Kurs sind. DevOps ist Kultur und Denkweise und kein Programm oder eine einzelne Anstellung. Wir müssen also die ganze Organisation mitsamt ihren Prozessen daraufhin ausrichten. Wir erzeugen Kundennutzen und somit mit jedem Release einen Mehrwert. Um kurze Releasezyklen mit gleichbleibender oder gar gestiegener Qualität zu ermöglichen, ist es wichtig, einen hohen Grad an Automatisierung zu erreichen. Einen neuen Release zu erstellen, darf also keine Schmerzen in Form von hohen Aufwänden und vielen manuellen Schritten verursachen, sondern muss möglichst auf Knopfdruck automatisiert durchgeführt werden können. Dazu zählen die Build- und Release-Automatisierung sowie die Testautomatisierung. Ausserdem müssen wir eine Fail-Fast- Kultur etablieren. Man darf, nein, muss sich sogar trauen, neue Wege zu beschreiten, aber auch den Mut haben, zu erkennen, wenn man sich auf dem falschen Weg befindet, um zum richtigen Zeitpunkt das Steuer herumzureissen. Eric Ries beschreibt in seiner Lean-Start-up-Methodik den Build- Measure-Learn-Zyklus. Wir erstellen ein Stück Software, einen Kundennutzen, und analysieren (measure) dieses mit verschiedensten Metriken. Wie wird die Software vom Kunden genutzt? Gibt es Fehlerzustände? Welchen Einfluss hat dies auf unsere Infrastruktur und den Betrieb? Wie können wir die Funktionalität verbessern? Aus all diesen Analysedaten führen wir nun die Schlussfolgerungen zusammen, was Einfluss auf unser Backlog und somit die nächsten Entwicklungsphasen hat. Genau dieses Feedback gibt uns auch den Rückhalt, die Richtung nötigenfalls zu wechseln. Wer möchte schon Geld und Zeit in ein Feature investieren, das von den Kunden nicht genutzt wird? Hier haben wir nun eine wichtige DevOps-Ergänzung zur agilen Entwicklung kennengelernt: Wir entwickeln das Backlog weiter (Backlog Grooming), indem wir das Learning (Build-Measure-Learn) aus dem Betrieb einfliessen lassen. Aber nochmals zurück auf Start: Wie kommt man nun also zu einer effizienten und erfolgreichen DevOps- Kultur mit den damit verbundenen Prozessen und dem richtigen Tooling? Als Berater werde ich oft nach einer pfannenfertigen Lösung gefragt. Es dürfte allen klar sein, dass in diesem hochkomplexen Umfeld vielen Einflussfaktoren Rechnung getragen werden muss und es somit nicht die eine Lösung gibt. Wenn wir aber anstelle der pfannenfertigen Lösung, den Köchen ein Kochbuch mit den Grundlagen in die Hand geben, ist dies sicherlich ein guter Start. Es gehört viel Erfahrung und Expertise dazu, den eigenen DevOps-Prozess zu optimieren. Aber wie wir vorhin bereits gelesen haben, ist dies am Ende auch nichts anderes als Build-Measure-Learn. Welche Kapitel beinhaltet nun unser Kochbuch? Team-Autonomie und Unternehmensplanung in Einklang bringen Die Team-Autonomie ist ein wichtiger Bestandteil der agilen Entwicklung. Sie dient der effektiven Umsetzung im Team. Die Herausforderung ist es nun, die Automomie eines Teams mit den Unternehmenszielen beziehungsweise dem Gesamtziel mehrerer Teams und deren Planung in Einklang zu bringen und diese periodisch zu überprüfen und abzugleichen. Die meisten Organisationen arbeiten mit Sprints mit einer Länge von zwei bis vier Wochen. Aus Unternehmens- beziehungsweise Produktsicht müssen wir aber den Horizont weiter aufspannen. Oft wird die Planung in folgende Komponenten unterteilt: kurzfristige Planung (Backlog-Priorisierung) über die nächsten Sprints (in der Regel drei Sprints), Produkt-/Geschäftsziele über die nächsten sechs Monate (Definition der Epics) sowie die Vision für die nächsten ein bis zwei Jahre. Aufgrund dieser Planungszyklen erhalten die Teams ein heruntergebrochenes Product Backlog für die Sprintplanung. Die technische Schuld beherrschen Unter technischer Schuld versteht man den Zusatzaufwand, der schlecht geschriebene Software mit sich bringt. Bei sich weiterentwickelnden Anforderungen und der damit verbundenen sich verändernden Softwarearchitektur mittels Refactorings, ist es enorm wichtig, die technische Schuld zu überwachen und aktiv abzuarbeiten. Der Source Code sollte in einem zentralen Integrationsbranch mit kurzen Feature-Branches verwaltet werden. So driften die Code- Stände nicht auseinander und das Zusammenführen gestaltet sich www.netzwoche.ch © netzmedien ag 10 / 2016

Archiv