Wie viele Entwickler werden vor der kontinuierlichen Integration für uns wirksam?

Die kontinuierliche Integration ist mit einem Mehraufwand verbunden, z. B. Einrichtung, Umschulung, Sensibilisierungsmaßnahmen, Unterbrechung der Behebung von "Fehlern", die sich als Datenprobleme herausstellen, erzwungene Trennung der Programmierstile von Bedenken usw.

Ab wann rechnet sich die kontinuierliche Integration?

EDIT: Das waren meine Erkenntnisse

Das Setup war CruiseControl.Net mit Nant, das von VSS oder TFS liest.

Hier einige Gründe für einen Fehler, die nichts mit dem Setup zu tun haben:

Untersuchungskosten : Die Zeit, die aufgewendet wird, um zu untersuchen, ob ein rotes Licht auf eine echte logische Inkonsistenz im Code, in der Datenqualität oder auf eine andere Ursache zurückzuführen ist, z ist ausgefallen usw. usw.)

Politische Kosten über der Infrastruktur : Ich habe überlegt, für jede Methode im Testlauf eine "Infrastruktur" -Prüfung durchzuführen. Ich hatte keine Lösung für das Timeout, außer den Build-Server zu ersetzen. Bürokratie störte und es gab keinen Serverersatz.

Kosten für die Korrektur von Komponententests : Ein rotes Licht aufgrund eines Datenqualitätsproblems kann ein Hinweis auf einen schlecht geschriebenen Komponententest sein. Daher wurden datenabhängige Komponententests neu geschrieben, um die Wahrscheinlichkeit eines roten Lichts aufgrund schlechter Daten zu verringern. In vielen Fällen wurden die erforderlichen Daten in die Testumgebung eingefügt, um die Komponententests genau ausführen zu können. Es ist sinnvoll zu sagen, dass der Test robuster wird, wenn er die Daten robuster macht, wenn er von diesen Daten abhängig ist. Das hat natürlich gut funktioniert!

Deckungskosten, dh Schreiben von Komponententests für bereits vorhandenen Code : Es bestand das Problem der Abdeckung durch Komponententests. Es gab Tausende von Methoden, die keine Unit-Tests hatten. Daher würde eine beträchtliche Anzahl von Manntagen benötigt, um diese zu erstellen. Da dies zu schwierig wäre, um ein Geschäftsmodell zu erstellen, wurde beschlossen, Unit-Tests für künftige neue öffentliche Methoden zu verwenden. Diejenigen, die keinen Komponententest hatten, wurden als "potentiell infrarot" bezeichnet. Ein interessanter Punkt hierbei ist, dass statische Methoden ein Diskussionspunkt dafür waren, wie es möglich wäre, eindeutig zu bestimmen, wie eine bestimmte statische Methode fehlgeschlagen ist.

Kosten für maßgeschneiderte Releases : Nant-Skripte gehen nur so weit. Sie eignen sich beispielsweise nicht für CMS-abhängige Builds für EPiServer, CMS oder eine UI-orientierte Datenbankbereitstellung.

Dies sind die Arten von Problemen, die bei stündlichen Testläufen und QS-Builds über Nacht auf dem Buildserver aufgetreten sind. Ich gehe davon aus, dass diese als Build-Master unnötig sind und diese Aufgaben zum Zeitpunkt der Veröffentlichung manuell ausführen können, insbesondere mit einer Ein-Mann-Band und einem kleinen Build. Einzelschritt-Builds haben meiner Erfahrung nach die Verwendung von CI nicht gerechtfertigt. Was ist mit den komplexeren, mehrstufigen Builds? Dies kann eine Herausforderung sein, insbesondere ohne ein Nant-Skript. Also waren diese nicht mehr erfolgreich, obwohl sie eines geschaffen hatten. Die Kosten für die Behebung der Rotlichtprobleme überwogen die Vorteile. Schließlich verloren die Entwickler das Interesse und stellten die Gültigkeit des roten Lichts in Frage.

Nach einem fairen Versuch bin ich der Meinung, dass CI teuer ist und viel an den Rändern gearbeitet wird, anstatt nur die Arbeit zu erledigen. Es ist kostengünstiger, erfahrene Entwickler zu beschäftigen, die keine großen Projekte durcheinander bringen, als ein Alarmsystem einzuführen und zu warten.

Dies ist auch dann der Fall, wenn diese Entwickler das Unternehmen verlassen. Es spielt keine Rolle, ob ein guter Entwickler das Unternehmen verlässt, da durch die von ihm befolgten Prozesse sichergestellt wird, dass er Anforderungsspezifikationen und Entwurfsspezifikationen schreibt, die Codierungsrichtlinien einhält und seinen Code so kommentiert, dass er lesbar ist. All dies wird überprüft. Wenn dies nicht geschieht, erledigt sein Teamleiter seine Arbeit nicht. Dies sollte von seinem Vorgesetzten usw. übernommen werden.

Damit CI funktioniert, reicht es nicht aus, nur Komponententests zu schreiben, die vollständige Abdeckung beizubehalten und eine funktionierende Infrastruktur für große Systeme sicherzustellen.

Fazit: Man könnte sich fragen, ob die Behebung möglichst vieler Fehler vor der Veröffentlichung aus betriebswirtschaftlicher Sicht überhaupt wünschenswert ist. CI erfordert viel Arbeit, um eine Handvoll von Fehlern zu erfassen, die der Kunde in UAT identifizieren oder das Unternehmen für die Behebung im Rahmen eines Kundendienstvertrages bezahlen kann, wenn die Garantiezeit ohnehin abläuft.

Das Einrichten eines CI-Motors entspricht dem Einrichten eines Feuermelders in einem Haus.

Meiner Meinung nach korrelieren die Vorteile nicht mit vielen Entwicklern, sondern mit einer großen Codebasis. Die CI-Engine erledigt aktiv alle langweiligen Arbeiten, die Sie nicht selbst ausführen möchten, und dies jedes Mal.

Wenn Sie ein Remote-Modul beschädigen, das Sie lange nicht mehr berührt haben, werden Sie sofort darüber informiert. Nicht nur in Bezug auf die Kompilierung, sondern auch in Bezug auf die Funktion, wenn Sie Unit-Tests eingerichtet haben.

Beachten Sie auch , dass , wenn Sie lassen Sie CI-Motor tun alle die langweilige Arbeit, einschließlich Installateure usw. einrichten, Sie haben es nicht manuell zu tun. Sie können einfach Ihre Quelle einchecken und darauf warten, dass das fertige Produkt am Standardstandort hergestellt wird. (BEARBEITEN: Die CI-Engine arbeitet auch in einer genau definierten Umgebung, wobei keine Entwicklereinstellungen erforderlich sind, um die Reproduzierbarkeit zu gewährleisten.)

Dies ist auch Teil der Qualitätssicherung.

BEARBEITEN: Nachdem ich das oben Genannte geschrieben habe, habe ich Erfahrung mit dem Maven Build Tool für Java. Dies ermöglicht es uns im Wesentlichen, die gesamte CI-Konfiguration innerhalb des Projekts (mit pom.xml) beizubehalten, was die Wartung der CI-Installation und / oder die Migration auf eine andere CI-Engine erheblich vereinfacht.

Es ist nicht die Anzahl der Entwickler, sondern die Anzahl der Schritte, die erforderlich sind, um von 1 zu n (einschließlich) zu gelangen, wobei 1 & n ...

1: Code auschecken
und
n: installierbare \ implementierbare Pakete haben

Wenn n <2, benötigen Sie möglicherweise kein CI.
Andernfalls benötigen Sie ein CI

Update Nach dem
Lesen Ihrer Ergebnisse kann ich nur den Schluss ziehen, dass Sie sich aus den falschen Gründen an CI gewandt haben.

Auch für ein Team von einem kann sich die Mühe lohnen. Dies gilt insbesondere dann, wenn Sie plattformübergreifenden Code entwickeln und sicherstellen müssen, dass Ihre Änderungen auf beiden Plattformen funktionieren. Zum Beispiel ist der C ++ - Compiler von Microsoft akzeptabler als GCC. Wenn Sie also unter Windows entwickeln, aber auch Linux unterstützen müssen, ist es eine große Hilfe, wenn Sie von einem CI-System erfahren, wann Ihr Build unter Linux abbricht.

Einige CI-Systeme sind recht einfach einzurichten, sodass der Overhead nicht wirklich so groß ist. Probieren Sie zum Beispiel Jenkins oder Hudson.

Wie Sie sagen, entstehen zusätzliche Kosten für die Einrichtung und den Betrieb.

Die Frage, wo die Gewinnschwelle liegt, hängt jedoch nicht davon ab, wie viele Personen in Ihrem Team beschäftigt sind, sondern von der Länge Ihres Projekts.

Allerdings gibt es einen Teil der Einrichtungskosten, die Sie in all Ihren zukünftigen Projekten verwenden können, sodass die Gemeinkosten langfristig gegen Null gehen können.

Ich habe Jenkins diese Woche eingerichtet, um ein kleines .NET-Projekt zu erstellen, an dem ich arbeite. Ich habe es in meine Git-Quellcodeverwaltung integriert, sodass bei jedem Commit ein Build ausgelöst wurde. Ich habe die Unit-Tests in den Build integriert. Ich habe die statische Analyse in Form von FxCop- und StyleCop-Verstößen integriert.

Jedes Mal, wenn ich einchecke, checkt es meinen gesamten Code aus, erstellt ihn, erhöht die Versionsnummer für alle Assemblys, testet ihn, analysiert ihn auf FxCop- und StyleCop-Verstöße, archiviert den Build und zeichnet die Ergebnisse in einer Reihe von Diagrammen auf Ich habe im Laufe der Zeit Einblick in Testergebnisse und Verstöße.

Dies von Grund auf zu tun, dauert ungefähr eine Stunde (vielleicht einen Tag mit Google, wenn Sie es noch nicht getan haben). Es kostet nichts, da alle Tools kostenlos zur Verfügung stehen.

Wenn, wie und wann das Projekt erstellt wird, habe ich eine qualitativ hochwertige Infrastruktur, die kostenlos mitwächst. Wenn oder wenn neue Entwickler dem Projekt beitreten, kann ich kostenlos einen vollständigen Überblick über ihre Arbeit und ihre Auswirkungen auf das Projekt erhalten.

Das einzige Szenario, in dem ich sehe, dass sich CI nicht lohnt, ist entweder ein Projekt, das einen Tag in Anspruch nimmt und dann nie wieder aufgegriffen wird, oder eines in einer Sprache, in der keine vorhandenen / kostenlosen Tools verfügbar sind und deren Anschaffungskosten ist unverhältnismäßig zur Arbeit.

Wenn Sie nach jeder Änderung alle Aspekte Ihres Projekts überprüfen können, benötigen Sie kein CI.

In allen anderen Fällen ist es ein Nettogewinn.

Der Aufwand ist minimal. Ich würde sagen, für Ein-Mann-Projekte wäre es nützlich. Sobald Sie zwei erreichen, ist es von unschätzbarem Wert.

Ich bin damit einverstanden, dass Sie für Ein-Mann-Projekte, wenn Sie einen "One-Step-Build / Verify" -Projekt haben, mit der kontinuierlichen Integration einverstanden sind es in einem formalen System (CC, Hudson, TeamCity, etc.).

Die Frage, wann sich CI amortisiert, ist bei einem neuen Projekt nur schwer zu beantworten.

In einem vorhandenen Projekt ist es viel einfacher zu sehen. Wenn Sie einen kritischen Fehler in der Entwicklung der Lieferkette finden, wissen Sie, dass das Problem zum frühestmöglichen Zeitpunkt vorliegt. Die Kosten für das Reparieren sind jetzt die niedrigsten. Wenn dieses Problem in einer Umgebung auftritt, die über der Entwicklung liegt, sind Ihre Kosten höher.

Nun, das Management könnte beschließen, mit einem Fehler zu veröffentlichen, aber das ist ein Geschäftsrisiko. Zumindest kann dies jetzt durch diese Risikobewertung gemildert werden, anstatt durch spätabendliche Telefonate / Paniken, die, wenn sie zu Stundensätzen abgerechnet werden, sehr teuer werden.

Eine andere Sache, um in Bezug auf die Kosten zu berücksichtigen. Wie ist Ihre QS-Abteilung? Handelt es sich um manuelle Tests? Wenn Sie sich für CI entscheiden, können Sie möglicherweise die QA-Gesamtkosten senken, indem Sie diese Skripts für Ihre Entwicklungsbox automatisieren. Möglicherweise können Sie die Anzahl der QS-Mitarbeiter reduzieren, die Ihr Projekt unterstützen, indem Sie sie in die CI-Phase einbeziehen.

CI lohnt sich immer immer: Durch das Sicherheitsgefühl, das es Ihnen gibt, können Sie schneller arbeiten, als es sonst möglich wäre. Das Problem, das Sie haben, scheint sich um Unit-Tests zu drehen. Ich stimme zu, dass Unit-Tests sehr teuer sind, denke aber auch, dass sie (für viele Dinge) die am wenigsten schlimmste Option sind, die wir haben. Persönlich und für die Arten von Systemen, an denen ich tendenziell arbeite, schwöre ich auf Tests auf Systemebene, bei denen eine Kombination aus realen und (möglicherweise synthetischen) pathologischen Fällen angewendet wird. Es ist billiger als Unit-Tests und gelangt in die schwer zugänglichen Ecken Ihres konzeptionellen Universums: Donald Rumsfelds "Unknown Unknowns".

Verwenden Sie es immer, unabhängig von der Größe des Teams. Wenn es zum Beispiel nur Sie sind, wer weiß, könnten Sie bei Starbucks von Ihrem Laptop aus codieren und dann zu Hause von Ihrem stärkeren System aus fortfahren?

Der Aufwand ist wirklich nicht so schlimm.

Eins. Ja, man reicht aus, um mit der kontinuierlichen Integration zu beginnen.

Es geht nicht darum, wie viele Entwickler, sondern um

ein. Wie viel Zeit sparen Sie durch Automatisierung und wie oft.

• Zeitersparnis beim Erstellen nach Integrationen, Ausführen automatisierter Tests und Erstellen von Setups * Häufigkeit des Eincheckens = Zeitersparnis in Prozent.

b. Wie viele Versionen / Branchen / Produkte haben Sie?

• Wenn Sie einen Entwickler haben, der an zwei verschiedenen Zweigen arbeitet, verdoppelt sich die Zeitersparnis, da jeder Zweig gebaut, getestet und verpackt werden muss.