Ich bin die meiste Zeit ein Einzelentwickler und arbeite an einer Reihe großer, hauptsächlich PHP-basierter Projekte. Ich möchte den Umgang mit Änderungen an der Codebasis professionalisieren und automatisieren und einen kontinuierlichen Integrationsprozess erstellen, der den Übergang zur Arbeit in einem Team ermöglicht, ohne dass grundlegende Änderungen vorgenommen werden müssen.

Was ich gerade mache, ist, dass ich für jedes Projekt eine lokale Testumgebung habe. Ich benutze SVN für jedes Projekt; Änderungen werden lokal getestet und dann in der Regel per FTP in die Online-Version übertragen. Die API-Dokumentation wird manuell aus dem Quellcode generiert. Unit-Tests sind etwas, auf das ich mich langsam einlasse, und es ist noch nicht Teil meiner täglichen Routine.

Der "Build-Zyklus", den ich mir vorstelle, würde Folgendes bewirken:

• Ein Änderungssatz wird in SVN eingecheckt, nachdem er lokal getestet wurde.

• Ich starte den Build-Prozess. Die SVN HEAD-Revision wird ausgecheckt, bei Bedarf geändert und zum Hochladen vorbereitet.

• Die API-Dokumentation wird automatisch generiert. Wenn ich sie noch nicht im Detail eingerichtet habe, scanne ich mithilfe einer Standardvorlage die gesamte Codebasis.

• Die neue Version wird über FTP am Remotestandort bereitgestellt (einschließlich einiger Umbenennungen von Verzeichnissen, Chmodding, Importieren von Datenbanken und dergleichen). Dies ist etwas, das ich bereits sehr mag , aber ich bin natürlich offen für Alternativen.

• Unit-Tests an einem vordefinierten Ort werden ausgeführt. Ich werde über E-Mail, RSS oder (vorzugsweise) HTML-Ausgabe, die ich abrufen und in eine Webseite einfügen kann, über deren Misserfolg oder Erfolg informiert.

• (optional) Eine Endbenutzer-Textdatei "Changelog" an einem vordefinierten Speicherort wird mit einem vordefinierten Teil der Festschreibungsnachricht aktualisiert ("Es ist jetzt möglich, gleichzeitig nach" foo "und" bar "zu filtern Zeit). Diese Nachricht ist nicht unbedingt identisch mit der SVN-Festschreibungsnachricht, die wahrscheinlich viel mehr interne Informationen enthält.

• Dinge wie Codemetriken, Überprüfung des Codestils usw. sind momentan nicht mein Hauptaugenmerk, aber auf lange Sicht werden sie es sicherlich. Lösungen, die dies sofort einsatzbereit machen, werden sehr freundlich geprüft.

ich suche nach

• Feedback und Erfahrungen von Menschen, die sich in einer ähnlichen Situation befinden oder befanden und eine Lösung dafür erfolgreich implementiert haben

• Insbesondere gute Schritt-für-Schritt-Anleitungen und Anleitungen zum Einrichten

• Lösungen, die so viel Automatisierung wie möglich bieten , z. B. durch Erstellen einer Skelett-API, von Testfällen usw. für jedes neue Projekt.

und auch

• Produktempfehlungen . Was ich bisher weiß, ist Phing / Ant für das Bauen und PhpUnderControl oder Hudson für den Berichtsteil. Ich mag sie alle, soweit ich sehen kann, aber ich habe natürlich keine detaillierten Erfahrungen mit ihnen.

Ich bin mit Arbeit überfüllt , daher neige ich stark zu einfachen Lösungen. Wenn andererseits eine Funktion fehlt, werde ich darüber weinen, dass sie zu begrenzt ist. :) Point-and-Click-Lösungen sind ebenfalls willkommen. Ich bin auch auf kommerzielle Produktempfehlungen, die mit PHP-Projekten arbeiten können.

Mein Setup

Ich arbeite lokal unter Windows (7, um genau zu sein) und die meisten Client-Projekte werden auf einem LAMP-Stack ausgeführt, häufig auf Shared Hosting (= kein Remote-SSH). Ich suche nach Lösungen, die ich in meiner eigenen Umgebung ausführen kann. Ich bin bereit, eine Linux-VM dafür einzurichten, kein Problem. Gehostete Lösungen sind für mich nur dann interessant, wenn sie alle beschriebenen Aspekte bieten oder flexibel genug sind, um mit den anderen Teilen des Prozesses zu interagieren.

Kopfgeld Ich akzeptiere die Antwort, von der ich glaube, dass sie mir die meisten Kilometer bringt. Hier gibt es viele hervorragende Beiträge. Ich wünschte, ich könnte mehr als eine Antwort akzeptieren. Vielen Dank an alle!

Ich habe Buildbot , CruiseControl.net , CruiseControl und Hudson durchlaufen . Obwohl mir CruiseControl * sehr gut gefallen hat, war es mit zu komplexen Abhängigkeitsfällen einfach zu mühsam. Buildbot ist nicht einfach einzurichten, hat aber eine schöne Ausstrahlung (ich mag Python, das ist alles). Aber Hudson gewann die ersten drei, weil:

1. Es ist einfach einzurichten
2. Es ist einfach anzupassen
3. Es sieht gut aus und hat eine schöne Übersichtsfunktionalität
4. Es erhielt Point-and-Click-Updates für sich und alle installierten Plugins. Dies ist eine wirklich schöne Funktion, die ich immer mehr schätze

Vorsichtsmaßnahme: Ich habe immer nur Linux als Basis für die oben genannten Build-Server verwendet (CC.net lief auf Mono ), aber alle sollten - laut Dokumentation - plattformübergreifend ausgeführt werden.

Einrichten eines Hudson-Servers

Voraussetzungen:

• Java (1.5 wird Ihnen gut dienen)
• Lesezugriff auf den Subversion-Server (Ich habe ein separates Konto für den Hudson-Benutzer)

Von hier aus ist es nur:

java -jar hudson.war

Dadurch wird eine kleine Serverinstanz direkt von Ihrer Konsole ausgeführt, und Sie sollten in der Lage sein, die Installation auf Ihrer zu durchsuchen http://localhost:8080, wenn auf diesem Port im Voraus nichts anderes ausgeführt wird (Sie können einen anderen Port angeben, indem Sie die --httpPort=ANOTHER_HTTP_PORTOption an übergeben oben Befehl) und alles lief gut in der 'Installation'.

Wenn Sie in das verfügbare Plugins-Verzeichnis ( http://localhost:8080/pluginManager/available) wechseln, finden Sie Plugins zur Unterstützung Ihrer oben genannten Aufgaben (die Subversion-Unterstützung ist standardmäßig installiert).

Wenn das Appetit macht, sollten Sie einen Java-Anwendungsserver wie Tomcat oder Jetty installieren . Installationsanweisungen sind für alle wichtigen Anwendungsserver verfügbar

Update : Kohsuke Kawaguchi hat ein Windows-Service-Installationsprogramm für Hudson erstellt

Ein Projekt in Hudson einrichten

Die Links in der folgenden Anleitung setzen eine laufende Instanz von Hudson unter voraus http://localhost:8080

1. Wählen Sie http://localhost:8080/view/All/newJobim Menü links die Option Neuer Job ( )
2. Geben Sie dem Job einen Namen und kreuzen Sie Build a free-style software projectdie Liste an
3. Durch Drücken von 'OK' gelangen Sie zur Konfigurationsseite des Jobs. Alle Optionen haben ein kleines Fragezeichen. Durch Drücken dieser Taste wird ein Hilfetext zur Option angezeigt.
4. Unter der Optionsgruppe 'Quellcodeverwaltung' würden Sie Subversion verwenden. Hudson akzeptiert sowohl den URL-Zugriff als auch den lokalen Modulzugriff
5. Unter der Optionsgruppe 'Build Triggers' würden Sie 'Poll SCM' verwenden. Die hier verwendete Syntax ist die von cron, daher wird das Subversion-Repository alle 5 Minuten abgefragt*/5 * * * *
6. Der Prozess des Erstellens des Projekts wird unter der Optionsgruppe 'Erstellen' angegeben. Wenn Sie bereits eine Ameisen-Build-Datei mit allen benötigten Zielen haben, haben Sie Glück. Wählen Sie einfach "Ameise aufrufen" und schreiben Sie den Namen des Ziels. Die Optionsgruppe unterstützt sofort Maven- und Shell-Befehle, es steht jedoch auch ein Plugin für Phing zur Verfügung .
7. Kreuzen Sie zusätzliche Build-Aktionen in "Post-Build-Aktionen" an, z. B. E-Mail-Benachrichtigungen oder Archivierung von Build-Artefakten.

Zum Einrichten von Prozessen, für die Hudson keine Plugins hat, können Sie diese entweder direkt über ein Shell-Skript im Build-Setup aufrufen oder ein eigenes Plugin schreiben

Tücken:

• Wenn Sie Build-Artefakte produzieren lassen, denken Sie daran, dass Hudson in regelmäßigen Abständen nach sich selbst aufräumt.
• Wenn Sie mehr als 20 Projekte einrichten, sollten Sie nicht ihren Baustatus als Standard - Haupt-Seite auf hudson Anzeige

Viel Glück!

Der Begriff, den Sie suchen, ist "kontinuierliche Integration".

Hier ist ein Beispiel für jemanden, der GIT + phpundercontrol verwendet: http://maff.ailoo.net/2009/09/continuous-integration-phpundercontrol-git/

CruiseControl (ein CI-Server) kann Hosted SVN / GIT als Quelle verwenden. Sie können es also sogar mit GitHub oder Beanstalk oder etwas anderem verwenden.

Dann können Sie das in die folgende Art von Software integrieren:

• PHPUnit
• PHP-Codesniffer
• phpdocumentor
• PHP Gcov
• PHPXref
• Yasca
• etc.

Sie können auch dieses gehostete CI ausprobieren: http://www.php-ci.net/hosting/create-project

Beachten Sie jedoch, dass diese Tools benutzerdefinierte Unterstützung benötigen, wenn Sie sie selbst integrieren.

Haben Sie auch über Projektmanagement und Patch-Management nachgedacht?

Sie können Redmine für das Projektmanagement verwenden. Es hat eine kontinuierliche Integrationsunterstützung integriert, jedoch nur als Client (nicht als CI-Server).

Versuchen Sie es mit einem gehosteten SVN / GIT / etc. Lösung, da sie Ihre Backups abdecken und ihre Server am Laufen halten, sodass Sie sich auf die Entwicklung konzentrieren können.

Ein Tutorial zum Einrichten von Hudson finden Sie unter: http://toptopic.wordpress.com/2009/02/26/php-and-hudson/

Ich benutze Atlassian Bamboo Kontinuierliche Integration Server für mein Haupt-PHP - Projekt (zusammen mit ihren anderen Produkten wie Fisheye (Repository - Browsing), jira (Issue Tracker) und Klee (Code Coverage)).

Es unterstützt SVN und unterstützt jetzt Git und hat eine großartige Benutzeroberfläche. Es ist für Linux, Windows und Mac verfügbar und kann eigenständig auf einem eigenen Tomcat-Server ausgeführt werden. Dies ist ideal für Leute (wie mich), die nicht gerne Tage brauchen, um ihre Tools einzurichten. Obwohl es teuer aussehen mag, habe ich als Einzelentwickler die Starter-Kit-Lizenz für 10 $ (10 $ per Software) gekauft. Dies ist großartig für kleine Teams und es ist einen Blick wert.

PHPTesting PHPCI Dies ist ein schöner, kontinuierlicher Integrationsserver, der in PHP integriert ist.

Plus, es ist kostenlos und Open Source. :) :)

es hat Anzahl von Plugins ..

PHPCI enthält Integrations-Plugins für:

• Atoum
• Behat
• Lagerfeuer
• Codeception
• Komponist
• Email
• Grunzen
• IRC
• PHP
• Fussel
• MySQL
• PDepend
• PostgreSQL
• PHP Code Sniffer
• PHP Copy / Paste Detector
• PHP Spec
• PHP-Einheit
• Shell-Befehle
• Teer / Reißverschluss

Ich bin meistens ein Systemadministrator, aber manchmal codiere ich auch PHP. Als Nebenprojekt habe ich einige Skripte erstellt, die es einfach und problemlos machen, mit Jenkins eine vollständige PHP-CI-Umgebung einzurichten. Außerdem wird ein Beispielprojekt für Sie ausgeführt, damit Sie sehen können, wie die einzelnen Erstellungsschritte konfiguriert sind.

Wenn Sie es ausprobieren möchten, benötigen Sie lediglich eine Debian / Ubuntu-Box und einen Shell-Zugriff.

http://yauh.de/articles/379/setting-up-a-ci-environment-for-php-projects-using-jenkins-ci

Update So fügen Sie meiner Antwort einige Inhalte hinzu:

Sie können einfach ein Jenkins CI für PHP mit Ansible einrichten. Seit v1.4 werden Rollen unterstützt, die Sie von der Community-Site galaxy.ansibleworks.com herunterladen können, und es wird das schwere Heben für Sie erledigen. Es heißt Jenkins-PHP .

Ich würde vorschlagen, Jenkins http://jenkins-ci.org/ zu verwenden. Es ist kostenlos und Open Source.

Die Einrichtung ist ziemlich einfach, funktioniert auf mehreren Plattformen und lässt sich gut in andere Tools für die kontinuierliche Integration wie SonarQube (+ SQUALE) integrieren, um die technische Verschuldung und Thukydides zum Testen der Automatisierung zu messen.

Ich würde dringend empfehlen, GIT oder GIT Hub für die Versionskontrolle anstelle von SVN zu verwenden. Aus meiner Sicht ist es nur ein besseres Versionskontrollsystem, mit dem Sie Ihre Entwicklungsbemühungen später skalieren können.

Da Sie hauptsächlich mit PHP-Projekten arbeiten, können Sie einige andere Tools verwenden.

PHPUnit - Für Unit-Tests

PHP CodeSniffer - Auf Codierungsstandards prüfen

PHP-Abhängigkeit - Zeigt Ihre PHP-Code-Abhängigkeiten an

XDEBUG - Zum Testen der Leistung

Alle diese Tools werden mit einem Jenkins-Job ausgelöst und helfen bei der Qualität und Leistung Ihres Codes.

Viel Glück und viel Spaß!

Ich verwende nicht viele der Produkte oder sogar Arten von Produkten, die Sie verwenden, aber ich werde Ihnen meine Erfahrung geben.

Ich führe eine TEST-Umgebung parallel zu meiner PROD-Umgebung aus. Ich habe keine lokalen Tests an sich. Wenn es zu schwierig ist, sich in eine echte TEST-Umgebung hineinzuversetzen, behebe ich meinen Erstellungsprozess. Ich sehe keinen Sinn darin, lokal zu testen, da die Umgebungen unterschiedlich sind. UPDATE: Das einzige, was ich lokal mache, ist "php -l" auszuführen, bevor ich etwas hochlade. Stoppt die dummen Fehler.

Der Erstellungsprozess funktioniert mit allem, was sich im aktuellen Arbeitsbereich befindet, einschließlich nicht festgeschriebenem Code. Dies ist nicht jedermanns Sache, aber ich werde sehr oft testen. Alles wird festgelegt, bevor Sie zu PROD gehen.

Ein Teil meines Erstellungsprozesses (ähnlich wie bei Ihnen) erstellt zwei META-Dateien. Eine enthält die letzten (normalerweise) 100 Änderungen und gibt mir auch die aktuelle Änderungslistennummer. Das zeigt mir, welche Änderungen installiert sind. Die andere enthält die CLIENTSPEC (in Perforce-Begriffen), die mir genau zeigt, welche Zweige in diesem Build verwendet wurden. Zusammen geben mir diese reproduzierbare Builds.

Ich baue nicht direkt auf die Zielumgebung, sondern auf einen Staging-Bereich auf dem Server. Ich benutze SSH, also macht das Sinn. Dies gibt mir einige Vorteile. Am wichtigsten ist, dass es vermieden wird, auf halbem Weg durch einen großen Upload zu sterben. Es gibt mir auch einen Platz zum Speichern von META-Dateien, und alle Build-Dateien werden automatisch archiviert (so kann ich direkt zu jedem Build zurückkehren). Das Skript protokolliert auch das Update (es gibt also einen Eintrag im Protokolldatenstrom und ich kann Pre- und Post- sehen) und tritt alle Daemons aus (ich verwende Daemontools, also "svc -t"). All dies ist auf dem Zielcomputer besser geeignet.

Ein weiteres Problem sind DB-Änderungen. Ich behalte ein Masterskript des DB-Schemas, das ich jedes Mal aktualisiere, wenn sich das Schema ändert. Jede der Änderungen wird auch in ein Skript "changes.sql" übernommen, das mit dem Build in den Staging-Bereich hochgeladen wird. Das Skript wird als Teil des Installationsskripts ausgeführt.

Ich habe vor kurzem den gleichen Prozess begonnen und verwende Beanstalk für das SVN-Hosting.

Es gibt zwei raffinierte Funktionen in den bezahlten Konten (ich glaube, ab 15 Uhr):

• Durch die Bereitstellung kann der Benutzer FTP-Ziele für Staging- und Produktionsserver erstellen, die auf Knopfdruck bereitgestellt werden können (einschließlich Angabe einer Revision und eines Zweigs).
• Mit Webhooks kann der Benutzer eine URL einrichten, die bei jedem Commit / Deployment aufgerufen wird und über Dinge wie Versionsnummer, Beschreibung und Benutzer hinweggeht. Dies kann verwendet werden, um Dokumente zu aktualisieren, Komponententests auszuführen und Änderungsprotokolle zu aktualisieren.

Ich bin mir sicher, dass es andere gehostete oder selbsthostende SVN-Server mit diesen beiden Funktionen gibt, aber Beanstalk ist derjenige, mit dem ich Erfahrung habe, und er funktioniert sehr, sehr gut

Es gibt auch eine API, mit der ich mir vorstellen kann, die Bereitstellung weiter in Ihren Prozess zu integrieren.

Betrachten Sie fazend.com , eine kostenlose gehostete CI-Plattform, die Konfigurations- und Installationsvorgänge automatisiert. Sie müssen keine Versionskontrolle, Fehlerverfolgung, CI-Server, Testumgebung usw. einrichten. Alles wird bei Bedarf erledigt.