Diskussion:Kontinuierliche Integration

Kaputter Satz

CABIE – eine in Perl geschriebene Open-Source-Erstellungs- und Integrationsumgebung, die mit CVS, Subversion and Perforce ein Server für fortlaufende Integration, der Apache Maven und Apache Ant unterstützt

Der Satz scheint mir so zerrissen, dass ich den Inhalt nicht verstehe. Ich habe das Gefühl, dass nur einige Zeichen falsch sind, da ich aber inhaltlich nicht weiß, worum es geht, kann ich nicht aus einem 'der' ein 'die', einem 'ein' ein 'einen' oder so machen. Kann das bitte wer überprüfen, der den Text inhaltlich versteht? (nicht signierter Beitrag von 84.57.238.16 (Diskussion) 18:50, 7. Feb. 2009)

Sprachliche Fragen.

• "Kontinuierliche Integration (auch: fortlaufende oder permanente Integration, en. Continuous Integration) ist ein Begriff aus der Software-Entwicklung, der den Prozess des regelmäßigen, vollständigen Neubildens und Testens einer Anwendung beschreibt. Obwohl dieses Konzept älter ist, wird es häufig mit Extreme Programming in Verbindung gebracht." Worauf bitte bezieht sich "dieses Konzept", was also ist älter? In dieser Formulierung ist das nicht erkennbar.
• Das Lemma heisst zwar Kontinuierliche Integration aber im folgenden Artikeltext wird praktisch nur noch von "Permanente(r) Integration" gesprochen. Dass der Ausdruck PM in der deutschsprachigen Literatur verwendet wird, ist sicher nicht zu bestreiten - sprachlich ist dieses Konstrukt eher eine katastrophale Übersetzung, da permament dauerhaft, aber eben nicht fortlaufend/kontinuierlich heisst. An dieser Stelle sei nur ein abschreckendes Beispiel, beliebig ergooglet, zitiert: „Neue Komponenten werden permanent in das lauffähige Gesamtsystem integriert.“ heisst im Deutschen, dass Komponenten dauerhaft bzw. für immer in das System eingebaut werden, nicht abe rin einem kontinuierlichen Prozess. Was also spricht dagegen, auch im Artikeltext das Lemma Kontinuierliche Integration zu verwenden?

--Burkhard 20:40, 30. Apr. 2009 (CEST)

Continuous Integration mit Permanenter Integration zu übersetzen ist ziemlicher Schwachsinn. Als Alternative zu Kontinuierlicher Integration wäre Stetige Integration akzeptabel. Fortlaufende Integration hört sich für mich auch missverständlich an, da die jeweilige Integration nicht fortlaufend geschieht, sondern mit einem Mal abgeschlossen ist. (Der Unterschied liegt hier in der Konkretheit des Begriffes Integration, einmal als Oberbegriff, einmal als konkrete Integration. Wenn fortlaufend verwendet werden soll, dann müsste es genauer - aber dafür um so holpriger - lauten: Methode der Fortlaufenden Integrationen.) (nicht signierter Beitrag von 87.164.129.120 (Diskussion | Beiträge) 19:12, 27. Sep. 2009 (CEST))

Ich habe den Artikel entsprechend umgearbeitet, dass das Lemma korrekt referenziert wird und hoffentlich durch eine ordentliche Einleitung die Gesamtverständlichkeit verbessert. --Taxi1729 (Diskussion) 17:46, 3. Jul. 2013 (CEST)

?

Hierbei muss immer sorgfältig abgewogen werden ...

  und weniger relevante Tests nach die einzelnen Integrationen verschoben werden.

soll bedeuten:

  und weniger relevante Tests müssen verschoben werden, bis einzelne Integrationen abgeschlossen sind?

Oder wie genau? Ich habe technisch keine Ahnung aber der Satz klingt so, als ob jemand der/die sich auskennt, das in besser verständliches/korrekteres Deutsch umformulieren könnte.

Im Voraus besten Dank! (nicht signierter Beitrag von 84.56.240.42 (Diskussion | Beiträge) 20:49, 26. Jul 2009 (CEST))

Habe ich deutlicher formuliert. --Taxi1729 (Diskussion) 17:53, 3. Jul. 2013 (CEST)

Im jetzigen Zustand ist der Artikel schlecht - komplett neu schreiben oder löschen

Schon der Artikel-Name:"Kontinuierliche Integration" hat sich nicht eingebürgert. Continuous Integration heißt das, nach wie vor.

"Permanente Integration" ist irreführend.

Bei der CI wird auch nicht unbedingt vollständig getestet. Ein Nightly Build ist keine Alternative zu CI. Der Abschnitt "Vorteile" ist richtig: Ein erfahrener Entwickler kann sich denken, was gemeint ist.

Verweise zu Fowler sind sehr gut, aber ganz gelesen wurde der auch nicht. (nicht signierter Beitrag von Andreas Reif (Diskussion | Beiträge) 09:19, 26. Mär. 2010 (CET))

WP:Sei mutig und mach die von Dir vorgeschlagenen Verbesserungen - nur nörgeln hilf uns nichts. Der Artikel hat weit mehr zu bieten als die wenigen von Dir angemerkten Punkte (auch wenn Du mMn teilweise recht hast) - "komplett neu schreiben oder löschen" ist wohl etwas übertrieben. --Sebastian.Dietrich 15:47, 26. Mär. 2010 (CET)

Doch auch nörgeln kann mal helfen. Der Artikel ist in der Tat eine Katastrophe. Manche Abschnitte stimmen sicher, aber andere Teile sind auch einfach falsch und viele Punkte sind für Nicht-Entwickler komplett unverständlich (schon ich als Software Entwickler hatte Probleme manche Stellen zu verstehen). Die anderen Teile sind mehr oder weniger gut aneinandergereiht. Dann kommen so simple formale Anforderungen wie Listenpunkte entweder immer groß oder immer klein schreiben. Ganz ehrlich, der Artikel ist was für die QM, der Ersteller solle sich doch bitte ein paar Minuten Zeit nehmen und das gerade ziehen. 95.222.166.79 21:41, 31. Aug. 2010 (CEST)

Ok - wenn da so ist, dann lehnen wir uns doch alle am besten zurück und warten bis sich der Artikel von alleine ändert... "der Autor" der Wikipedia hätte auch wirklich besser arbeiten sollen ... Nörgeln hilft da auf jeden Fall... --Sebastian.Dietrich ✉ 22:14, 31. Aug. 2010 (CEST)

Werbeaussage oder inhaltliche Aussage ?

Zitat: "Die Einführung permanenter Integration oder ersatzweise eines täglichen Builds ist ein geeigneter Weg, die Qualität zu steigern." Was genau heißt "Qualität steigern" ?, ist das ein betriebswirtschaftlicher Begriff ?, oder ist das nur Geschwafel ? Der Satz will sicherlich etwas auf den Punkt bringen, aber ich verstehe grade nicht was genau. (nicht signierter Beitrag von 84.61.124.8 (Diskussion) 22:33, 23. Aug. 2011 (CEST))

Wenn du CI betreibst kann es dir nicht passieren, dass du 2 Wochen an einem Feature rumwerkelst und am Ende nichts mehr läuft. Das heißt Qualität steigern -- Phiarc 15:59, 26. Okt. 2011 (CEST)

Vorteile - und die Nachteile?

CI hat doch auch sicher Nachteile, auch wenn mir gerade keine Einfallen. So ist es jedenfalls etwas zu undifferenziert imho -- Phiarc 15:59, 26. Okt. 2011 (CEST)

Mir fallen auch keine ein - ausser das es anders ist als davor (und Menschen hassen üblicherweise jede Art von Veränderung) --Sebastian.Dietrich ✉ 17:21, 26. Okt. 2011 (CEST)

Nachteile:

• Einarbeitung in Tools und Methodik erforderlich. (Etwas mehr für den Buildmanager, etwas weniger für die Devs)
• Widerstand des Teams. (Was wollen denn die noch?)
• Ein Zuviel ist auch hier möglich. (Overtooling)

--Andreas Reif (Diskussion) 13:04, 31. Mai 2012 (CEST)

Naja - das sind aber keine spezifischen Nachteile von CI, sondern allgemeine Nachteile bei der Einführung irgendeines Tools. Dazu kommt noch "benötigt Ressourcen wie Speicher, CPU und IP-Adresse/Port". Würde ich aber nicht im Artikel erwähnen... --Sebastian.Dietrich ✉ 00:19, 1. Jun. 2012 (CEST)

Ein Nachteil ist, dass die Zeit, die für die Bearbeitung der durch CI entdeckten Mängel benötigt wird, nicht dazu genutzt werden kann, die eigentliche Entwicklung, etwa mit neuen Funktionen, voranzutreiben. Zwar wird der Code durch CI zukunftssicherer, z.B. sauberer oder leichter wartbar, keine Frage. Dass der Code aber sauber ist, ist idR kein Argument für die Benutzung eines bestimmten Produkts. Es wird schlicht erwartet, dass das Produkt funktioniert; wie es das hinbekommt, ist bestenfalls zweitrangig. Von einer Major-Version auf die nächste zu sagen, der Quellcode der Software sei jetzt auch ganz ordentlich, aber sonst sei alles gleich geblieben, ist - wenn überhaupt - dann ein denkbar schwaches Kaufargument. Das sind meist in erster Linie neue Features, die man mit CI nicht generiert. 88.130.68.57 (Diskussion) 23:35, 3. Jun. 2012 (CEST)

Da hast du recht, Qualität zieht selten als Verkaufsargument obwohl jeder weiss, dass ohne Qualität nicht mehr lange was zu verkaufen da ist bzw. die Weiterentwicklungs- und Wartungskosten explodieren. CI ist aber in erster Linie kein Werkzeug um Qualität sicherzustellen, sondern nur um die - für die Software notwendige - Integration sicherzustellen. CI ist nur die konsequente Fortsetzung von Release-Integration -> monatliche -> wöchentliche -> tägliche Integration. Laufende Integration benötigt (wegen des schnelleren Feedbacks) wesentlich weniger Aufwand als herkömmliche Integration. --Sebastian.Dietrich ✉ 00:48, 4. Jun. 2012 (CEST)

Apropos explodierende Wartungskosten: IdR erhofft man sich von der Einführung von CI ja sinkende Kosten und ersparte Zeit. Langfristig sind diese Effekte auch gegeben. Auf kurze Sicht erreicht man aber oft das genaue Gegenteil: Die Infrastruktur muss installiert und konfiguriert werden. Die Mitarbeiter müssen mit den entsprechenden Tools geschult werden. Es entsteht eine ganz neue Ebene an Komplexität. Auch der Zeitplan kann daher nicht unmittelbar verkürzt werden. Auch muss man aufpassen, was die Erwartungshaltung bzgl. der Automatisierbarkeit angeht: Zwar ist es so, dass man mit steigender Nutzungsdauer "einfache" Testaufgaben gut automatisieren kann; die (teure) Arbeitszeit der Entwickler kann man dann eher auf komplexere Aufgaben konzentrieren. Aber nur weil man irgendein CI-Werkzeug nutzt, heißt das noch lange nicht, dass man die gesamte Testarbeit automatisieren könnte (eine immer noch verbreitete Fehlvorstellung). Abgesehen davon fallen "Meta-Kosten" dafür an, dass man die CI-Tools wartet und immer wieder anpasst. Diesen Zeitaufwand und diese Kosten hätte man ohne CI natürlich auch nicht. Ich hab das im Artikel ergänzt. 88.130.94.190 (Diskussion) 23:29, 4. Jun. 2012 (CEST)

Sehe ich nicht so. Ja die Infrastruktur muss installiert und konfiguriert werden. Das dauert meiner Erfahrung nach kürzer, als ein einziges mal eine händische Integration der einzelnen Komponenten zu machen. Der Zeitplan wird daher meiner Erfahrung nach unmittelbar verkürzt.

Klar die Mitarbeiter müssen geschult werden - das dauert bei den Tools die ich kenne (Hudson, Jenkins) wenige Sekunden, da die Tools trivial zu bedienen sind & "die Mitarbeiter" nur zwischen rot und grün/blau unterscheiden können müssen & über welchen Klick sie auf für sie bekannte Buildlogs kommen. Nicht alle Mitarbeiter müssen wissen wie sie Builds einrichten & konfigurieren können, aber auch das ist selbsterklärend und dauert nur wenige Minuten bis man es kapiert.

@Testaufgaben - Klar dauert es enorm viel Zeit bis manuelle Tests in automatisierte Tests umgewandelt werden. Ist aber nicht Aufgabe eines CI Werkzeuges und somit hier nicht zu berücksichtigen.

Das einzige was CI macht ist Integration kontinuierlich zu machen. Es geht weder um Testautomatisierung, noch um Buildautomatisierung. Einen bestehenden (automatisierten) Build kontinuierlich auszuführen ist in nur wenigen Schritten machbar.

P.S. der Artikel (& auch die Vorteile von CI) muss aber noch korrigiert werden. Es stimmt z.B. nicht dass CI das vollständige Neubilden und Testen beschreibt. --Sebastian.Dietrich ✉ 13:29, 6. Jun. 2012 (CEST)

Dieser Artikel ist komplett unbrauchbar...

...und sollte deshalb komplett neu geschrieben werden!

Zum Beispiel habe ich den Begriff "Neubilden" im Zusammenhang mit dem Build einer Anwendung/eines Anwendungssystems noch nie gehört und den gibt es auch nicht. Es exisitieren in diesem Zusammenhang die Begriffe "Build" oder "Bauen", welche die Neuübersetzung von Quellcode und eventuell das Linken des Objectcodes gegen Bibliotheken beschreiben, aber mit etwas "bilden" hat das Ganze nichts zu tun. (nicht signierter Beitrag von 193.111.217.134 (Diskussion) 17:42, 6. Jun. 2012 (CEST))

Schwachsinn - natürlich ist der Artikel brauchbar, wenngleich verbesserungswürdig. Den von dir angemerkten Punkt hast du ja bereits ausgebessert. Sei konstruktuv und merke weitere Punkte an und verbessere sie... --Sebastian.Dietrich ✉ 23:25, 6. Jun. 2012 (CEST)

Entfernung zweier Absätze

Für den folgenden Absatz fehlt es an jeglicher Grundlage. Technische ist es möglich ein CIS sogar auf einem Entwicklungsrechner aufzusetzen z.B. um einen Clean-Build durchzuführen. Wenn die passende Studie mir gezeigt wird OK aber so...

   Auch wenn Systeme wie CruiseControl, Jenkins, Hudson 
   oder Anthill es sehr viel leichter machen, eine permanente Integration umzusetzen, so ist doch in 
   vielen Unternehmen und Projekten keine Umgebung vorhanden, die ein solches Arbeiten unterstützt.

Als Alternative wird der Nightly Build (warum nicht Daily Build - Begriff ist genauso verbreitet) benannt. Die Beschreibung ist aber letztendlich nichts anderes als ein minimaler CI-Prozess. Es handelt sich hier nicht um gegensätzliche Vorgehensmodelle sondern ergänzende bzw. aufeinander aufbauende Konzepte.

   Die einfachere Alternative – und häufig die Vorstufe zur permanenten Integration – ist der [[Nightly 
   Build]] (nächtlicher Erstellungsprozess), bei dem jede Nacht die aktuellen Versionen aus dem 
   Versionsverwaltungssystem geholt werden und auf diesem Stand ein Gesamtsystem gebaut wird. Sofern 
   möglich, wird auch noch eine Installation in der Zielumgebung vorgenommen (Deployment) und ein Minimaltest
   (Anschalttest, vgl. Smoke testing) durchgeführt. (nicht signierter Beitrag von Bastie (Diskussion | Beiträge) 14:34, 7. Jun. 2012 (CEST)) 

Wenn du alles löschst, was verbesserungswürdig ist, dann ist der Artikel bald leer. Die Absätze formuliere ich gleich mal um, dass sie korrekter sind. Das nächste mal mach du das bitte... --Sebastian.Dietrich ✉

Jetzt ist wieder die komplette Bescheibung des Nightly Build drin, der hier nicht rein gehört. Das Löschen war nicht wahlfrei, weil verbesserungswürdig sondern zielgerichtet da nicht zu dem Thema gehörend. Zu dem gelöschten ersten Absatz hast du zudem gar keine Aussage getroffen sondern einfach wieder aufgenommen ohne einen Nachweis hierfür zu erbringen. So wird der Artikel auch nicht besser :( --Bastie (Diskussion) 11:07, 18. Jun. 2012 (CEST)

Ähm - deine "Verbesserung" besagt jetzt zwar, dass beide Systeme unterschiedliche Vorteile haben, aber welche Unterschiede (oder Vorteile) sie haben hast gelöscht. Schlecht so. --Sebastian.Dietrich ✉ 22:07, 20. Jun. 2012 (CEST)

Weitere Tools

Ich schlage vor die Tools Finalbuilder und Continua CI von VSoft Technologies als weitere Tools hinzuzufügen. Dabei ist Continua CI der Nachfolger von Finalbuilder. (nicht signierter Beitrag von 198.90.66.177 (Diskussion) 09:33, 22. Aug. 2013 (CEST))

WP:Sei mutig und füge sie hinzu. --Sebastian.Dietrich ✉ 13:23, 22. Aug. 2013 (CEST)

Transformation von Software-Liste in Tabelle

Ist eine Transformation der Software-Liste in eine Tabelle mit Lizenzen und Kompatibilität mit Linux, Mac OS und Windows ok? Zgh (Diskussion) 12:35, 27. Apr. 2015 (CEST)

Ja, mach. Das ist eine gute Idee. --37.209.88.14 22:21, 8. Jul. 2019 (CEST)

Software

Kann man den Abschnitt "Software" nicht in eine Tabelle fassen, damit man besser vergleichen kann, welche Features welche CI Software hat? So wie es momentan ist, wird der gleiche Text mehrmals kopiert. Diese Duplikate könnte man mit einer einfachen Tabelle reduzieren und man hätte einen bessere Überblick. --37.209.88.14 22:21, 8. Jul. 2019 (CEST)

Vielleicht, ja. Was würdest du denn für Kriterien (Spalten) nehmen, die auch bei allen Softwareprodukten Sinn machen? So viele Details stehen in dem Artikel nämlich nicht über die einzelnen Produkte. --rugk (Diskussion) 23:21, 9. Jul. 2019 (CEST)