2010-03-08 5 views
5

Ich bin dabei, die Entwicklungsumgebung (PHP/MySQL) für mein Startup einzurichten. Wir verwenden drei Gruppen von Servern:Einrichten eines effizienten und effektiven Entwicklungsprozesses

, LIVE - die Server, die der tatsächlichen Anwendung TEST bieten - eine Testversion bereitstellt, bevor es tatsächlich DEV freigegeben wird - den Entwicklungsserver

Die Entwicklungsserver mit jedem Entwickler SVN liefen Auschecken ihrer lokalen Kopie. Am Ende eines jeden Tages werden abgeschlossene Fixes eingecheckt und dann verwenden wir Hudson, um unseren Build-Prozess zu automatisieren und dann auf TEST zu übertragen. Wir überprüfen dann, ob die Anwendung mit einem Tester noch ordnungsgemäß funktioniert, und wenn alles in Ordnung ist, verschieben Sie sie auf LIVE. Ich bin mit diesem Prozess zufrieden, aber ich habe zwei Fragen:

  • Wie würden Sie tun wir lokale Tests empfehlen - wie jeder Entwickler neue Seiten oder Änderungen Funktionalität hinzufügt ich sie möchte in der Lage zu testen, was sie tun . Würden Sie einfach lokalen Apache und eine lokale Datenbank einrichten und sie lokal auf ihrem eigenen Rechner testen lassen?

  • Wie empfehlen Sie den Umgang mit Datenschichtänderungen?

  • Gibt es noch etwas, was Sie empfehlen würden, um unseren Entwicklungsprozess so einfach und effizient wie möglich zu machen?

Vielen Dank im Voraus

Antwort

3

+1 zu jedem Entwickler ihr eigenes Setup, komplett mit Apache und die Datenbank ausgeführt wird.

Behalten Sie das Datenbankschema unter Versionskontrolle.

Möglicherweise könnten Sie (vielleicht in einem separaten Repository) einen kleinen, aber repräsentativen Datensatz in einer Testdatenbank speichern. Jeden Morgen schauen Sie sich die neueste Version dieser Testdatenbank an und beginnen mit dem Hacken. Wenn Sie Schemas ändern, aktualisieren Sie Ihr Testdaten-Repository entsprechend.

+0

Wie behalten Sie das Datenbankschema in der Versionskontrolle? Klingt nach einer wirklich guten Idee - ich habe es vorher noch nicht gesehen. – christophmccann

+0

Ich schrieb einen Artikel darüber: http://www.gsdesign.ro/blog/mysql-database-versioning-strategy/ und Sie könnten hier auch mehr lesen: http://StackOverflow.com/Questions/1607/Mechanismen- for-tracking-db-Schemaänderungen –

0

Jeder, der Entwicklung macht, sollte seine eigene lokale Umgebung haben. Ich benutze Mac, also lasse ich MAMP laufen, damit ich meine eigene LAMP-Umgebung lokal und unabhängig von jeder anderen Umgebung haben kann. Dies erlaubt mir auch zu wissen, dass niemand anders die gleichen Komponenten verändert/bearbeitet, die ich bin, und jede mögliche Verwirrung beseitigt. Wenn Sie ein Windows-Benutzer sind, gibt es auch einfach zu installierende lokale Versionen des LAMP-Stacks wie XAMP, etc. Wenn Sie Linux als Ihren Desktop betreiben, werden Sie wahrscheinlich schon wissen, wie man LAMP für den Geschmack von Linux installiert Rennen.

Die Datenbankschemaversion ist eine großartige Idee. Es ist was wir auch verwenden. Zusätzlich zum Schema unter Versionskontrolle fügen wir dem Schema eine Schemaversionstabelle hinzu und halten sie auf dem neuesten Stand, so dass wir schnell erkennen können, welche Version in production/qa/dev ist, wenn wir vergleichen müssen.

Für die Datenschicht Änderungen gibt es zwei Dinge, die ich empfehlen würde.

  1. Erstellen Sie immer Ihren Migrationspfad vorwärts und rückwärts. Dies bedeutet, dass Sie das Schema, das Sie für die Produktion verwenden möchten, um ein vorhandenes Schema zu aktualisieren, immer als Teil des Releases verwenden sollten. Ein übersichtlicher Prozess zum Ändern der Tabellen. Aus dem gleichen Grund benötigen Sie eine funktionierende und getestete ROLLBACK-Version für den Fall, dass etwas schief geht.

  2. Was ich hilfreich gefunden habe, ist eine Sicherung der Produktion zu laden auf meinem lokalen (oder QA/DEV), so dass ich die aktuellsten Daten/Schema zu spielen haben, ohne die Produktion zu beeinflussen. Wenn Sie keine regelmäßigen Produktionssicherungen durchführen, ist es jetzt vielleicht an der Zeit, eine Richtlinie zu implementieren. Dann werden Sie zwei Fliegen mit einer Klappe schlagen. Sie haben Sicherungen für jeden Ausfall und ein nützliches Live-Schema mit Daten, die Sie zum Testen auf einem anderen Rechner laden können. Dies wird sich auch für mögliche Probleme mit Schemaänderungen eignen, da die Daten der Produktion entsprechen. Wenn es also lokal (und auf DEV/QA) funktioniert, reduziert es das Risiko, dass in der Produktion etwas schief geht.