Willkommen auf myCSharp.de! Anmelden | kostenlos registrieren
 | Suche | FAQ

Hauptmenü
myCSharp.de
» Startseite
» Forum
» Suche
» Regeln
» Wie poste ich richtig?

Mitglieder
» Liste / Suche
» Wer ist online?

Ressourcen
» FAQ
» Artikel
» C#-Snippets
» Jobbörse
» Microsoft Docs

Team
» Kontakt
» Cookies
» Spenden
» Datenschutz
» Impressum

  • »
  • Community
  • |
  • Diskussionsforum
Auswertung und Feedback zur DevOps-Umfrage
Abt
myCSharp.de - Team

Avatar #avatar-4119.png


Dabei seit:
Beiträge: 16206

Themenstarter:

Auswertung und Feedback zur DevOps-Umfrage

beantworten | zitieren | melden

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.

Kommentare

Von Vorn weg gleich mal die Nachrichten, die über das Kommentarfeld der Umfrage eingereicht wurden, da ich später nicht mehr drauf eingehen werde.
Zitat
Wieder mal sehr oberflächlich, wo ist Delphi ? Scheinbar wieder nur deine eigenen Vorlieben (Mobile/Agile Entwicklung)
Zitat
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.
- performance is a feature -

Microsoft MVP - @Website - @blog - @AzureStuttgart - github.com/BenjaminAbt
private Nachricht | Beiträge des Benutzers
bredator
myCSharp.de - Member



Dabei seit:
Beiträge: 368

beantworten | zitieren | melden

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. ;)
Dieser Beitrag wurde 2 mal editiert, zum letzten Mal von bredator am .
private Nachricht | Beiträge des Benutzers
Abt
myCSharp.de - Team

Avatar #avatar-4119.png


Dabei seit:
Beiträge: 16206

Themenstarter:

beantworten | zitieren | melden

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.

Zitat von bredator
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....
- performance is a feature -

Microsoft MVP - @Website - @blog - @AzureStuttgart - github.com/BenjaminAbt
private Nachricht | Beiträge des Benutzers
LaTino
myCSharp.de - Experte

Avatar #avatar-4122.png


Dabei seit:
Beiträge: 3062
Herkunft: Thüringen

beantworten | zitieren | melden

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)
private Nachricht | Beiträge des Benutzers
Abt
myCSharp.de - Team

Avatar #avatar-4119.png


Dabei seit:
Beiträge: 16206

Themenstarter:

beantworten | zitieren | melden

Details von Build- und RM-Systemverteilung ist nachgetragen; hatte ich vergessen. Sorry.
- performance is a feature -

Microsoft MVP - @Website - @blog - @AzureStuttgart - github.com/BenjaminAbt
private Nachricht | Beiträge des Benutzers
bredator
myCSharp.de - Member



Dabei seit:
Beiträge: 368

beantworten | zitieren | melden

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".
Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von bredator am .
private Nachricht | Beiträge des Benutzers
OlafSt
myCSharp.de - Member



Dabei seit:
Beiträge: 76
Herkunft: HH

beantworten | zitieren | melden

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.
private Nachricht | Beiträge des Benutzers
Abt
myCSharp.de - Team

Avatar #avatar-4119.png


Dabei seit:
Beiträge: 16206

Themenstarter:

beantworten | zitieren | melden

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?
Zitat von OlafSt
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?
Zitat von OlafSt
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)
Zitat von OlafSt
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.
Zitat von OlafSt
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?
Zitat von OlafSt
Gibt es ein paar wirklich brauchbare Artikel, die einem den Nutzen eines DevOps-Systems aufzeigen kann ?
DevOps ist kein System, sondern ein Entwicklungsprozess ;-)
Zitat von OlafSt
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.
Zitat von OlafSt
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.
- performance is a feature -

Microsoft MVP - @Website - @blog - @AzureStuttgart - github.com/BenjaminAbt
private Nachricht | Beiträge des Benutzers
Palin
myCSharp.de - Member



Dabei seit:
Beiträge: 1115

beantworten | zitieren | melden

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.)


Zitat
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
private Nachricht | Beiträge des Benutzers
LaTino
myCSharp.de - Experte

Avatar #avatar-4122.png


Dabei seit:
Beiträge: 3062
Herkunft: Thüringen

beantworten | zitieren | melden

Zitat von OlafSt
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.
Zitat
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.
Zitat
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)
private Nachricht | Beiträge des Benutzers
Abt
myCSharp.de - Team

Avatar #avatar-4119.png


Dabei seit:
Beiträge: 16206

Themenstarter:

beantworten | zitieren | melden

Zitat von Palin
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.
Zitat von Palin
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.
Zitat von Palin
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.
Zitat von Palin
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.
Zitat von Palin
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!
- performance is a feature -

Microsoft MVP - @Website - @blog - @AzureStuttgart - github.com/BenjaminAbt
private Nachricht | Beiträge des Benutzers
p!lle
myCSharp.de - Member

Avatar #avatar-3556.jpg


Dabei seit:
Beiträge: 1053

beantworten | zitieren | melden

Zitat von OlafSt
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.
private Nachricht | Beiträge des Benutzers
Deaktiviertes Profil
myCSharp.de - Member



Dabei seit:
Beiträge: 996

beantworten | zitieren | melden


... 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).
private Nachricht | Beiträge des Benutzers
LaTino
myCSharp.de - Experte

Avatar #avatar-4122.png


Dabei seit:
Beiträge: 3062
Herkunft: Thüringen

beantworten | zitieren | melden

...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)
private Nachricht | Beiträge des Benutzers
Deaktiviertes Profil
myCSharp.de - Member



Dabei seit:
Beiträge: 996

beantworten | zitieren | melden


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?
Dieser Beitrag wurde 3 mal editiert, zum letzten Mal von Deaktiviertes Profil am .
private Nachricht | Beiträge des Benutzers
Abt
myCSharp.de - Team

Avatar #avatar-4119.png


Dabei seit:
Beiträge: 16206

Themenstarter:

beantworten | zitieren | melden

Zitat von Sir Rufo
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.
- performance is a feature -

Microsoft MVP - @Website - @blog - @AzureStuttgart - github.com/BenjaminAbt
private Nachricht | Beiträge des Benutzers
Deaktiviertes Profil
myCSharp.de - Member



Dabei seit:
Beiträge: 996

beantworten | zitieren | melden

Zitat von Abt
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.
private Nachricht | Beiträge des Benutzers
Abt
myCSharp.de - Team

Avatar #avatar-4119.png


Dabei seit:
Beiträge: 16206

Themenstarter:

beantworten | zitieren | melden

Zitat von "Sir Rufo"
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.
- performance is a feature -

Microsoft MVP - @Website - @blog - @AzureStuttgart - github.com/BenjaminAbt
private Nachricht | Beiträge des Benutzers
Palin
myCSharp.de - Member



Dabei seit:
Beiträge: 1115

beantworten | zitieren | melden

Zitat von Abt
Zitat von Palin
Zitat von Palin
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.
Zitat von Abt
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.
Zitat von Sir Rufo
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.
Zitat von Abt
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
private Nachricht | Beiträge des Benutzers
Deaktiviertes Profil
myCSharp.de - Member



Dabei seit:
Beiträge: 996

beantworten | zitieren | melden

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.
private Nachricht | Beiträge des Benutzers
Abt
myCSharp.de - Team

Avatar #avatar-4119.png


Dabei seit:
Beiträge: 16206

Themenstarter:

beantworten | zitieren | melden

Zitat von Palin

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.
- performance is a feature -

Microsoft MVP - @Website - @blog - @AzureStuttgart - github.com/BenjaminAbt
private Nachricht | Beiträge des Benutzers
Palin
myCSharp.de - Member



Dabei seit:
Beiträge: 1115

beantworten | zitieren | melden

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
private Nachricht | Beiträge des Benutzers
Abt
myCSharp.de - Team

Avatar #avatar-4119.png


Dabei seit:
Beiträge: 16206

Themenstarter:

beantworten | zitieren | melden

Zitat von Palin
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.
- performance is a feature -

Microsoft MVP - @Website - @blog - @AzureStuttgart - github.com/BenjaminAbt
private Nachricht | Beiträge des Benutzers
MrChangeLog
myCSharp.de - Member

Avatar #avatar-4086.gif


Dabei seit:
Beiträge: 135

beantworten | zitieren | melden

Zitat von Abt
Neu builden ist nicht DevOps-konform.

Macht ja nix.
private Nachricht | Beiträge des Benutzers
Abt
myCSharp.de - Team

Avatar #avatar-4119.png


Dabei seit:
Beiträge: 16206

Themenstarter:

beantworten | zitieren | melden

Ä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.
- performance is a feature -

Microsoft MVP - @Website - @blog - @AzureStuttgart - github.com/BenjaminAbt
private Nachricht | Beiträge des Benutzers
MrChangeLog
myCSharp.de - Member

Avatar #avatar-4086.gif


Dabei seit:
Beiträge: 135

beantworten | zitieren | melden

Zitat von Abt
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
private Nachricht | Beiträge des Benutzers
Abt
myCSharp.de - Team

Avatar #avatar-4119.png


Dabei seit:
Beiträge: 16206

Themenstarter:

beantworten | zitieren | melden

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.
- performance is a feature -

Microsoft MVP - @Website - @blog - @AzureStuttgart - github.com/BenjaminAbt
private Nachricht | Beiträge des Benutzers
LaTino
myCSharp.de - Experte

Avatar #avatar-4122.png


Dabei seit:
Beiträge: 3062
Herkunft: Thüringen

beantworten | zitieren | melden

Zitat von Sir Rufo
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)
private Nachricht | Beiträge des Benutzers
MarsStein
myCSharp.de - Experte

Avatar #avatar-3191.gif


Dabei seit:
Beiträge: 3430
Herkunft: Trier -> München

beantworten | zitieren | melden

Zitat von LaTino
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
private Nachricht | Beiträge des Benutzers
Abt
myCSharp.de - Team

Avatar #avatar-4119.png


Dabei seit:
Beiträge: 16206

Themenstarter:

beantworten | zitieren | melden

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.
- performance is a feature -

Microsoft MVP - @Website - @blog - @AzureStuttgart - github.com/BenjaminAbt
private Nachricht | Beiträge des Benutzers
Entwickelt mit ♥ und ASP.NET Core. Version 0.1.343+72512b0987 vom Uhr. Betrieben auf Azure App Service (debian.10-x64 mit .NET 6.0.0-rtm.21522.10)
Copyright 2003-2021 myCSharp.de - Alle Rechte vorbehalten. Benutzerinhalte unterliegen cc-by-sa 4.0