Ich bin kürzlich zu einem Start-up-Unternehmen gewechselt, das eine Website für soziale Netzwerke anbietet. In meiner neuen Organisation sind wir ein kleines Team von 8 Entwicklern/Designern.
Ich habe viel über kontinuierliche Integration gehört (z. B. Husdon/Jenkins), aber nie versucht, besser gesagt, nie gebraucht. Bei uns funktioniert mentis bisher einwandfrei.
Als Manager (ahh, meine erste Aufgabe als Manager) muss ich kontinuierlich Prozesse für eine bessere Effizienz vorschlagen, ohne die Aufgaben des Entwicklers zu verkomplizieren. Ich bin mir jedoch nicht 100 % sicher, ob ich CI für meine Organisation vorschlagen sollte, da ich nicht viel über CI weiß. Ich möchte keine besseren oder effizienteren Wege der Softwareentwicklung missen, aber gleichzeitig möchte ich den Prozess nicht nur um seiner selbst willen verändern.
Kann jemand bitte darauf hinweisen, ob die Verwendung von CI-Tools wie Hudson/Jenkins für ein kleines Team, das bereits einen Arbeitsprozess hat, von Vorteil ist? Wenn ja, welche Vorteile erhalten wir für diesen Wechsel? Lohnt es sich angesichts der Teamgröße, meine Zeit zu investieren, um zuerst CI-Tools zu lernen/auszuprobieren?
Bearbeiten
Es tut uns leid, dass ein erforderlicher Kontext fehlt. Aktueller Arbeitsablauf: Unser Produkt basiert auf Symfony 1.4, wir verwenden Mentis- und Symfony-Konsolentools für Builds. Für jede Release-Version erstellen wir nach manuellen Tests SVN-Tags und aktualisieren den Server mit SVN-Tags.
Ich leitete ein Team von fünf Entwicklern und wir begannen mit CI unter Verwendung von CruiseControl. Es fällt mir schwer, mir eine Situation vorzustellen, in der mehr als ein Entwickler involviert ist, in der es nicht vorteilhaft wäre, CI zu machen. Hudson/Jenkins ist eine gute Plattform, auf die wir später umgestiegen sind.
Außerdem bekommen Sie VIEL mehr für Ihr Geld, wenn Sie CI gegen ein Build-System durchführen, das bei jedem Build automatisierte Regressionstests durchführt. Ich würde sehr empfehlen, dass Sie Unit-Tests und allgemeine Regressionstests als Ergebnisse für jedes Feature, das Sie implementieren, einbeziehen. Es dauert zunächst länger, aber Sie können später im Prozess viel schneller arbeiten und nachts gut schlafen, da Sie wissen, dass die Qualität Ihres Produkts nicht beeinträchtigt wird.
An einem Punkt in unserem Produkt hatten wir über 7.000 Regressionstests, die bei jedem Build ausgeführt wurden. Unser Produkt brauchte 20-30 Minuten zum Bauen und 5 Stunden zum Testen. Diese Tests wurden alle während der Entwicklung des Produkts durchgeführt und es war ein Aspekt des Projekts, mit dem ich am zufriedensten war.
Hudson/Jenkins hat ein sehr starkes Regressionstest-Dashboard. Stellen Sie eine Regel auf, dass niemand mit seiner Feature-Arbeit fertig ist, bis sein Code im Build-Prozess erstellt wird und alle Tests bestanden sind. Nachdem Sie den Server eingerichtet haben und die Leute ihn ein paar Wochen lang benutzt haben, werden Sie nicht einmal daran denken, darauf zu verzichten.
Während die Frage, wie sie ursprünglich gestellt wurde, nicht wirklich ideal zu dieser Seite passt (z. B. geht es mehr um die Entwicklungspraxis als um das Verwalten von Projekten), ist sie dennoch eine nützliche Frage, wenn sie richtig formuliert ist.
Aus Sicht des Projektmanagements erfordern reale Projekte typischerweise (unter anderem):
Continuous Integration erfüllt diese Rolle automatisiert, muss also nicht explizit verwaltet werden. Dies schafft im Laufe der Zeit häufig Effizienzsteigerungen für das Projekt. Aus Sicht eines Projektmanagers kann dies auch bedeuten, dass weniger Fehler lange genug unbemerkt bleiben, um die Gesamtprojektschätzungen oder Veröffentlichungsdaten negativ zu beeinflussen.
Geht das ohne CI? Sicher. Aber wenn Sie auch nur zwei Entwickler in Ihrem Team haben, dann wird es auch Integrationsarbeit geben (Sie haben die Feature-Integration in Ihrem Projektplan geplant, nicht wahr?), die automatisiert werden kann und sollte.
Aus Sicht des Projektmanagements bedeuten häufige Integrationstests weniger Integrations-Todesmärsche am Ende eines Projekts. Meiner Erfahrung nach neigt jedes große Projekt ohne automatisierte Integrationstests dazu, seinen Zeitplan zu sprengen, da der Aufwand und die Komplexität manueller Integrationstests mit der Zeit wachsen – und wenn es bis zum Ende des Projekts bleibt, werden Sie es nicht schaffen um den Aufwand genau abzuschätzen.
Ein weiterer Zweck von CI ist die Verwendung als Informations-Dashboard. Ein gutes CI-System mit sowohl effektiven Tests als auch ausreichender Codeabdeckung wird den Status des Projekts schnell an alle Interessierten übermitteln. CI wird niemandem mitteilen, welche Funktionen in der Codebasis verfügbar sind, aber ein grünes Dashboard wird den Beteiligten mit Sicherheit mitteilen, dass alle vorhandenen und getesteten Funktionen zur Auslieferung bereit sind.
Natürlich kann das CI-Dashboard wie jedes andere Tool oder jede Projektmanagementtechnik missbraucht werden. Beispielsweise verstößt das Herausnehmen fehlgeschlagener Tests, nur um das Dashboard "grüner" zu machen, gegen die Prinzipien effektiver Kommunikation und Transparenz, die alle Projektmanager anstreben sollten, aber ich habe gesehen, dass dies aus politischen Gründen und durch organisatorische Funktionsstörungen geschah.
Als Projektmanager ist die Kommunikation des Projektstatus äußerst wichtig. Wenn ein Teil dieser Kommunikation automatisiert werden kann, stellt dies eine Projekteffizienz dar, die normalerweise einen messbaren Mehrwert bringt.
Während CI aus technischer Sicht nützlich ist, kann es auch nützlich sein, um Effizienzen zu schaffen und die Kommunikation innerhalb eines Projektmanagement-Frameworks zu verbessern. Wenn Ihr Projekt nicht wirklich trivial ist, ist die Vermeidung des Overheads der Automatisierung von Tests normalerweise eine falsche Sparsamkeit.
Ich bin dem Risiko von Ablehnungen ausgesetzt, aber ich glaube nicht, dass Sie in diesem Projekt kontinuierliche Integration benötigen . Es ist gut, dass Sie es sich vor der Einführung ansehen, aber es wäre auch gut zu wissen, ob Ihre Organisation es überhaupt braucht – zuerst nachfragen, dann liefern .
Continuous Integration ist gut geeignet, um Probleme zu finden, die auftreten, weil gleichzeitig an derselben Codebasis gearbeitet wird, wie z. B. Build-Probleme, Regressionstests und mögliche Bereitstellungsprobleme (es handelt sich eher um Continuous Deployment). Wenn Ihre Organisation ohne größere Probleme parallel entwickeln und testen kann, bringt die kontinuierliche Integration keinen Wert.
Außerdem haben Continuous-Integration-Systeme am Anfang einen gewissen kontinuierlichen Wartungsaufwand. Ich spreche nicht davon, das Tool zu aktualisieren, sondern mich um fehlgeschlagene Builds zu kümmern, um es schneller und reaktionsschneller zu machen. Wenn das Team daran wenig Interesse hat, also nicht von dem System profitiert , wird es langsam sterben .
Wenn Sie es trotzdem in Ihrem Projekt verwenden möchten, führen Sie vor der Einführung eine Demo durch oder beauftragen Sie einen guten Experten, der die Vorteile aufzeigen und die Idee hinter Continuous Integration erklären kann (wenn er oder sie mit den Tools beginnt, dann suchen Sie sich jemand anderen).
Kleine Teams, wenn auch die Codebasis klein ist, können ohne CI auskommen, da ihre Testsuite so wenig Zeit zum Ausführen benötigt (wahrscheinlich nur 3-10 Minuten).
Die wirklichen Stärken von CI zeigen sich, wenn entweder:
jmort253
Kapil Sharma