Gibt es seriöse Unternehmen, die keine Versionskontrolle und kontinuierliche Integration einsetzen? Warum?

17

Ein Kollege von mir hatte den Eindruck, dass unsere Softwareabteilung sehr weit fortgeschritten war, da wir sowohl einen Build-Server mit kontinuierlicher Integration als auch Versionskontrollsoftware verwendeten. Dies passte nicht zu meiner Sichtweise, da ich nur eine Firma kenne, die seriöse Software herstellte und auch keine hatte. Meine Erfahrung ist jedoch auf eine Handvoll Unternehmen beschränkt.

Kennt jemand eine echte Firma (größer als 3 Programmierer) , die im Softwaregeschäft tätig ist und diese Tools nicht verwendet? Wenn es eine solche Firma gibt, gibt es einen guten Grund, warum sie das nicht tut?

Daramarak
quelle
3
Diese lästigen Softwareschauspieler.
Leichtigkeit Rennen mit Monica
1
unterscheiden sich Software-Akteure von Software-Entwicklern?
Aditya P
"Ich bin keine Software, aber ich spiele eine im Fernsehen !!" - Software-Schauspieler.
FrustratedWithFormsDesigner
1
Es gibt Jayne Seymour, sie ist eine ernsthafte Software-Schauspielerin ... oder sie spielte zumindest Solitare in Live und Let Die :)
Kevin D
3
Wo ich vor zehn Jahren gearbeitet habe, hatten wir nächtliche Builds auf allen unterstützten Systemen. Sie kamen nie in die Nähe der Kompilierung. Je.
David Thornley

Antworten:

5

Ich bin mir nicht sicher, ob Sie es ernst meinen, aber MySpace ist in dieser Hinsicht ziemlich arm: Siehe http://highscalability.com/blog/2011/3/25/did-the-microsoft-stack-kill- myspace.html .

Steve
quelle
1
+1 Sie sind mindestens in der obersten Liga. Ich hätte nicht gedacht, dass das möglich ist. So ein großes Unternehmen ohne Versionskontrolle. Stelle dir das vor.
Daramarak
Verrückt. Ich hätte es nicht geglaubt, aber dieser Blog und die Verweise aus dem Artikel sind alle zuverlässig.
Steve
Schuld daran ist der Hund.
JeffO
2
Eine Website für Teenager, die eine Band in einer Garage gründen, ist im Stil eines Kodierers geschrieben, der von ihrer Garage aus arbeitet. Figuren.
quant_dev
13

Sie wären überrascht zu sehen, was die Realität mit dem gesunden Menschenverstand anstellen kann ;-)

Ich denke, es gibt immer noch einige Unternehmen, die kein Versionskontrollsystem verwenden. Interessanterweise in all den Fällen, die ich bisher gesehen habe, ist es nicht, weil sie bereitwillig gegen die Verwendung solcher Systeme sind, sondern weil sie nicht wissen, dass so etwas wie SVN existiert! Was mich betrifft: Ich stimme Ihnen voll und ganz zu und kann mir keine Situation vorstellen, in der ich keine Versionskontrolle verwenden möchte. Zur Hölle, ich schiebe sogar meine eigenen persönlichen Dateien (Word-Dokumente usw.) auf meinem Heim-PC in ein GIT-Repository.

Im Falle eines kontinuierlichen Integrationssystems ist es etwas üblicher, sie nicht im täglichen Betrieb einzusetzen. Manchmal auch, weil die Leute nicht wissen, dass es ein solches System gibt, aber ich habe auch Fälle gesehen, in denen die - sehr fragwürdige - Entschuldigung für das Nichtgebrauchen darin besteht, dass "wir nicht komplex genug sind" oder "es ohne kontinuierliche Integration sehr gut funktioniert, Warum also eine andere Technologie hinzufügen? " Das ist natürlich keine realistische Einschätzung - aber um die ursprüngliche Frage zu beantworten: Es ist gar nicht so ungewöhnlich.

perdian
quelle
11
Ist es möglich, dass ein durchschnittlicher Softwareentwickler nichts von Versionskontrollsoftware gehört hat? Woher nehmen diese Unternehmen Mitarbeiter? Die dunkle Seite des Mondes?
Daramarak
7
@daramarak: Viele (wenn nicht die meisten) Softwareentwickler lesen keine Bücher, durchsuchen keine Entwicklungsblogs und kommunizieren überhaupt nicht mit anderen Entwicklern (außerhalb ihres Unternehmens). Wenn Sie sich in die Entwicklung einarbeiten, indem Sie sich mit einem dieser Bücher über "Visual Basic in 21 Tagen lernen" vertraut machen, ist es unwahrscheinlich, dass Sie etwas über die Versionskontrolle erfahren. Tatsächlich kann ich mich nicht erinnern, vor 10 Jahren etwas über die Versionskontrolle an der Universität gelernt zu haben.
Joeri Sebrechts
@joeri - zum Glück nicht wahr, wo ich arbeite, aber ich kann es im Allgemeinen glauben.
Steve
@perdian - du sagst "ziemlich viele Firmen", gibst aber keine Einzelheiten an ... hast du irgendwelche Links zu Artikeln, Blogs usw., die benannt und beschämt werden? Ich sage nicht , ich glaube dir nicht (in der Tat ich tun Sie glauben), aber die Daten ist immer gut ...
Steve
@Steve Haigh - Nein, ich habe keine "harten" Beweise. Ich habe ein paar Unternehmen selbst gesehen , dass die Verwendung CI nicht oder Versionskontrolle (deren Namen ich für mich behalten würde g ) und mit einem wenig Extrapolation Ich gehe davon aus, dass es viel mehr ist „da draußen“. Ich denke, es ist sehr einfach, Unternehmen zu finden, die CI verwenden, indem Sie sich zum Beispiel die Referenzliste auf der Jenkins-Seite ansehen . Aber umgekehrt? Es gibt nicht viele Leute, die Werbung für "Hey, wir verwenden keine Technologie X" machen ;-)
perdian
12

Nahezu jedes Unternehmen in meiner Branche (Banken) verwendet derzeit die Versionskontrolle. Es ist jedoch durchaus möglich, Software ohne Versionskontrolle erfolgreich zu entwickeln. Vor 20-30 Jahren. genau das haben wir getan.

Ich würde sagen, dass viele Banken, vielleicht sogar die Mehrheit, keinen Build-Server mit kontinuierlicher Integration verwenden. Wenn Sie bereits erfolgreich Software ohne kontinuierliche Integration bereitstellen, ist es absolut sinnvoll, diesen Weg fortzusetzen.

Strassenkämpfer
quelle
3
Ich bin nicht der Meinung, dass es vollkommen vernünftig ist, "diesen Weg fortzusetzen". Ja, wenn Software in den letzten X Jahren ausgeliefert wurde, bedeutet dies nicht, dass sie in den nächsten Y Jahren ohne Änderungen nicht funktioniert. Nach der Einführung von CI in bestehende (und recht ausgereifte) Softwareprodukte ist jedoch immer etwas davon zu profitieren.
perdian
1
@perdian: Es gibt immer etwas zu gewinnen von vielen Initiativen. Sie müssen also CI gegen alles andere abwägen. Sie können nicht einfach behaupten, dass CI Ihnen mehr Nutzen bringt als alles andere. Sie müssen auch Opportunitätskosten messen.
RoadWarrior
1
@ SK-logic: RCS war zu diesem Zeitpunkt im britischen Bankensektor völlig unbekannt. Und wir haben einige sehr große und robuste Systeme ohne Quellcodeverwaltung entwickelt.
RoadWarrior
1
-1: "Fast jedes Unternehmen", das ist eine zu weite Aussage, die falsch ist. Ich habe im letzten Jahr einige Unternehmen gesehen, die kein Versionskontrolle-Tool verwenden und sich auf Versionskopien in einem freigegebenen Verzeichnis verlassen. Ja, das hat mich zum Weinen gebracht. Sie sagten, dass "svn zu schwer zu benutzen ist". OH MEIN GOTT. Aber ich finde immer noch einige Unternehmen, die so sind. Verallgemeinern Sie nicht, nicht jeder in der Branche weiß, was ein Quellcodeverwaltungssystem ist, und auch nicht, was eine kontinuierliche Integration ist. (Ich stimme zu, das ist die Hölle. Ich bin froh, nicht mehr da zu sein.)
Klaim 29.06.11
1
@ SK-logic - ... was RoadWarrior gesagt hat, außer in der Schiffs- / Kraftindustrie hier. Ich werde keine Namen nennen, aber ich kenne mindestens zwei Unternehmen, die in ihrer Branche dominant sind (einige spezialisierte Softwareentwickler), für die meines Erachtens niemals VCS (in Ihrem Sinne) verwendet wurden. Sie hatten ihre Möglichkeiten, guten Code von in Arbeit befindlichem Code zu unterscheiden.
Rook
7

Nur um einen Gegenpunkt zur Antwort von @ RoadWarrior zu setzen:

Ich arbeite für eine Bank. Ich habe die letzten 3 Jahre damit verbracht, die Versionskontrolle zu implementieren und habe es nun geschafft, sie auf ungefähr 20% unserer Codebasis zu bringen (was ziemlich groß ist, wir haben ungefähr 20 Entwickler und haben unsere Systeme für> 16 Jahre entwickelt).

Durch meine Kontakte in der Branche (Bankwesen) kenne ich eine Menge anderer Finanzinstitute, die nicht über das verfügen, was eine vernünftige Person als Versionskontrolle bezeichnen würde.

Ja, unsere Branche (Softwareentwicklung) ist viel trauriger, als die meisten zugeben möchten.

Dan McGrath
quelle
Mein Beileid. Klingt so, als ob zumindest einigen Teilen der Branche die Werkzeuge ernsthaft fehlen. Ich denke, es ist wieder die Geschichte von den Schusterkindern. Könnte ich fragen, was eine verrückte Person Versionskontrolle nennen würde?
Daramarak
6
Kopieren Sie den Code manuell, bevor Sie ihn bearbeiten. ZB MyProg -> MyProd.old4
Dan McGrath
Leider ist diese Praxis häufiger als die Leute denken
Craig T
3

Versionskontrolle: In meinem ersten Job vor 25 Jahren gab es kein Versionskontrollsystem als solches, aber dies war RSX11 auf PDP-11s. Es gab jedoch ein sehr hohes Maß an Qualitätskontrolle mit formellen Überprüfungen von Design und Code (dies war in der Nuklearindustrie der Fall).

Seitdem hat jeder Job Versionskontrollsysteme verwendet, einschließlich SCCS, PVCS, Clearcase, CVS und Perforce.

Meiner Erfahrung nach ist die Verwendung der Versionskontrolle in der ernsthaften Softwareentwicklung ziemlich universell.

Kontinuierliche Integration: Dies ist ein größeres Problem, insbesondere an Orten, an denen viel Legacy-Code vorhanden ist, der wahrscheinlich nicht einmal die Möglichkeit zum automatisierten Testen bietet. Es ist eine sehr große Investition, vorhandenen Code in eine CI-Umgebung zu verschieben, und obwohl es sich wahrscheinlich am Ende auszahlt, ist es schwierig, das Management dazu zu bringen, eine solche Investition ohne kurzfristigen Gewinn zu tätigen.

Ich habe an einem Ort (einer großen Bank) gearbeitet, an dem CI für einige Projekte eingerichtet war, und wir haben eine Art CI-System für unser Projekt implementiert, was die Dinge viel einfacher gemacht hat, aber ungefähr 6 Monate in Anspruch genommen hat.

Chris Card
quelle
Haben sie für die Orte mit altem Code automatisierte Builds durchgeführt oder hatten sie einen manuellen Build- / Bereitstellungsplan?
Daramarak
3

Ich würde mir vorstellen, dass MOST-Unternehmen diese Dinge nicht verwenden, weil sie die Vorteile nicht verstehen und ihre Entwickler entweder nicht lernen wollen oder Angst haben, den Topf zu rühren, indem sie Dinge anders machen, als sie es bisher getan haben vorher gemacht.

Wayne Molina
quelle
3
Absolut! Ich habe die Antwort gehört (oder vielleicht sollten wir es eine lahme Ausrede nennen) "wir haben sie bisher nicht benutzt und da sie (irgendwie) funktioniert hat, brauchen wir sie nicht". Es ist eine Schande, wie hartnäckig die Leute dagegen sind, ihre Werkzeuge zu wechseln.
perdian
1
Ich kann solche Leute nicht leiden. Leider ist dies die Art von "Entwickler", der ich in meiner Karriere nur allzu häufig begegnet bin, und ich kann mich einfach nicht mit ihrer Ignoranz auseinandersetzen und versuche immer, ein Unternehmen zu verlassen, in dem diese Arten von Entwicklern vorherrschen. Diese Art von Menschen, die Gefahr laufen, geradezu feindselig zu klingen, erkranken an diesem Beruf.
Wayne Molina
2

Obwohl ich jetzt Angestellter bin, war ich als Datenbankberater selbständig. Während dieser vielen, vielen Jahre war ich in 800 bis 1000 Unternehmen tätig, von Tante-Emma-Unternehmen bis hin zu Fortune-100-Unternehmen.

Ich habe relativ wenige Orte gesehen, die eine kontinuierliche Integration durchgeführt haben, kann mich aber nicht erinnern, jemals ein Unternehmen gesehen zu haben, das keine Versionskontrolle verwendet hat. In einigen Fällen gab es kein zentrales Repository für versionsgesteuerten Code. Einzelne Programmierer verwendeten die Versionskontrolle entweder auf ihren eigenen Computern oder behielten den versionskontrollierten Code irgendwo unterhalb ihres Ausgangsverzeichnisses auf dem Server.

Ich glaube nicht, dass eine dieser Firmen im Softwaregeschäft tätig war, aber ihre Programmierer waren es mit Sicherheit.

Mike Sherrill 'Cat Recall'
quelle
1

Ein Kollege von mir hatte den Eindruck, dass unsere Softwareabteilung hoch entwickelt war, da wir sowohl einen Build-Server mit kontinuierlicher Integration als auch eine Versionskontrollsoftware verwendeten.

Nein, ich hasse es, es zu sagen, aber das ist wahr. Bei den letzten beiden Arbeiten (einer Abteilung einer Bank und einer Finanzgesellschaft) war ich derjenige, der das Versionskontrollsystem implementiert hat. Eine Reihe von Orten (insbesondere Nicht-Software-Shops) verstehen nicht, warum dies für eine langfristige Entwicklung wirklich notwendig ist. Das Team beginnt normalerweise mit ein oder zwei Personen und wächst dann, wenn auch schmerzhaft. Mit einer oder zwei Personen kommt man (nicht gut) ohne aus, weil man fast ständig miteinander kommunizieren kann.

Continuous Build ist ein ganz anderer Fall. Wenn ich raten müsste, würde ich wetten, dass fast 90% der Orte, an denen die Entwicklung durchgeführt wird, keine CI-Lösung haben. Ich gehe zu Konferenzen und die meisten Leute sind erstaunt, dass es eine andere Organisation als MS oder Google gibt. Was ich herausgefunden habe, ist, dass das Management nicht den geringen Geldbetrag ausgeben möchte, um es zum Laufen zu bringen, obwohl es viel Zeit sparen kann.

Die größten Gründe, die ich dafür gefunden habe, sind:

  1. Die Führungskräfte sind in der gleichen Organisation durch die Reihen aufgestiegen. Sie haben es nie benutzt und brauchten es nicht. Warum sollten sie es jetzt ändern? Einige, die ich gefunden habe, haben nur Angst vor Veränderungen. Etwas Neues ist beängstigend, und es würde verhindern, dass sie ihren alten Compiler abstauben und unseren jüngeren in Notzeiten helfen. Zu anderen Zeiten (und häufiger) verfügen sie über immer knappe Budgets und müssen entscheiden, wo sie Geld ausgeben. Für uns ist die Implementierung ein offensichtlicher Bedarf, aber das liegt daran, dass wir sie bereits verwendet haben. Wir kennen die Vorteile, sie nicht.

  2. Manager sind keine IT-Mitarbeiter, und alles, was sie hier tun, ist, dass Sie Geld für etwas ausgeben möchten, das zuvor nicht benötigt wurde.

Die meisten Argumente, die ich von Leuten gehört habe, drehen sich um Best Practices usw. und diese sind wahr, aber was die meisten Entwickler nicht verstehen, ist, dass Sie in diesem Szenario eine finanzielle Situation angeben müssen. Mit dieser Menge Geld, die Sie ausgeben werden, sparen wir X Zeit und Sie benötigen Zahlen, um sie zu sichern. Dies ist nicht immer wahr, aber es war meine Erfahrung in der Vergangenheit.

kemiller2002
quelle
Ich kann mir vorstellen, dass solche Probleme auftreten, wenn der Entwickler und die Geschäftsleitung nicht gut miteinander kommunizieren. Zum Glück sind nicht alle Unternehmen so. Wo ich arbeite, müssen wir (sofern nicht verpflichtet) der Geschäftsleitung mitteilen, ob uns etwas effektiver machen könnte.
Daramarak
1

Ich würde sagen, dass viele Leute die Quellcodeverwaltung nicht verwenden, weil sie möglicherweise selbstständig codieren und es gewohnt sind, die Codebasis regelmäßig auf einem zentralen Server oder einer USB-Festplatte zu sichern. Ich habe mich vor ungefähr einem Jahr gezwungen, SVN zu verwenden, weil ich wusste, dass es auf lange Sicht vorteilhaft sein würde. Es hat eine Weile gedauert, bis ich mich daran gewöhnt habe, aber jetzt habe ich Tonnen von Code-Verlauf, auf die ich mich ständig beziehen kann. Ich wünschte jetzt, ich hätte es vor vier Jahren implementiert, als ich anfing.

Kontinuierliche Integration? Verwenden Sie es nur, wenn Sie es brauchen. Für mich gibt es nur zwei Softwareingenieure, daher würden wir von einer kontinuierlichen Integration nicht profitieren, da wir selbst an unserer eigenen Software arbeiten.

Brian
quelle
1
Die kontinuierliche Integration soll Fehler erkennen, wenn sie auftreten. Sogar zwei Entwickler brauchen das.
Daramarak
1
@daramarak: Nicht, wenn die beiden Ingenieure unabhängig voneinander an zwei separaten Produkten arbeiten, die nicht integriert sind.
Brian
1
CI ist eines der Dinge, auf die ich verzichten möchte. Persönlich würde ich es gerne in meinem Job haben, aber es wird nicht so schnell passieren. Wir haben allerdings 1-2 mal am Tag automatische Builds, und das ist wirklich ausreichend für unsere Bedürfnisse.
Michael K
1
Mit einem automatisierten Build sind Sie auf halbem Weg. Nur zu wissen, dass alles, was beim Kompilieren eingecheckt wird, manchmal eine Freude sein kann ("Es kompiliert auf meinem Computer")
Daramarak
1

Ha, Sie denken, Sie sind fortgeschritten, weil Sie SCM und ein CI-System haben? Lassen Sie mich Ihnen sagen, dass es eine Amateurstunde ist, wenn es darauf ankommt.

Viele Unternehmen tun das erforderliche Minimum, denn das ist alles, was es wirklich braucht . Wenn es funktioniert und Sie ohne großen Aufwand gute reproduzierbare Veröffentlichungen erhalten, muss nichts behoben werden. Das Letzte, was Sie unter solchen Umständen tun möchten, ist, das Problem zu beheben, insbesondere, wenn es darum geht, Administratorressourcen für die Einrichtung und Verwaltung Ihrer neuen Server und Build-Systeme zu entziehen.

Einige Unternehmen benötigen jedoch etwas strengere Systeme, die nicht nur die Erstellung, sondern auch die Anforderungen bis hin zur Bereitstellung über Testpläne und Testergebnisse steuern Vom Teamleiter festgelegte Arbeitspaketverwaltung. Das ist echtes Konfigurationsmanagement, und seien Sie verdammt froh, dass Sie nicht in einer solchen Umgebung arbeiten müssen!

Ich habe in ein paar Unternehmen gearbeitet und mir fallen keine ein, die keine Form von SCM hatten. Einige von ihnen waren umfassender als andere, aber alle hatten ein System, das für sie gut funktionierte, sogar für diejenigen, die VSS verwendeten.

gbjbaanb
quelle
lol! signiert: ein Profi.
Deadalnix
Ich stimme zu, SCM und ein Bug-Tracker ist das Entwicklungsäquivalent zum Tragen von Hosen zur Arbeit. CI ist die grundlegende Automatisierung einer kritischen Funktion. Wie automatische Backups, aber für Releases. Ah, CCB-Treffen. Jede Woche wie am Schnürchen.
Tim Williscroft
1

Selbst mit zwei Programmierern, wenn Sie an komplexen Anwendungen und einer Liste von Aufgaben arbeiten, kann es schwierig sein, die Änderungen nicht gegenseitig zu beeinflussen.

Sogar unsere alte Release-Management-Software zeigte die Änderungen nebeneinander und erlaubte es, sie in beide Richtungen anzuwenden. Änderungen wären ohne sie bei mehr als einer Gelegenheit verpasst worden.

Ich sehe eine Reihe von Vorteilen, die CI bietet, aber ich kann mir nicht vorstellen, warum ein Unternehmen keine Software zur Versionskontrolle einsetzt.

DHorse
quelle
1

Der letzte Job, bei dem ich ohne Versionskontrolle gearbeitet habe, war 2006 (ich bin ein Webentwickler, FWIW). Das Unternehmen hatte nur ungefähr 2 oder 3 Entwickler, bevor ich eingestellt wurde, aber ich war der erste von ungefähr 10 Entwicklern, die in nur wenigen Monaten eingestellt wurden. Eines der ersten Dinge, die ich bei meiner Einstellung tat, war die Einführung der Versionskontrolle (CVS, weil ich zu der Zeit nicht wusste, wie schlecht das funktioniert!), Aber viele der Entwickler, die nach meiner Einstellung eingestellt wurden, konnten es nicht zum Laufen bringen Umgebungen, also nicht verwendet. Oh, habe ich erwähnt, dass nicht einmal lokale Instanzen der Anwendung ausgeführt wurden? Sie haben Code auf dem Server gehackt. Und natürlich keine automatisierten Tests. Ich zucke zusammen, wenn ich daran zurückdenke.

Davor habe ich einige AS / 400-Programmierarbeiten ohne Versionskontrolle durchgeführt. Ich weiß nicht, ob für diese Umgebung überhaupt ein anständiges VCS verfügbar war.

Jetzt benutze ich Git für alle meine Ein-Mann-Projekte, und meine letzten Jobs haben es auch verwendet.

CI ist eine andere Sache. Es ist großartig, und ich unterstütze es, aber es ist weniger wichtig als die Versionskontrolle, zumindest für kleinere Projekte in interpretierten Sprachen. Die meisten meiner letzten Jobs hatten jedoch CI-Server. Dies bedeutet unter anderem, dass niemand vergessen kann, die vollständige Testsuite vor der Bereitstellung auszuführen.

Marnen Laibow-Koser
quelle
'CI ist eine andere Sache. Es ist großartig, und ich unterstütze es, aber es ist weniger wichtig als die Versionskontrolle, zumindest für kleinere Projekte in interpretierten Sprachen. ' Einverstanden. CI ist wirklich nur dann erforderlich, wenn Sie häufige und / oder komplexe Builds ausführen und dies viel Zeit in Anspruch nimmt oder wenn Sie eine Testsuite ausführen möchten oder wenn Sie in der Lage sein möchten, mehrere Zweige usw. zu implementieren Wenn Sie in einem PHP-Projekt mit einem Dutzend Entwicklern und keiner Testsuite einmal pro Woche in die Produktion gehen, sollten Sie sich wahrscheinlich auf einen guten QA-Workflow konzentrieren, bevor Sie sich Gedanken über CI machen.
Siliconrockstar
Und Sie sollten sich wahrscheinlich auf eine gute Testsuite konzentrieren, bevor Sie sich Gedanken über die Qualitätssicherung oder etwas anderes machen.
Marnen Laibow-Koser
Vielleicht in der Theorie, aber wenn Sie Open Source-Software verwenden, ist dies praktisch unmöglich, es sei denn, es wird mit einer Testsuite geliefert. Ich habe noch kein einziges Mal an einem PHP-Projekt mit einer angemessenen, vollständigen Testabdeckung gearbeitet, aber jedes Projekt, an dem ich gearbeitet habe, hatte ein gewisses Maß an Qualitätssicherung.
Siliconrockstar
@siliconrockstar Ich sprach davon, eine gute Testsuite für Ihren eigenen Code zu haben. Ein angemessenes Testniveau für Bibliothekscode ist eine ganz andere Sache.
Marnen Laibow-Koser
@siliconrockstar Für die meisten Rails-Projekte, an denen ich gearbeitet habe, war die Testabdeckung für Entwickler hervorragend (die Ausnahmen versuchten aktiv, sie zu verbessern). Nicht alle hatten eine formelle Qualitätssicherung. Es ist viel weniger notwendig, eine formelle Qualitätssicherung mit guten Tests durchzuführen, obwohl dies immer noch eine sehr gute Idee ist. Eine Entwicklung ohne vorhandene Tests ist jedoch äußerst riskant. Aus diesem Grund sollte die Verbesserung von Tests Vorrang vor allen anderen Aufgaben haben.
Marnen Laibow-Koser
0

Ich habe auf jeden Fall hier und da ein paar getroffen, aber hauptsächlich kleine Unternehmen. Das Problem, das ich häufiger sehe, sind Unternehmen, die tatsächlich über SCM verfügen, jedoch viele Projekte für zu klein oder unwichtig halten, um darin nachverfolgt zu werden.

JohnFx
quelle