Laden...

Auswertung und Feedback zur DevOps-Umfrage

Erstellt von Abt vor 6 Jahren Letzter Beitrag vor 6 Jahren 5.711 Views
Abt Themenstarter:in
16.806 Beiträge seit 2008
vor 6 Jahren
Auswertung und Feedback zur DevOps-Umfrage

Auswertung der Ergebnisse der Umfrage Freiwillige, anonyme Umfrage zum Thema DevOps

Diese Umfrage hatte die grobe Überschrift "DevOps".
Ziel von mir war es zu erfahren, wie viele den DevOps Gedanken verfolgen - und wie viele immer noch nicht.

Diese Umfrage wurde mit Absicht nur in diesem Forum veröffentlicht, da ich besonders einen Einblick in die Welt der .NET Entwickler hier haben wollte.
Ich weiß, dass dies nicht der Durchschnitt aller Entwickler darstellt; war jedoch auch nicht gewollt. .NET Entwickler haben jedoch gerade durch Visual Studio Team Services/Team Foundation Server eine gesamtheitliche Plattform in ihrer Sprachnähe, die so aktuell keine andere Entwickler-Teilwelt bietet.
Dahingehend ist es besonders interessant: wer nutzt denn tatsächlich die aktuellen Möglichkeiten, um Zusammenarbeit und Qualität von Software zu tracken und zu steigern?

Grundsätzlich ging ich von folgenden Basisfragen aus:* Wie hoch ist der Anteil der Entwickler, die hier im Team arbeiten?

  • Wie viele arbeiten mit einem Quellcodeverwaltungssystem
  • Wie viele verwenden ein automatisches Buildsystem?
  • Zudem wie hoch der Anteil ist, die über ein Releasesystem verfügen

Es war also eher nicht relevant, ob jemand Angestellt oder Selbstständig im Team ist: es ging vor allem um das Team an für sich.
Genauso ging es nicht wirklich darum, welches Buildsystem genutzt wird - das ist prinzipiell nicht ganz so entscheidend - sondern ob eines genutzt wird.

Die Inhalte der Fragen - es waren neun insgesamt, wovon vier für die Auswertung hier von Relevanz sind - wurden geschmückt, um eine möglichst hohe Abdeckung zu haben.
Die Antworten wurden jedoch kumuliert; zB. wollte ich nur wissen, wie viele im Team arbeiten - ob das nun Angestellte, Beamter, Freelancer oder Studenten sind; das ist eigentlich zweitrangig.
Ein Team ist ein Team.

Die potentiellen Antwortmöglichkeiten wurden in den letzten Wochen gesammelt. Dass diese Liste niemals vollständig sein kann, sollte jedem bewusst sein.
Daher haben sich alle Möglichkeiten aus Gesprächen mit Besuchern / Zuhörern von Konferenzen und Usergroups ergeben. Hinzu kamen noch aktuelle Themen in Usergroups.
Dahingehend gab es auch (Zitat) "Exoten" wie Go und kein Delphi, da sich die Verbreitung einer Sprache im Gegensatz zum Wachstum - besonders in Firmen - nicht messen lässt.

Damit trotzdem jeder eine Chance hat etwas anzugeben das nicht zur Auswahl stand und sich dennoch angesprochen zu fühlen, gab es das Feld "Sonstige".
Der Fragebogen wurde also nicht gestaltet, um irgendjemand auszugrenzen, sondern hatte eine abgewogene Basis.

Ich bin jedoch davon ausgegangen, dass ich bei SurveyMonkey nachträglich Optionen anbieten kann, sollte sich herausstellen, dass dies hier mehrere Teilnehme der Umfrage aktiv nutzen.
Beispiel: TeamCity.

Von Vorn weg gleich mal die Nachrichten, die über das Kommentarfeld der Umfrage eingereicht wurden, da ich später nicht mehr drauf eingehen werde.

Wieder mal sehr oberflächlich, wo ist Delphi ? Scheinbar wieder nur deine eigenen Vorlieben (Mobile/Agile Entwicklung)

Erstaunlich, das bei den Programmiersprachen solche Exoten wie "Go" auftauchen, das durchaus verbreitete Delphi aber nicht 😉

Ich erspar mir/euch an dieser Stelle ein inhaltliches Kommentar zu diesen beiden Texten; ich würde auch ganz gern ein passendes Emoji dazu hinterlassen, nur leider unterstützt das Forum dieses Emoji aktuell nicht und auch existiert kein entsprechendes Smiley dazu hier im Forum.

Man sieht an dem Charakter der Aussagen schon, dass es den Personen weniger um die Umfrage ging, sondern nur um ihre persönlichen Präferenzen.
Auch war den beiden wohl egal, worum es in dieser Umfrage eigentlich ging (Titel: DevOps).
Meine Güte; wenn jemand etwas nicht passt - und das darf es im Rahmen der liberalen Meinungsfreiheit durchaus - wieso muss man denn immer gleich pöbelnd sein statt inhaltlich, wie andere es ebenfalls getan haben, nachzufragen...

Worauf die Antwortmöglichkeiten basieren, habe ich hier - mit Absicht im Nachhinein - erläutert. Trotzdem ein Hinweis in diesem konkreten Fall des Vorwurfs:
Go ist zB. dabei, weil es - offensichtlich - im Gegensatz zu Delphi extremen Anklang in den Communities findet.
Während Go die jeweils am stärksten wachsende Sprache 2009 und 2016 gehört, findet sich Delphi in den letzten 15 Jahren nicht auf diesem Treppchen.
Und wie gesagt: Verbreitung kann eben vor allem in Firmen nicht messen, aber Wachstum.

An die beiden Personen sei einfach dieser Link empfohlen: https://www.youtube.com/watch?v=rpk6K4EgHWc
Solche Personen braucht eine Community wirklich nicht.

Ergebnisse

Durch die Ausgangslage der Fragen werde ich im Rahmen der Ergebnisse Antwortmöglichkeiten kommunlieren. Dass diese nicht 100% genau ist, ist mir bewusst; aber die Richtung kommt der Realität trotzdem sehr Nahe.
Dahingehend transparent meine Rechnung:

Entwickler, Sprache und IDE

Entwickler, die geantwortet haben: 64 von 71, davon 44 im Team.
Hinzu kommen selbstständige Entwickler, wovon ich ausgehen kann, dass diese durchaus ebenfalls einem Team zugehörig sind.
Macht also 48 von 68, die im Team arbeiten, was einem Prozentsatz von ~70% ausmacht.

62 der Teilnehmer verwenden C#. Das entspricht mit über 87% einem sehr hohen Anteil, wovon in einem C#-Forum auch auszugehen war.
Erläuterung dazu im Anfangsteil.

Ebenfalls sehr hoch ist der Anteil von Antworten, die Visual Studio als primäre IDE verwenden: 66 Antworten entsprechen dabei rund 93%.

Entwicklungsbereiche

Etwas interessanter ist dann wieder, auch aus dem DevOps Gedanken, welches Gebiet denn wie weit vertreten ist:*Desktop Entwickler: 52 % (37 Stimmen)

  • Backend Entwickler: 20 % (14 Stimmen)
  • Web Entwickler: 18 % (13 Stimmen)
  • App Entwickler: 3 % (2 Stimmen)
  • Sonstige: 7 % (5 Stimmen), darunter: Full Stack (x2), Mobile CE Entwicklung, CAD PLM.

Full Stack zähle ich persönlich nicht, da ich persönlich der Ansicht bin: es gibt heute keine Full Stack Entwickler mehr.
Dies ist in der Masse der Technologien und des enorm breiten und tiefen Spektrums einfach nicht mehr möglich. Wir sind nicht mehr in den Zeiten, als mit LAMP(Linux, Apache, MySql, PHP) ein vollständiger Stack beschrieben wurde.

Das Ergebnis der Verteilung hier ist trotzdem interessant, denn der Bereich der Desktop-Entwicklung lässt sich mit DevOps viel viel einfacher realisieren, als zum Beispiel der App-Bereich.
Bei Desktop-Entwicklungen sind zum Beispiel Tests viel einfacher zu realisieren als Apps, die auf hunderten von Devices, Screens, Sprachen und Auflösungen eigentlich getestet werden müssen. Ebenso ist es bei Desktop-Anwendungen abstrakt gesagt: am Ende kommt halt eine Exe raus.
Jedoch bei Apps ist es ein wenig komplexer, da wir hier Stores oder Business Channels (Mobile Device Management Software für Firmen) dazwischen haben, die automatisiert angesteuert werden müssen.

Quellcodeverwaltung

Die Art und Weise wie ihr Quellcode verwaltet ist doch schon etwas breiter:*Order kopieren mit erschreckenden 10 Stimmen bei 14 %

  • Ebenfalls Zip-Dateien mit 4 Stimmen und 6 % eindeutig zuviel
  • VSTS mit Git in der Cloud: 2 Stimmen, 3 %
  • VSTS mit TFVC in der Cloud: 2 Stimmen, 3 %
  • TFS mit Git On Prem: 7 Stimmen, 10 %
  • TFS mit TFVC On Prem: 23 Stimmen, 32 %
  • Subversion mit 23 Stimmen bei 32 %
  • GitHub 2 Stimmen 3 %
  • GitLab 5 Stimmen 7 %
  • BitBucket 9 Stimmen 13 %
  • Perforce: niemand
  • 8 Stimmen (11 %) fallen auf Sonstige mit: SourceSafe, MKS Integrity, SourceGear, Git mit eigener Plattform

Auch die Quellcode-Verwaltung an für sich ist jetzt nicht sooo interessant; interessanter für mich war die Basisfrage: wie viele arbeiten mit einem Quellcodeverwaltungssystem und das ist den Angaben zufolge 85% recht zufriedenstellend.
Es ist zwar zufriedenstellend, aber nicht gut. Denn immerhin 14 Teilnehmer verwenden für ihre Projekte immer noch "Ordner kopieren" und "ZIP Dateien". Warum?
Beides ist vor allem für Teams überhaupt nicht praktikabel und für DevOps ein No-Go.
Bei Hobbies kann ich es noch einigermaßen verstehen; nicht aber beim beruflichen Zweck. Hier sehe ich es als absolutes Hoch-Risiko.

Dass Git trotz seiner enormen Vorteile, gerade mit GitFlow für die hier sehr verbreitete Desktop Welt, doch noch so einen geringen Teil hat; das wundert mich ein wenig und ist womöglich auf Legacy-Projekte zurück zu führen.
Was ich nicht gefragt habe: verwendet ihr TFC wirklich noch gern? Wieso (noch) kein Umstieg auf eine Git-Basis?

Build System

Beim Build-System bin ich in anbetracht der Anzahl von Entwickler im Team wirklich negativ überrascht: eine deutliche Mehrheit von fast 58% verwendet kein Buildsystem!
Das überrascht mich wirklich. Persönlich hab ich damit gerechnet - das war so die Hausnummer, die ich in den Usergroups/Konferenzen mitbekomme - dass rund 80-85% bereits ein automatisches Buildsystem verwenden. Hier scheint es doch irgendwie eine Differenz von Usergroup-Teilnehmern zu geben. Warum kann ich mir gerade nicht erklären.
Da ein Releasesystem i.d.R. immer auf einem Buildsystem aufbaut und mit dessen Artifacts(Build Outputs, zB. Exe Files) arbeitet, wundert es dann auch nicht, dass über 70% kein Releasesystem verwenden.

Das ist beides erschreckend niedrig!* Wie überwacht ihr denn dann die Qualität von euren Commits, wenn nicht über ein gemeinsames, automatisches Buildsystem?

  • Wie überwacht ihr denn dann die Qualität von euren Outputs, wenn nicht über ein Release System? Rennt ihr noch mit Zettel und Stift durch die Gegend, damit jemand ein Release unterschreibt?
  • Wie gewährt ihr die Transparenz, wer eine Software zu welchem Zeitpunkt mit welchem Inhalt freigegeben habt?
  • Wusstet ihr evtl. gar nicht, dass es sowas gibt - oder woran scheitert es? Kosten? Aufwand?

Ich würde es gerne besser nachvollziehen können.

Software Qualität ist enorm wichtig und beide Systeme - Build- und Releasemanagement - sind Grundbausteine von Software-Qualität und Transparenz.

Die verteilung der Buildsysteme sind wiefolgt:

  • Visual Studio Team Services (VSTS, Cloud): 1 Stimme (1,45 %)
  • Team Foundation Server (TFS, On Prem): 14 Stimmen (20 %)
  • Jenkins: 2 Stimmen (3 %)
  • Travis - 0 Stimmen
  • GitHub CI 1 Stimme (1,45 %)
  • Bamboo - 2 stimmen (3 %)
  • QuickBuild - 0 Stimmen
  • Nein, verwenden wir nicht: 58 % - 40 Stimmen!
  • TeamCity: 6 Stimmen
  • Sonstige: 3

Und die Release Management:

  • Visual Studio Team Services (VSTS, Cloud) - 2 Stimmen, 3 %
  • Team Foundation Server (TFS, On Prem) - 10 Stimmen, 15 %
  • Octopus Deploy - 2 Stimmen, 3 %
  • Nein, verwenden wir nicht - 50 Stimmen, 72% !!!!
  • Sonstige - 6 Stimmen (TeamCity (?), Jira/Confluence (?), Eigenentwicklung)

Solch eine Quote der Nicht-Nutzung habe ich ehrlich gesagt eher im Hobby statt im beruflichen Umfeld erwartet.

Cloud
Zum Schluss war es dann einfach noch eine persönliche Interesse: wie viele arbeiten aktuell mit der Cloud.
Warum? So einfach DevOps umzusetzen, wie in der Cloud, geht eigentlich gar nicht.
Und besonders einfach, einfach durch die Stärke von Visual Studio Team Services, das so keine andere Plattform bietet, geht es eben mit Microsoft Azure.
Azure hat hier auch den höchsten Anteil der aktiven Nutzung mit 17 Prozent und 12 Stimmen; aber - womit ich gerechnet hab - 72 Prozent (51 Stimmen) arbeiten überhaupt nicht mit der Cloud.
AWS und Google Cloud sind noch mit je 7 Prozent (5 Stimmen) vertreten wie auch Azure Stack (im eigenen Rechenzentrum) mit 3 Prozent (2 Stimmen).

Persönliches Fazit

Nochmals herzlichen Dank an (fast 😉 ) alle Teilnehmer der Umfrage!

Warum ist DevOps so wichtig?
DevOps ist nur ein Metabegriff und zugegeben eigentlich in dieser Bezeichnung noch recht neu; vielleicht 10 Jahre. Aber immerhin schon 10 Jahre! Und DevOps hat sich bei den aller meisten Bereichen der Software Entwicklung einfach bewährt.
DevOps ist dazu da, dass der Nutzer der Software einen direkten Mehrwert hat: neue Funktionen stabiler verwenden zu können.
Dabei spielt es keine Rolle ob Desktop, App oder Web: alle Bereiche bieten Nutzern einen Mehrwert. Sonst würde es diese Software nicht geben.
Der Bereich App ist hier evtl. besonders hervorzuheben, denn App-Nutzer sind sehr pingelig. Ist eine App schlecht, weil sie zB. oft abstürzt, wird sie oft direkt wieder deinstalliert und nie wieder installiert. Dazu hagelt es schlechte Bewertungen in den Stores.
Hier ist es also besonders wichtig, gute Qualität abzuliefern.

Zudem gibt es bei Firmen einen direkten Zusammenhang von Management und DevOps: je schneller neue Features bereitgestellt werden, desto eher wird man positiv von Endkunden und Chefetage wahrgenommen und desto positiver wird dies mit den Leistungen der Entwicklern verbunden.
Zeitgleich bietet eine vollständige DevOps Pipeline die Möglichkeit, dass der Entwickler sich auf seine Lieblingsaufgabe konzentrieren kann: geile Software entwickeln!
Und nicht auf nervige Bugsuche gehen, weil man die Software nicht automatisch entsprechend testet und es irgendwo beim Endkunde knallt.

Trotzdem sehe ich noch im Alltag - ich bin in verschiedenen, vor allem größeren Firmen unterwegs - dass DevOps noch nicht so wirklich angekommen ist.
Bei den größeren Firmen, die eigentlich nicht so schnell etwas adaptieren, ist DevOps aber irgendwie weiter fortgeschritten, als bei den kleinen.
Bei den kleineren Firmen hat man oft den Eindruck von "gebastel". Das soll jetzt nicht beleidigend sein; es ist eher die Feststellung, dass der Prozess von Entwicklung über Vertrieb hin zum Betrieb und Überwachung von Software eigentlich großteils sehr lückenhaft ist.
Und dies spielt durchaus eine Rolle in Sachen Software-Qualität; und eher schlechtere Software-Qualität ist durchaus mit Image, mit Benutzerzufriedenheit und natürlich auch mit Folgekosten zu verbinden.

Vielleicht mag ja jemand, der sich bei den Auswertungen angesprochen fühlt, etwas sagen; warum zum Beispiel noch kein Build- oder Releasemanagement-System eingesetzt wird.

Eine Frage habe ich vergessen zu stellen:
Wer entwickelt in der Firma und wer hat die Möglichkeit auch ausserhalb der Firma (zB. Home Office) zu arbeiten.
Dies ist besonders interessant, wenn man die Quellcode-Verwaltung dazu kombiniert, da das Branching-Modell von Git dem von TFVC bei der Verwendung von mehreren Personen/Devices recht deutlich überlegen ist.

Besten Dank und ich bin gespannt auf euer Feedback.

B
357 Beiträge seit 2010
vor 6 Jahren

Dann erzähl ich mal ein bisschen von unserer Struktur in der Firma.

Als ich 2010 hier angefangen hatte, wurde mit VS2008 und SourceSafe entwickelt. Allerdings letzterer in Version 6, sprich, Nutzer mussten eine Datei einchecken, damit ein anderer sie auschecken und bearbeiten konnte. Eincheckkommentare gab es überhaupt nicht und auch Branches etc. wurden schlichtweg nicht genutzt. Alles auf einem Haufen, unübersichtlicher ging es gar nicht. Dazu Regalweise Ordner mit Softwarefehlern, tausende Zeilen auskommentiertem Code (kann man ja vielleicht mal wieder brauchen), ebenso tausende Zeilen, die einfach mit if(FALSE) aus dem Spiel genommen wurden.

Es dauerte etwa 2 Jahre voll meiner subtilen Beschwerden, bis man überhaupt mal einen Bugtracker eingeführt hatte. Dieser wird inzwischen allerdings auch für jede eingegangene Mail, Anrufe etc. missbraucht, weshalb er quasi unbrauchbar geworden ist, wenn man nicht mit eigenen Filtern arbeitet.

Es dauerte schließlich bis Mitte 2015, bis ich in Eigeninitiative das Projekt TFS gestartet habe. Nach einem sorgfältig ausgearbeiteten Migrationsplan bekam ich grünes Licht der Geschäftsleitung und nach einem durchgearbeiteten Wochenende konnten wir mit dem TFS arbeiten. Alles auf dem lokalen Server aufgrund des sehr starken Misstrauens der Cloud gegenüber in der Firma. Ich habe lange argumentiert, aber nur Freigabe für eine OnPremise-Installation bekommen. Seis drum.

Endlich war es also möglich, gleichzeitig am gesamten Code zu arbeiten. Gleichzeitig habe ich unseren Workflow um schon lange notwendige Code-Reviews erweitert. Ebenso gab es eine schöne Einstellung, die Code-Checkin-Kommentare zur Pflicht machte. Einmal aktiviert, 2 Wochen das Gemecker der Kollegen ignorieren ("Wenn man jetzt aber mal ganz schnell was einchecken muss, will ich mir nicht erst einen Kommentar überlegen müssen" - und ähnliche Perlen) und schon funktioniert das.

Man merkt schon, in so einem konservativen Umfeld sind Änderungen nur sehr langsam - wenn überhaupt - möglich.

Massiv angekekst hat es mich schon seit meinem Einstieg, dass einige Kollegen es immer wieder geschafft haben, broken Code einzuchecken. Sei es, weil Ressourcen vergessen wurden oder sogar der Code selbst gar nicht kompiliert hatte. Mal den aktuellen Code abholen und darauf einen neuen Teil entwickeln konnte dazu führen, dass man erst mal ne Stunde damit zugebracht hatte, den Code wieder lauffähig zu bekommen.

Die Einführung des TFS und dieses Dauerproblem waren der Initiator zu sagen "So geht es nicht weiter". 1-2 weitere durchgearbeitete Wochenenden später haben wir ein Buildsystem eingeführt, das bei jedem Checkin prüft, ob das überhaupt kompiliert. Falls nicht -> Checkin abgelehnt. Eine schöne Sache. Das haben wir jetzt seit Anfang 2017 im Einsatz und sind sehr glücklich damit. Es folgten im Mai die Nightly-Builds für unser internes Testsystem. Vollautomatisch täglich aktuelle Kompilate auf dem Testsystem, großartig.

In der Umfrage habe ich das Releasesystem noch verneint, weil das erst jetzt so langsam als nächster Schritt ansteht. Diese ständige Verwirrung, wer jetzt welchem Kunden welche Programmversion übergeben kann ist ein Graus. Kurz zusammengefasst weiß die Rechte nicht, was die Linke tut. Das Releasesystem soll hier Abhilfe schaffen. Da ich derzeit aber auch privat enorm eingespannt bin, tu ich mir gerade etwas schwer, mir das Wissen anzueignen, zumal nicht jede Literatur in Form von Blogs und Büchern die entsprechend brauchbare Qualität aufweist. Ich will nicht wissen, welche Buttons in welchen Dialogen in welcher Reihenfolge geklickt werden müssen, ich will wissen, WARUM ich diesen oder jenen Schritt gehen muss. Das verschlingt Zeit und dementsprechend plane ich mit dem Releasesystem erst auf den Herbst.

Es ist eine ständige Transformation im Betrieb. Es geht langsam vorran, aber doch vorran. Es ist nur manchmal frustrierend, wenn von manchen Kollegen immer wieder kommt, dass "man das schon immer so gemacht hat". Man weiß genau, dass manches in den frühen 90ern steckengeblieben ist, will es besser machen, aber weil es halt anders ist, wird es abgelehnt. Ich habe lernen müssen, dass man in so einem Unternehmen die Leute ganz langsam an Änderungen heranführen muss und die Leute selber erlernen müssen, wie viel besser es in Neu sein kann. Dann wird es auch eher akzeptiert. Aber auch das, sehr zeit- und nervenaufwändig.

Ich kann aber nur aus eigener Erfahrung sagen: Ein Buildsystem lohnt sich quasi immer. Die Zeit um Code wieder lauffähig zu bekommen war firmenweit bei uns im Bereich von 4-5 Stunden pro Woche. Das ist der halbe Tag eines ganzen Entwicklers jede Woche! Diese Zeit ist inzwischen völlig entfallen. Man kann davon ausgehen, dass der Code im TFS IMMER kompiliert und läuft, egal, wann man ihn abholt. Super Sache. Und vom Releasesystem verspreche ich mir sogar noch größere Zeiteinsparungen, wenn nicht fast im Stundentakt im ganzen Haus geklärt werden muss, welche Version des Programms verteilt werden kann.

Auf jeden Fall, schöne Umfrageergebnisse. Oder zumindest interessante, manches ist ja doch eher unschön. 😉

Abt Themenstarter:in
16.806 Beiträge seit 2008
vor 6 Jahren

Danke für Deine Erläuterungen.
Habt ihr dann direkt mit TFS und Git gearbeitet (was ja so auch von Microsoft ausdrücklich empfohlen wird) oder noch mit TFVC?
Verwendet ihr im Falle von Checkins Pull Requests?

Was denkst Du wäre mit euch passiert, wenn ihr nicht migriert hättet?
Wäre alles beim alten geblieben oder glaubst Du, dass ihr durch die geringere Effizienz der alten Plattform Marktnachteile gehabt hättet?

Habt ihr evtl. Bewerber gehabt, die sowas geäußert haben wie "was, ihr arbeitet noch mit solch alten Tools? Ne leider kein Interesse mehr.".

Sowas hab ich im Rahmen von Usergroups nun schon mehrfach gehört, sodass Firmen einfach sehr schwierig neue Leute finden und sie dadurch quasi einen Migrationszwang haben.
Hier zwingt also auch der Arbeitsmarkt die Arbeitgeber dazu, dass auch sie technologisch ein Ökosystem bereitstellen, das den Anforderungen selbst gerecht wird.

aber weil es halt anders ist, wird es abgelehnt.

Das ist leider sehr oft so - und schadet jeder Firma in meinen Augen massiv.
So massiv, dass es in den aller meisten Fällen langfristig ein Risiko für Arbeitsplätze ist. Habe hier aber schon oft gehört "mir egal, bis dahin bin ich in Rente".
Was will man dann bei sowas noch machen....

3.003 Beiträge seit 2006
vor 6 Jahren

Kannst du bitte noch Verteilung der benutzten Build/RM-Systeme aufschlüsseln? Bin einigermaßen erschüttert, dass die so wenig verbreitet sind. Nach meiner Erfahrung ist das der Faktor, der den Teams das nötige Selbstvertrauen und die Sicherheit bietet, um auch mal Mut beim Entwickeln haben zu können.

Was die Delphi-Adepten angeht: Gott, wie süß, v.a. auch die Überzeugung, dass Delphi eine Rolle spielen würde. Ich stelle lieber jemanden ein, der zwei Jahre Rust/Haskell/Go programmiert hat, als jemanden, der 15 Jahre Delphi gemacht hat. Bei dem weiß ich wenigstens, dass er sich für Neues interessiert, anstatt ein totes Pferd zu reiten.

LaTino

"Furlow, is it always about money?"
"Is there anything else? I mean, how much sex can you have?"
"Don't know. I haven't maxed out yet."
(Furlow & Crichton, Farscape)

Abt Themenstarter:in
16.806 Beiträge seit 2008
vor 6 Jahren

Details von Build- und RM-Systemverteilung ist nachgetragen; hatte ich vergessen. Sorry.

B
357 Beiträge seit 2010
vor 6 Jahren

Wir haben TFVC im Einsatz. Git war etwas zu unterschiedlich, damit hätten wir vermutlich erst mal massive Probleme gehabt. Das kann man später noch nachholen, im Prinzip auf demselben Weg wie vom SourceSafe weg. Das alte Repository bleibt noch eine Weile parallel als Readonly bestehen, wird irgendwann wegarchiviert.

Ich glaube, auf lange Sicht wären die Nachteile, die wir am Markt bisher sowieso schon haben, enorm geworden. Wir sind ein relativ kleiner Betrieb und umso wichtiger ist dann Qualität, zu der wir uns immer weiter hin entwickeln müssen. Ohne entsprechende neue Tools, die hierbei unterstützen, wird der Gap irgendwann so groß, dass er von den Beteiligten nicht mehr überbrückt werden kann um dabei gleichzeitig wettbewerbsfähig zu bleiben. Die Konkurrenz schläft nicht, man muss am Ball bleiben.

Bewerbertechnisch hatten wir noch keine Probleme mit den Toolsets. Klar, man hört mal hier und da was, aber es ergeht dann meist die Aufforderung, dass sich der Brummelnde auch gerne damit beschäftigen kann, dieses oder jenes zu modernisieren. Aufgrund der Betriebsgröße ist das tatsächlich ein eher kleines Problem, was zu modernisieren. Aber es muss halt sorgfältig und langsam im Alltag eingearbeitet werden, sonst gehen viele wieder zurück zu "wie es immer war".

O
79 Beiträge seit 2011
vor 6 Jahren

Ich habe lange überlegt, ob ich mich hier beteiligen sollte, oder nicht. Die Feindseligkeit gegenüber anders arbeitenden ist schon bedrückend. Aber lassen wir das, führt zu nix.

Ich arbeite seit kurzem in einem Unternehmen, das man getrost als "von vorgestern" bezeichnen könnte. Der Compiler ist von 1999, der Code - vorsichtig ausgedrückt - unstrukturiert, weitgehend undokumentiert und das (immerhin) verwendete SourceSafe mit seinem Ein-/Auscheck-Zwang ist immer wieder nervtötend.

Ich würde gern losziehen und hier als erstes ein nach heutigen Maßstäben vernünftiges VCS einführen. Git wäre da meine erste Wahl, doch wenn man so gar keine Ahnung davon hat, ist man auch nach mehrstündiger Recherche nicht ernsthaft schlauer. Ich weiß das aus Erfahrung, denn ich habe schon dreimal versucht, mich da einzufuchsen. Das Problem dabei ist: Es gibt massenhaft Tutorials (auch hier), die mir zeigen, wie ich was wo installieren muß und wie ich ein Repo anlege.

Doch wenn das Repo auf einem Server liegt, damit auch mein Kollege damit arbeitet ? Kein einziges der Tutorials kam bis zu diesem Punkt und ein lokales Repo ist nur was für Einzelkämpfer, nicht für Team-Development.

Zu DevOps sieht das nicht wirklich besser aus, doch zähle ich hier auf die Community, die offenbar was davon versteht. Mir ist da z.B. völlig schleierhaft, welchen Vorteil ich aus einem über Nacht erzeugten Kompilat haben soll. Ist es tatsächlich inzwischen üblich, das man am Code Änderungen vornimmt und diese einfach nur eincheckt, ohne das ganze wenigstens einmal durch den Compiler zu schubsen ? Wenn ja, bleibe ich Oldschool...

Auch sehe ich keinen ernsthaften Nutzen aus einem Release-System. Unser Kundenkreis ist überschaubar (vielleicht ein dutzend Kunden), wir entwickeln ausschließlich Desktop-Anwendungen, der Anteil an Webentwicklung ist Null, der Anteil an Mobile Apps ist Null. Es existiert auch gar kein Bedarf in unserem Bereich für so etwas. Wozu also Releases, ergo wozu ein Release-System ?

Aufgrund des überschaubaren Kundenkreises gibt es auch gar keine Testsysteme hier. Aber womöglich ist damit etwas ganz anderes gemeint, als ich im Moment denke.

Gibt es ein paar wirklich brauchbare Artikel, die einem den Nutzen eines DevOps-Systems aufzeigen kann ? Welchen Aufwand müßte ich betreiben, um auch eine "exotische" Sprache wie Delphi oder Assembler mit in den Prozess zu integrieren ? Macht sowas überhaupt Sinn, wenn man mit Web oder Mobile nichts, aber auch rein gar nichts am Hut hat ?

Fragen über Fragen.

Abt Themenstarter:in
16.806 Beiträge seit 2008
vor 6 Jahren

Das soll nun kein Hilfe-Thread sein sondern eher ein Feedback, wieso man noch so arbeitet; aber das kann ich bei Dir zwischen den Zeilen einigermaßen erkennen: ihr braucht eigentlich jemanden, der euch das zeigt, nicht?

Kein einziges der Tutorials kam bis zu diesem Punkt und ein lokales Repo ist nur was für Einzelkämpfer, nicht für Team-Development.

Ja, die Einstiegshürde für Git ist vergleichsweise hoch. Ich bringe Neulingen /Studenten Git mit Hilfe von SourceTree bei. Deutlich einfacher als mit der Kommandozeile, wer es einfach nicht gewohnt ist.

Git-Server intern (TFS, GitLab OnPrem..) wie auch als SaaS (VSTS, GitHub, BitBucket, GitLab...) gibt es aber Haufenweise.
Vermutlich fehlt hier einfach nur die Beratung (alternativ interne Zeit). Richtig?

Mir ist da z.B. völlig schleierhaft, welchen Vorteil ich aus einem über Nacht erzeugten Kompilat haben soll.

DevOps ist keine Bezeichnung für einen Nightly Build. DevOps ist das Zusammenspielen vieler verschiedener Einzelschritte. (siehe zB dieses Bild: https://www.suse.com/assets/img/devops-process.png)

Ist es tatsächlich inzwischen üblich, das man am Code Änderungen vornimmt und diese einfach nur eincheckt, ohne das ganze wenigstens einmal durch den Compiler zu schubsen ?

Aber zur Frage:
Normalerweise erfolgt beim Checkin sofort ein Build, der prüft, ob der Code sauber kompiliert (fail fast and fail often). Dabei werden auch Unit Tests durchlaufen.
Nightly Builds nimmt man nun zum einen für die Dauerhafte Überprüfbarkeit des Codes, zB. weil sich externe Pakete aktualisiert haben (und man nicht mit fixen Versions-Dependencies arbeitet sondern zB. auf Minor-Basis).
Zudem verwendet man Nightly Builds für zeitaufwändige Tests, zB UI Tests.

Ein einfacher Build sollte nicht länger als 15 Minuten laufen.
Ein Nightly Build mit entsprechenden UI Tests läuft auch mal 4 Stunden Plus.

Auch sehe ich keinen ernsthaften Nutzen aus einem Release-System. (........) Wozu also Releases, ergo wozu ein Release-System ?

Ein Build erzeugt ein Artifakt, zB. ein MSI Paket oder eine Exe.

Ein Release ist nun dafür da, dieses Artifakt den verschiedenen Stages verfügbar zu machen - und zwar kontrolliert.
Einfacher Stageaufbau:

  • Stage Dev: hier landet das Artifakt nach dem Build automatisch. Dies kann der Entwickler sofort ausprobieren und selbst testen. Auf die Dev Stage haben nur Entwickler zugriff.
  • Stage QA: Quasi das Testsystem. Dies erfolgt nicht automatisch, sondern der Entwickler drückt auf "Manuell auf QA verschieben". Der Build wird hierfür nicht neu gestartet, sondern das Artifakt "weiter gereicht". Hier erfolgen letzte, manuelle Tests. Auf QA können auch Beta-User / Management gehen.
  • Stage Prod: Die Freigabe für den Live-Gang. Dies muss derjenige übernehmen, der für diese Freigabe auch haftet.
    Das sind oft Chefs, die in älteren Prozessen irgendeinen Wisch für die Freigabe unterschreiben. Bei größeren Firmen auch gerne mehrere Personen. Bei Dienstleistern ist das oft der Kunden, der das Produkt selbst nachher vertreibt oder hostet, denn er haftet.
    Bei Release Management Systemen erfolgt dies durch definierte Approvals.

Als Dienstleister oder Produkthersteller gibt es eben diesen wichtigen Punkt: Haftung.
Du haftest für die Software, die Du Deinen Kunden gibst - egal auf welchem Wege. Aber wenn was ist, dann musst Du nachweisen, was Du dem Kunde geschickt hast, welcher Code zu welchem Zeitpunkt in diesem Release war.
Ohne Release System hast Du eigentlich kaum eine Möglichkeit nachzuweisen, welche Software Du zu welchem Zeitpunkt mit welchem Inhalt mit welchen Änderungen und welcher Freigabe ausgeliefert hast.

Dass ihr keine Testsysteme betreibt: wie stellt ihr dann Software Qualität sicher?
Oder ist das eher Glückssache?

Gibt es ein paar wirklich brauchbare Artikel, die einem den Nutzen eines DevOps-Systems aufzeigen kann ?

DevOps ist kein System, sondern ein Entwicklungsprozess 😉

Welchen Aufwand müßte ich betreiben, um auch eine "exotische" Sprache wie Delphi oder Assembler mit in den Prozess zu integrieren ?

Wenn VSTS einen entsprechenden Build-Task hat dann geht das in Minuten.
Ansonsten musst Du eine eigene Maschine (Windows, Linux, was Du willst/brauchst) aufsetzen und einen Agent registrieren.
Auf dieser Maschine installierst Du alles, was Du für das kompilieren benötigst und zack: Du hast Dein VSTS Build Server.

Mit einer in Azure gehosteten Maschine setzt Du in unter 10 Minuten einen Buildserver auf, der über einen Agent mit VSTS gekoppelt ist.
Echt kein Hexenwerk.

Macht sowas überhaupt Sinn, wenn man mit Web oder Mobile nichts, aber auch rein gar nichts am Hut hat ?

Ja, absolut!
zB. mit TFS oder VSTS kannst Du jede Sprache auf jeder Plattform unter den DevOps Hut bekommen. Jede. Ohne Ausnahme.

Für weitere Fragen können wir dann spezifisch gerne ein eigenes Thema eröffnen.

P
1.090 Beiträge seit 2011
vor 6 Jahren

20% ohne Quellcode Verwaltung (QV) klingt jetzt erst mal viel.

Aber ich denke das 100% der 70%, die im Team arbeiten eine QV benutzen (vielleicht kann Abt, das anhand der Umfrage bestätigen). Bei den anderen 30% denke ich ist die Frage wie sie sich zusammen setzen. Ich kann mir hier gut Vorstelle, das da Schüler, Studenten usw. dabei sind, die gerade erst Programmieren lernen. Die kämpfen meist erst mal mit den Grundlagen, da steht eine QV nicht so im Vordergrund. Auch wenn sie wirklich sinnvoll ist.

Ich hab einen Bekannten, der Informatik Studiert und ich hab ihn von Anfang an geraten für seine Projekte eine QV zu verwenden. Hat er nicht gemacht. Letztes Jahr kam dann am Sonntag der Anruf, das er sein Projekt zerschossen hatte, nichts mehr funktionierte und er Montag die Abgabe hat. Mit einer QV wäre das kein Problem gewesen, da hätte man sich einfach die Unterschiede anschauen können und es wäre wohl auch öfter Eingecheckt worden. So war die Kopie Sicherung einen Monat alt und ich durfte ihn helfen das Projekt (in Java, hatte ich länger nichts mehr zu tun mit) wieder zum laufen zu bringen.
Ich kann nur jedem Raten einen QV zu benutzen und regelmäßig den Quellcode ein zu schecken (Und das lieber einmal zu oft als zu wenig.)

Bei den größeren Firmen, die eigentlich nicht so schnell etwas adaptieren, ist DevOps aber irgendwie weiter fortgeschritten, als bei den kleinen.
Bei den kleineren Firmen hat man oft den Eindruck von "gebastel". Das soll jetzt nicht beleidigend sein; es ist eher die Feststellung, dass der Prozess von Entwicklung über Vertrieb hin zum Betrieb und Überwachung von Software eigentlich großteils sehr lückenhaft ist.

Hier gibt es sicher unterschiedliche Gründe für.
Grundlegend haben aber größere Firmen einfach mehr Entwickler und wenn ich 50 Entwickler habe und sich da 2 um die Einführung von DevOps kümmern sind, das 4% Arbeitsleistung die Fehlen. Hab ich 5 Entwickler und einer kümmert sich um die Einführung, fehlen 20% Arbeitsleistung.
Bei größeren Firmen wird es dann wohl eher sein, das wenn sie sich für DevOps Entscheiden, ein paar Leute dafür Abstellen können oder sich einen Externen dazu holen und es dann komplett Umsetzen.
In kleineren Firmen, sieht es ja dann eher so aus das sich da ein Entwickler neben seiner Normalen Arbeit noch mal neben bei darum kümmern soll und sich dabei noch in die Materie einlesen muss.
In dem Rahmen finde ich es nicht schlimm wenn es bei kleinen Firmen eher "gebastelt" aussieht.
Solange sie sich bemühen es gut umzusetzen.

Was ich persönlich am meisten Stört, ist einfach die Grundlegende Diskussion ob DevOps sinnvoll sind.
(und das man wirklich teilweise mit Leuten aus dem Management (ist bei mir schon ein paar Jahre her) drüber diskutieren muss.)
Ja DevOps sind einfach sinnvoll, weil damit einfach Stabilere Software ausgeliefert wird. Was die Kunden Zufriedenheit steigert und die Kosten für die Wartung senkt.

Ich denke an dem Punkt ist nicht die Frage ob DevOps umgesetzt werden sollten, sondern wie man es im Detail am besten macht und welcher Aufwand damit verbunden ist.

Um es mal für uns zu Beschreiben.
Wir haben aktuell einen CI Build, der ca. 5min braucht. Dabei werden alle Unit Tests durchgeführt.
Für den Release Build, brauchen wir ca. 40min dabei werden aber auch Integration Tests und Coded UI Tests durchgeführt, damit diese Funktionieren werden die Datenbanken neu erzeugt und mit Testdaten gefüllt.
Meines Erachtens bringen die Unit Test, mit relative geringen Aufwand am meisten.
Integrations- und Codes UI Tests sind zwar nett zu haben, aber im Verhältnis, sehr Aufwändig.

Um an den Punkt vielleicht eine Frage zu Stellen.
Welche Sachen aus dem Bereich DevOps haltet ihr für kleine Betrieb (ca. 5 Leute) für Sinnvoll und welche würdet ihr gerne in größeren Betrieben sehen?

Sollte man mal gelesen haben:

Clean Code Developer
Entwurfsmuster
Anti-Pattern

3.003 Beiträge seit 2006
vor 6 Jahren

Ich habe lange überlegt, ob ich mich hier beteiligen sollte, oder nicht. Die Feindseligkeit gegenüber anders arbeitenden ist schon bedrückend. Aber lassen wir das, führt zu nix.

Du missverstehst. Die Feindseligkeiten sind nicht den Leuten gegenüber, die so arbeiten, sondern den Leuten gegenüber, denen ihre Entwickler und ihr eigenes Produkt so egal sind, dass sie nicht einmal vernünftige Arbeitsgrundlagen schaffen. Mein erster Arbeitsplatz als angestellter Entwickler entsprach ziemlich genau deiner Beschreibung: kleines Unternehmen (~5 Entwickler) unstrukturierter Code, VSS als Quellcodeverwaltung (immerhin). Allerdings war das 1999, und das Konzept Quellcodeverwaltung war mir, der ich davor lange selbstständig war, völlig unbekannt. Aus heutiger Sicht würde ich diese Umstände als Bestrafung ansehen. Die Werkzeuge haben sich weiterentwickelt, die Methoden haben sich weiterentwickelt, der Begriff Softwarequalität ist ein anderer. Softwareentwicklung ist wesentlich effizienter geworden, und DevOps ist ein weiterer Baustein im Werkzeugkasten, um die Effizienz zu erhöhen. Ein Lebewesen, das nicht mehr zuckt, ist genauso tot wie das Unternehmen, das sich nicht mehr weiter entwickelt[1]. Sich im Rahmen der Unternehmenstrategie mit Werkzeugen zu befassen, die die Arbeitsleistung und -qualität der Entwickler erhöhen, sollte selbstverständlich sein. Nebenbei macht man den Entwicklern das Leben leichter, und auch das ist nach meiner Meinung eine Aufgabe der Unternehmensführung, wenn sie gute Entwickler halten und noch bessere anlocken wollen.

Mir ist da z.B. völlig schleierhaft, welchen Vorteil ich aus einem über Nacht erzeugten Kompilat haben soll. Ist es tatsächlich inzwischen üblich, das man am Code Änderungen vornimmt und diese einfach nur eincheckt, ohne das ganze wenigstens einmal durch den Compiler zu schubsen ? Wenn ja, bleibe ich Oldschool...

Habt ihr nur ein Projekt? Bestehen keine Abhängigkeiten zwischen euren Projekten? Könnte ihr alle eure Produkte lokal innerhalb von 2 Minuten kompilieren? Wie lange laufen eure Unit Tests? Auf welchen Softwareständen laufen Regressionstests?

Selbst meine Hobbyprojekte zu Hause sind über die Jahre so miteinander verflochten (gemeinsame Bibliotheken) und so komplex, dass ich zugegeben den Überblick verloren habe, welche Änderung in welchen Projekten Auswirkungen haben könnte. Und ich baue sicher nicht von Hand alle Projekte jedesmal durch, das kann auch ein trainierter Affe oder gleich ein Buildsystem (das nebenbei nicht nur die Projekte erstellt, sondern auch gleich die Unit Tests laufen lässt). Und da reden wir von maximal 5 Stunden die Woche, die ich dran sitze. Mir kann keiner erzählen, dass das selbst bei kleinen und kleinsten Unternehmen besser ist.

Bei größeren Unternehmen sind natürlich die Dimensionen ganz anders. Wenn mein Team was eincheckt, sind potenziell immer rund 100 andere Entwickler von den Änderungen betroffen. Man kann zwar im eigenen Projekt sicherstellen, dass es kompiliert, aber nicht in abhängigen Projekten (wenn man nicht mal weiss, welche Projekte davon abhängen). Um ganz sicher zu gehen, müsste man also alle Projektmappen zumindest der wichtigsten Produkte durchkompilieren. Das dauert auf dem Buildserver ~30 Minuten, bei mir lokal gern mal 45 Minuten. Ich kann also entweder meine Entwickler pro Checkin 45 Minuten Däumchen drehen lassen, oder ich nutze ein Buildsystem. Das baut nebenbei noch alle Branches zB für einen Release oder ein spezielles Projekt mit.

Der Sinn daran, zu jeder Zeit ein funktionierendes Produkt zu haben, das auf einem beinah aktuellen Stand der Entwicklung ist, leuchtet dir nicht ein? Sagen wir, es ist bei euch wie bei uns damals: die Regressionstests bestehen aus dem Chef, der in der fertigen Software wild herumklickt und versucht, die neu eingebauten Features irgendwie zum Absturz zu bringen. (wir haben das gefürchtet. Irgendwie hat er immer einen Fehler gefunden.) Dann stellt sich die Frage: auf welchem Softwarestand probiert er das eigentlich? Findet er gerade Fehler, die eigentlich schon behoben sind?
Unter anderem dafür ist eine Software, von der immer ein funktionierendes Setup auf einem definierten Softwarestand existiert, unbezahlbar. Mal abgesehen davon, dass der Kunde neue Funktionen viel schneller erhält, weil das Zusammenstellen eines Setups kein eher seltener Vorgang ist, den ein Senior-Entwickler mit seinen Erfahrungen von Hand begleitet, sondern weil eine Setuperstellung ein alltäglicher Vorgang ist. Nimm dir den letzten Build, lass ihn durch die QS laufen, wenn du sowas hast, und raus damit an den Kunden. Bei kleinen Systemen hat man zwischen dem Checkin und dem fertigen Setup nicht mal eine Stunde. Bei großen fällt immer noch jeden Tag ein Setup aus dem Server (wohlgemerkt, da sind schon alle Unit Tests gelaufen).

Und das hat auch absolut gar nichts mit mobile apps oder Webentwicklung zu tun. Unser Hauptprodukt ist - neben Infrastruktursoftware - eine monolithische Desktop-Anwendung, sehr altmodisch vom Look&Feel, für einen sehr altmodischen Kundenkreis. Ich würde mich mit Händen und Füßen wehren, wenn man für diese Anwendung die Buildserver abschalten würde.

Wozu also Releases, ergo wozu ein Release-System ?

Äh, was? Wenn ihr euren Kunden keine Updates/Patches/Hotfixes/neue Versionen zur Verfügung stellt, dann gestatte die Frage: was macht ihr eigentlich, wenn niemand je ein Produkt von euch bekommt?

Ja, die Umsetzung von modernen Softwareentwicklungs-Prozessen (DevOps) ist eine Investition. Kostet Zeit, Geld, Ressourcen. Gar keine Frage. Aber es lohnt sich, und zwar nach meiner Erfahrung immer.

Aber - gute Nachricht - man muss nicht alles auf einmal umsetzen. Man kann klein anfangen und immer weiter dazu bauen. Das geht los mit einer vernünftigen Quellcodeverwaltung (da zähle ich VSS nicht mehr dazu), geht dann weiter mit einem rudimentären Buildsystem. Hat man das, kann man die Testdurchdringung deutlich erhöhen - guter Zeitpunkt, über TDD nachzudenken. Soweit mag es für kleine Unternehmen schon reichen, die Investition ist überschaubar[2] - aber man muss, gerade was die Testabdeckung angeht, möglicherweise seine Entwickler weiterbilden.

Wenn man das selbst trotzdem nicht stemmen kann: es gibt Dienstleister, die einem dabei helfen. Ja, klar kostet das was, wie gesagt: es ist eine Investition in die Zukunft.

Lies bitte einmal diesen Artikel aus dem Jahre 2000: das war quasi state-of-the-art zu dieser Zeit und ist weitgehend immer noch gültig. Und der Autor begründet das auch viel besser, als ich das könnte (Passend dazu diesen 11 Jahre alten Thread.)

LaTino

[1] in irgendwelchen Marktnischen kann man trotzdem noch jahrelang existieren, schon klar. Aber ein Unternehmen, egal wie groß oder klein, das sich nicht permanent zu verbessern versucht, ist auf lange Sicht Geschichte.
[2] Das ist das, was ich privat bei mir zu Hause gemacht habe. Zum einen, weil es nötig war, zum anderen, weil ich was darüber lernen wollte.

"Furlow, is it always about money?"
"Is there anything else? I mean, how much sex can you have?"
"Don't know. I haven't maxed out yet."
(Furlow & Crichton, Farscape)

Abt Themenstarter:in
16.806 Beiträge seit 2008
vor 6 Jahren

Aber ich denke das 100% der 70%, die im Team arbeiten eine QV benutzen (vielleicht kann Abt, das anhand der Umfrage bestätigen)

Das kann ich nicht sehen. Ich habe die freie Version von SurveyMonkey; ich sehe nur das, was hier auch reingeschrieben wurde.

Ich kann mir hier gut Vorstelle, das da Schüler, Studenten usw. dabei sind, die gerade erst Programmieren lernen.

Auch hier gilt: Team ist Team. Ich unterscheide nicht ob 50 Jahre Erfahrung oder abgehender Student. Beide sind im Team gleichberechtigt.

Für den Release Build, brauchen wir ca. 40min dabei werden aber auch Integration Tests und Coded UI Tests durchgeführt, damit diese Funktionieren werden die Datenbanken neu erzeugt und mit Testdaten gefüllt.

Was ist ein "Release Build"? Das gibts in der Sprache von DevOps eigentlich nicht.
Ein Release darf niemals etwas "builden" im Sinne von Kompilieren, sondern arbeitet mit dem Artifakt aus einem Build.

Meines Erachtens bringen die Unit Test, mit relative geringen Aufwand am meisten.
Integrations- und Codes UI Tests sind zwar nett zu haben, aber im Verhältnis, sehr Aufwändig.

Sehe ich auch so, bei 95% der Software.

Welche Sachen aus dem Bereich DevOps haltet ihr für kleine Betrieb (ca. 5 Leute) für Sinnvoll und welche würdet ihr gerne in größeren Betrieben sehen?

Der DevOps Process kann in zwei Bereiche unterteilt werden:* Plan- Code - Build - Test: das macht meistens der Entwickler

  • Release - Deploy - Operate - Monitor: macht oft eher eine IT-nahe Person

Beide Bereiche sind aber enorm wichtig:
Der erste Teil ist für die Qualität der Software unabdingbar, der zweite Teil für einen ordentlichen, reibungslosen Betrieb.

Viele denken nach dem "Build" ist man fein aus der Verantwortung raus: und genau so entsteht meist scheiss Software.
Auch das Release und der Operate-Teil muss der Entwickler kennen, um eine gute Software zu schreiben. Und auf Aktionen durch das Monitoring reagieren.
Monitoring kann hier aber auch sehr einfach nur ein Bucktracking sein, das dann wieder ins Planning führt.

@LaTino: guter Text!

1.040 Beiträge seit 2007
vor 6 Jahren

Ist es tatsächlich inzwischen üblich, das man am Code Änderungen vornimmt und diese einfach nur eincheckt, ohne das ganze wenigstens einmal durch den Compiler zu schubsen ?

Nur ganz kurz dazu eine Anmerkung bzw. ein Beispiel:
Du legst eine neue Klasse bzw. Datei an und vergisst diese Datei mit einzuchecken (aus welchen Gründen auch immer). Dann kannst du zwar lokal bauen (bei dir ist die Datei ja da), aber dein Kollege 3 Büros weiter nicht. 😉

D
985 Beiträge seit 2014
vor 6 Jahren

... und darüberhinaus:

Ein Code der kompiliert ist nur von der Syntax her richtig.

Wenn die UnitTests durchlaufen, dann ist der auch logisch richtig (wenigstens das, auf was man dort getestet hat).

Wenn die IntegrationTests/UITests durchlaufen, dann hat man wohl auch alles richtig verdrahtet (wenigstens das, auf was man dort getestet hat).

3.003 Beiträge seit 2006
vor 6 Jahren

...und wenn die Regressionstests durchlaufen, hat man darüber hinaus keine bereits vorhandenen Funktionen in ihrer Arbeitsweise ungewollt verändert. Die ganze Testerei NACH den Unit Tests darf je nach Komplexität auch ein paar Tage in Anspruch nehmen oder kann weggelassen werden.
Das ist eine Entscheidung, die im QM festgehalten werden muss.

"Furlow, is it always about money?"
"Is there anything else? I mean, how much sex can you have?"
"Don't know. I haven't maxed out yet."
(Furlow & Crichton, Farscape)

D
985 Beiträge seit 2014
vor 6 Jahren

Mal eine ganz doofe Frage?

IMHO sieht man den grundsätzlichen Sinn und Mehrwert hinter dem ganzen DevOps nur dann, wenn man auch (zumindest) UnitTests hat, bzw. hat man UnitTests, dann wächst auch die Begehrlichkeit gegen diese beim Einchecken automatisch prüfen zu lassen. Ich brauche also ein Build-System. Wenn ich das dann habe, dann kann man ja auch noch Nightly-Builds mit weitergehenden Tests laufen lassen. Und dann ...

Es ist also ein sich selbst befruchtendes System, was aber an der Basis anfängt.

Wenn der Source aber nicht dokumentiert ist, kann man mMn eigentlich keine UnitTests schreiben, bzw. sieht nur das Offensichtliche und denkt sich, wieso soll ich dafür jetzt einen UnitTest schreiben, hab ich doch so programmiert.

Ich sehe die UnitTests als Bestätigung/Prüfung an, dass z.B. die Methode sich genau so verhält, wie ich in der Dokumentation derselbigen beschrieben habe. Wenn ich das aber nicht beschreibe, was und worauf soll ich dann testen?

Ist das der eigentliche Grund für die Ablehnung?

Abt Themenstarter:in
16.806 Beiträge seit 2008
vor 6 Jahren

Wenn der Source aber nicht dokumentiert ist, kann man mMn eigentlich keine UnitTests schreiben, bzw. sieht nur das Offensichtliche und denkt sich, wieso soll ich dafür jetzt einen UnitTest schreiben, hab ich doch so programmiert.

Nein. Quellcode-Dokumentation ist wichtig, aber man sollte es nicht übertreiben.
Wenn man sich an ordentliche Namen hält "GetUserById" dann muss ich nicht kommentieren "hole User anhand der ID".

Ich finde es persönlich hier wichtiger nicht mit "var" zu arbeiten statt doppelt zu kommentieren.
Aber das ist ein anderes Thema.

Unit Tests werden glaube ich oft nicht gemacht, weil sich Entwickler überschätzen - oder sie einfach grotten faul sind.
Sie sind aber nicht zwingend für eine DevOps-Pipeline notwendig (ich brauch sie schließlich nicht für das Builden, für das Release....), aber sie sichern den Qualitätsprozess enorm.
DevOps ist ja vor allem das automatisieren, um effizienter zu sein und sich auf das Eigentliche konzentrieren zu können.

D
985 Beiträge seit 2014
vor 6 Jahren

Nein. Quellcode-Dokumentation ist wichtig, aber man sollte es nicht übertreiben.
Wenn man sich an ordentliche Namen hält "GetUserById" dann muss ich nicht kommentieren "hole User anhand der ID".

Das sehe ich genauso, für die grundsätzliche Beschreibung ist der Methodenname ausreichend.


class UserService
{
    public User GetUserById( string id )
    { ... }
}

Hier sollte jeder wissen, was er erwarten kann, wenn ein gültiger Wert für id übergeben wird.

Und wenn der Wert ungültig ist? Z.B. null oder es gibt zu der id keinen User? Was passiert dann? Gibt es eine Exception oder wird null zurückgeliefert?

Das kann ich nicht aus dem Methodennamen ableiten und genau das gehört in die Beschreibung und genau dafür schreibt man dann UnitTests.

Abt Themenstarter:in
16.806 Beiträge seit 2008
vor 6 Jahren

Und wenn der Wert ungültig ist? Z.B. null oder es gibt zu der id keinen User? Was passiert dann? Gibt es eine Exception oder wird null zurückgeliefert?

Hier hilft Dir die Naming Guides von Microsoft.

Get-Methoden liefern null, wenn etwas nicht gefunden wird.
Try-Methoden liefern false, wenn etwas nicht gefunden wird und liefern Resultate via out.

Exceptions sind keine Hilfsmittel zur Business-Logik.
Eine Exception UserNotFoundException würde geworfen werden, wenn Du AddOrder() ausführst, das eine Relation zu einem User haben soll, der nicht existiert.

Diese Basics sollte sind sowieso nicht im Code in-line dokumentierbar.
Sie gehören in das Summary einer Methode unter <exception> und <remarks> - dafür sind sie da.

Aber ja, zur Überprüfung dieser Logik verwendet man Unit Tests.

P
1.090 Beiträge seit 2011
vor 6 Jahren

Ich kann mir hier gut Vorstelle, das da Schüler, Studenten usw. dabei sind, die gerade erst Programmieren lernen.
Auch hier gilt: Team ist Team. Ich unterscheide nicht ob 50 Jahre Erfahrung oder abgehender Student. Beide sind im Team gleichberechtigt.
Mir ging es hier auch eher darum das jemand der grade Programmieren lernt, nicht um bedingt eine Quellcodeverwaltung verwendet, was vielleicht die 20% ohne QV erklären könnte.

Was ist ein "Release Build"? Das gibts in der Sprache von DevOps eigentlich nicht.
Ein Release darf niemals etwas "builden" im Sinne von Kompilieren, sondern arbeitet mit dem Artifakt aus einem Build.

Wir haben grob 3 Branchen Dev, Main und Release. Mit Release Build ist der Nightly Build der Release Branche gemeint.

Wenn der Source aber nicht dokumentiert ist, kann man mMn eigentlich keine UnitTests schreiben, bzw. sieht nur das Offensichtliche und denkt sich, wieso soll ich dafür jetzt einen UnitTest schreiben, hab ich doch so programmiert.

Man kann auch für unkommentierten Lagacy Code Unit Test schreiben. Und sollte es auch bevor man zum Refactoring ansetzt. Unit Test sind ja auch dazu da das Verhalten im Code zu Fixern.

Unit Tests werden glaube ich oft nicht gemacht, weil sich Entwickler überschätzen - oder sie einfach grotten faul sind.

Ich hab die Erfahrung gemacht, das grade die Entwickler die Behaupten keine Fehler zu machen, die meisten Fehler machen.

Sollte man mal gelesen haben:

Clean Code Developer
Entwurfsmuster
Anti-Pattern

D
985 Beiträge seit 2014
vor 6 Jahren

Ich glaube da hat man mich missverstanden.

UnitTests schreibe ich mindestens für das, was ich per XML-Dokumentation an die Methode geschrieben habe.

Und die Get-Methode soll null zurückliefern, wenn etwas nicht gefunden wird.
Der entsprechende Test dazu stellt sicher, dass das auch so ist.

Und wenn das Argument id null ist oder gar keine Id darstellen kann, dann gibt es eine ArgumentNullException bzw. ArgumentException. Auch das dokumentiert man (logisch) im <exception> Abschnitt und schreibt dazu auch UnitTests.

Die Dokumentation im Code-Abschnitt einer Methode selber ist in meinen Augen nicht relevant für den UnitTest.

Abt Themenstarter:in
16.806 Beiträge seit 2008
vor 6 Jahren

Wir haben grob 3 Branchen Dev, Main und Release. Mit Release Build ist der Nightly Build der Release Branche gemeint.

Hat das einen Grund, wieso ihr auf einen Release Branch (ihr verwendet GitFlow?) Nightly Builds macht?
Was macht ihr dann mit den Nightly Release Builds?

PS: Fehler machen ist nicht schlimm.
Daraus nicht zu lernen, ist schlimm.

P
1.090 Beiträge seit 2011
vor 6 Jahren

Beim Build wird das Test System für die QS neu Aufgesetzt inklusive Datenbanken, Testdaten usw.
Damit hat die QS immer einen genau definierten Anfangszustand und auf dem System werden auch Inhouse Schulungen durchgeführt.

Wir verwenden TFVC mit einem GitFlow ähnlichen Branching Model.

Sollte man mal gelesen haben:

Clean Code Developer
Entwurfsmuster
Anti-Pattern

Abt Themenstarter:in
16.806 Beiträge seit 2008
vor 6 Jahren

Beim Build wird das Test System für die QS neu Aufgesetzt inklusive Datenbanken, Testdaten usw.

Das wäre aber Aufgabe des Releasemanagements und nicht des Buildsystems.
VSTS: What is release management?

Das Release würde hier im Gegensatz zur Dev Stage für die QA Stage eine erweiterte Konfiguration für die Testdaten haben.
Neu builden ist nicht DevOps-konform.

121 Beiträge seit 2016
vor 6 Jahren

Neu builden ist nicht DevOps-konform.

Macht ja nix.

Abt Themenstarter:in
16.806 Beiträge seit 2008
vor 6 Jahren

Ähm, wie bitte? 🤔
Natürlich macht das was! Du hast dann zwei unterschiedliche Artifakte; im dümmsten Fall, falls der Kompiler mal nicht richtig will, ein Artifakt das funktioniert und eines, das nicht funktioniert. Oder gerade in der JavaScript und NPM Welt, bei der viele ohne Lockdatei und damit mit unbekannten Versionreferenzen arbeiten, kommt das gar nicht so selten vor, wie man denkt; eher täglich.
Das widerspricht der kompletten Pipeline-Welt!
Tools wie VSTS Release Management lassen sowas auch gar nicht zu (außer Du hast mehrere Release Konfigurationen, was natürlich quatsch ist).

Die Aussage "macht ja nix" ist genau das, was man mit DevOps vermeiden will: potentielle Fehlerquellen automatisch ausmerzen.
Wenn wir so ("macht ja nix") an die Sache gehen, dann wird die Diskussion sinnfrei. Dann hast Du DevOps "Release" einfach nicht verstanden. ⚠

121 Beiträge seit 2016
vor 6 Jahren

Wenn wir so ("macht ja nix") an die Sache gehen, dann wird die Diskussion sinnfrei. Dann hast Du DevOps "Release" einfach nicht verstanden. ⚠

Stimmt, habe ich nicht 😉

Abt Themenstarter:in
16.806 Beiträge seit 2008
vor 6 Jahren

Dann danke ich herzlichst für Deinen Beitrag.

Wenn jemand etwas nicht verstanden hat; nicht schlimm. Gerne nachfragen. Dafür ist das Forum da.
Aber bitte nicht irgendeinen Stuss reinquacken.

3.003 Beiträge seit 2006
vor 6 Jahren

Und wenn das Argument id null ist oder gar keine Id darstellen kann, dann gibt es eine ArgumentNullException bzw. ArgumentException. Auch das dokumentiert man (logisch) im <exception> Abschnitt und schreibt dazu auch UnitTests.

Eigentlich ist das genau anders herum, denn der Test existiert vor der Methode. Die Testcases definieren das Verhalten der Methode, und die Dokumentation hält das so fest, dass die Information auch außerhalb des Codes verfügbar ist/sein könnte, wenn man wollte.

LaTino

"Furlow, is it always about money?"
"Is there anything else? I mean, how much sex can you have?"
"Don't know. I haven't maxed out yet."
(Furlow & Crichton, Farscape)

3.170 Beiträge seit 2006
vor 6 Jahren

Eigentlich ist das genau anders herum, denn der Test existiert vor der Methode. Wenn man Test Driven entwickelt, ja. Sonst nicht.
Für mich persönlich ist TDD nun nicht gerade ein heiliger Gral. Daher würde ich dieser Aussage nicht die Richtigkeit, aber doch die Allgemeingültigkeit absprechen.

Gruß, MarsStein

Non quia difficilia sunt, non audemus, sed quia non audemus, difficilia sunt! - Seneca

Abt Themenstarter:in
16.806 Beiträge seit 2008
vor 6 Jahren

TDD sehe ich auch den als wenigsten verbreitete Ansatz. Wenn er gemacht wird, dann vor allem mit Firmen mit eigener Entwicklung.
Im Consulting, wo Release Management einfach das A und O ist (der Kunde betreibt ja, nicht der Consultant -> Haftung), ist TDD echt selten.

D
985 Beiträge seit 2014
vor 6 Jahren

Hmmm, ich mache mir eigentlich vor der Implementierung und vor den UnitTests darüber Gedanken, wie sich die Methode verhalten soll.

Diese Gedanken manifestiere ich dann in der XML-Dokumentation zu der Methode.
Dann schreibe ich die UnitTests, die sicherstellen, dass die Implementierung auch der Dokumentation folgen wird.
Dann implementiere ich die Methode.

Natürlich kommt es auch vor, dass ich erst mal drauf los implementiere, aber vor dem Unit-Test kommt bei mir immer die Dokumentation

Abt Themenstarter:in
16.806 Beiträge seit 2008
vor 6 Jahren

Da bist Du ehrlich gesagt wirklich ein Exot - quasi wie Go 😉

M
33 Beiträge seit 2012
vor 6 Jahren

zum Thema

Full Stack zähle ich persönlich nicht, da ich persönlich der Ansicht bin: es gibt heute keine Full Stack Entwickler mehr.

wie nennt man denn den Esel der alles machen muss (Frontend, Backend, Windows, Web, Datenbank), weil es nur einen Entwickler im Haus gibt ?

mfg
ein Esel

Falls fallend du vom Dach verschwandest, brems bevor du Unten landest.

Abt Themenstarter:in
16.806 Beiträge seit 2008
vor 6 Jahren

Dann bist Du ein Entwickler. Punkt. Evtl. noch ein Entwickler in verschiedenen Bereichen; aber kein Full Stack Entwickler. Denn Full = Alles.
Anders sind eben fokussierte Entwickler, die nennen sich gleich "Frontend Entwickler" oder evtl. noch "Web Entwickler". Da weiß man gleich, welchen Bereich er abdeckt.
Aber Full Stack ist einfach quatsch.

Full Stack ist in meinen Augen das Äquivalent zu: Jack of all trades, master of none

Die Technologiebreite und -tiefe, die heute existiert, lässt es nicht zu, dass Du alles beherrscht.
So jemanden gibt es einfach nicht.

Man baut auch höchstens ne Holzhütte alleine und nennt sich dann "Hausbauer" aber für nen Wolkenkratzer bringt einem das halt noch lange nichts; da müssen Profis ran.
Nichts anderes ist Software.

1.040 Beiträge seit 2007
vor 6 Jahren

Unit Tests werden glaube ich oft nicht gemacht, weil sich Entwickler überschätzen - oder sie einfach grotten faul sind.

Ein Kollege meinte mal: "Informatik soll Faulheit fördern.". 😁

Aber mal ernsthaft.
Habe mal gelernt, dass man für einen guten UnitTest zeitlich ungefähr so lange braucht, wie für die Implementierung der zu testenden Methode.

Bei einem vorherigem Arbeitgeber lief das dann ungefähr so ab:
Arbeitgeber: "Wie lange brauchst du für die und die Anforderung?"
Entwickler: "4 Stunden für die Implementierung und UnitTests."
Arbeitgeber: "Und nur für die Implementierung?"

UnitTests werden nach meiner Erfahrung in der Führungsebene oft als zeitfressendes Übel angesehen.

Abt Themenstarter:in
16.806 Beiträge seit 2008
vor 6 Jahren

Viele vergessen bei Unit Tests aber plötzlich zu programmieren.
Hier kann man genauso Code generisch halten wie in der Implementierung um Code und damit Zeit einzusparen.
Und dann gibts eben noch Test-Frameworks wie xunit und FluentAssertions, mit denen man viel schneller mit viel weniger aufwand eine höhere Code-Abdeckung bekommt.

Aber ja, Tests schreiben kostet Zeit.

Faulheit darf sie fördern, solange die Qualität nicht darunter leidet.
Weil das ist das aktuelle Problem der Software Branche: Qualität.

Und hier hilft wieder das eigentliche Thema: DevOps.

M
33 Beiträge seit 2012
vor 6 Jahren

Dann mach aus einem Full-Stack einen "nur" Entwickler bitte.

Das man im Bereich Software nicht "ALLES"-können kann, ist heute
wohl nachvollziehbar 😃

mfg
Wasabi

Falls fallend du vom Dach verschwandest, brems bevor du Unten landest.

3.003 Beiträge seit 2006
vor 6 Jahren

Interessant, offenbar habe ich, was TDD angeht, einen Tunnelblick.

@palin:

Arbeitgeber: "Wie lange brauchst du für die und die Anforderung?"
Entwickler: "4 Stunden für die Implementierung und UnitTests."
Arbeitgeber: "Und nur für die Implementierung?"

Entwickler: "4 Stunden".

Bei Arbeitsanweisung dieselbe schriftlich festhalten. Das ist nach meiner Auffassung eine direkte Anweisung, auf die grundlegenden Qualitätssicherungsmaßnahmen zu verzichten. Also absichern, damit mangelnde Qualität dann nicht dir zugeschoben wird. Und mittelfristig anderen Job suchen.

(Das ist genau das, was ich ganz oben meinte. Solche Arbeitgeber sind besser heute als morgen aus dem Geschäft. Wenn man auf die Qualität seiner Produkte einen Haufen setzen möchte, kann man immer noch am BER anfangen. grrr)

@Wasabi: das ist bei der breiten Masse der Recruiter leider noch nicht angekommen. Die Suche nach einem "full stack" developer sollte mittlerweile ein rotes Warnschild sein: hier wird ein Mädchen für alles gesucht, weil man eigentlich keine richtige Stellenbeschreibung hat.

LaTino

"Furlow, is it always about money?"
"Is there anything else? I mean, how much sex can you have?"
"Don't know. I haven't maxed out yet."
(Furlow & Crichton, Farscape)

1.040 Beiträge seit 2007
vor 6 Jahren

Also absichern, damit mangelnde Qualität dann nicht dir zugeschoben wird.

Naja, im Endeffekt ist sowieso immer das letzte Glied der Nahrungskette Schuld, auch wenn man nachweisen könnte, dass man dafür mehr Zeit veranschlagen wollte. 😉
Und gelernt hat man meistens auch nichts daraus...

EDIT sagt noch:
Es gibt natürlich auch die Variante, dass man im Nachhinein die Frage gestellt bekommt, warum man denn keinen UnitTest geschrieben hat. Das man die dafür benötigte Zeit nicht zur Verfügung gestellt bekommen hat, weiß dann natürlich keiner mehr.

Und mittelfristig anderen Job suchen.

Schon erledigt. 👍

D
985 Beiträge seit 2014
vor 6 Jahren

Arbeitgeber: "Wie lange brauchst du für die und die Anforderung?"
Entwickler: "4 Stunden für die Implementierung und UnitTests."
Arbeitgeber: "Und nur für die Implementierung?"

5-6 Stunden

Also ich habe vor einiger Zeit eine Berechnung implementiert, deren Formeln (einige) auf 5 DIN-A4 Seiten standen (handschriftlich), die auch noch in sich verkrümmt und verkräuselt waren.

Ohne Unit-Tests hätte ich hierfür definitiv länger gebraucht.

P
1.090 Beiträge seit 2011
vor 6 Jahren

Das wäre aber Aufgabe des Releasemanagements und nicht des Buildsystems.

>

Das Release würde hier im Gegensatz zur Dev Stage für die QA Stage eine erweiterte Konfiguration für die Testdaten haben.
Neu builden ist nicht DevOps-konform.

Kling Interessant muss ich mir mal in Ruhe anschauen.
Vielleicht direkt eine Kurze Frage dazu, wie ist das mit Integrations- und Codesd UI Test wandern, die dann mit in das Release Management?

Im Build ist es aktuell weil es historisch so gewachsen ist, erst Unit Test, dann Integartions Test (für die die Test Daten erzeugt werden mussten) und dann Coded UI Test, wo zu ich die Seite veröffentlicht habe und die konnte dann ganz einfach von der QS mit Verwendet werden.

@p!lle Als Arzt der Enterprise solltest du doch den Scotty Factor kennen.

Zu Unit Test gibt es unterschiedliche Studien was die Zeit angeht. Bei Microsoft und IBM würde eine Studie gemacht nach der Unit Test die Anfängliche Entwicklungszeit um 15-35% erhöht haben es dafür aber 40-90% weniger Fehler. (Sind jetzt 2 Links da ich die Ursprüngliche Studie jetzt nicht auf die Schnelle bei google gefunden habe.

Roy Osherove hat in seinen Buch The Art of Unit Testing noch eine Studie (Time difference between developing with unit tests vs no tests), die die Zeit bis zum Release Betrachtet und die im Anschluss gefundenen Fehler. Mit Unit Tests waren es 23 Tage und 11 Fehler, ohne Unit Tests waren es 26 Tage und 71 Fehler.

Unit Test schreibe ich, grade weil ich faul bin. 😉

Sollte man mal gelesen haben:

Clean Code Developer
Entwurfsmuster
Anti-Pattern

Abt Themenstarter:in
16.806 Beiträge seit 2008
vor 6 Jahren

Nein, Tests bleiben prinzipiell im Build.
Ohne gültige Tests kann es kein gültiges Artifakt geben.

Aber im Release Management kann man weitere Tests machen, zB. Performance Tests gegen die Live-Hardware.