MySQL-Datenbank für ein Entwicklungsteam: wie am besten?
0 2 1 
dedlfix
MySQL-Datenbank für ein Entwicklungsteam: wie am besten?
Liebe Forumsmitglieder,
ich muss mich hier gerade staendig rumärgern, weil wir zwar mittels Subversion auf denselben Sourcen arbeiten (was ja schon mal ganz schön ist), aber jeder seine eigene Datenbank-Instanz laufen hat. Kaum ändert man was am Datenmodell, haben gleich alle den Ärger: entweder sie müssen dasselbe Update vornehmen, oder akzeptieren, dass der neue Code teilweise nicht zur Datenbank passt.
Letztlich sind die Datenbanken aber alles nur Kopien! Es müsste doch möglich sein, eine zentrale Datenbank zur Verfügung zu stellen, auf der alle arbeiten.
Nur: wie mache ich das in einem Windows-2000-Netzwerk mit MySQL? Ich wäre euch da für einen Tipp sehr dankbar!
Liebe Grüße,
Ralph
-
moin,
Nur: wie mache ich das in einem Windows-2000-Netzwerk mit MySQL? Ich wäre euch da für einen Tipp sehr dankbar!
Sofern mehrere Kollegen auf einer Maschine gleichzeitig arbeiten sollen, braucht es ein Multi-User-Operating-System; unter Win32-Systemen auch bekannt als Terminal-Server.
Hotte
--
Wenn der Kommentar nicht zum Code passt, kann auch der Code falsch sein. -
Hallo,
ihr habt kein Problem mit der Technik (vollkommen egal, ob da jetzt ein Windows 2000 Netzwerk ist oder irgendwas anderes) sondern mit euch selbst. Organisiert euch besser!
1. Modularisiert eure Entwicklungsbereiche, jeder sollte so unabhängig wie möglich voneinander arbeiten
2. Deklariert Interfaces / Schnittstellen, welche stabil bleiben und wo sich jeder dran zu halten hat
3. checkt nur Code ein, der auch funktioniert (wenn alle auf nur einer DB hocken ist es noch schlimmer als wenn jeder seine eigene DB kaputtschiesst mit neuem Code.
4. arbeitet mit "Sandboxen", jeder entwickler kann/soll sich seine eigene Umgebung bauen (das ist ein KANN ... kein MUSS)
5. definiert "Release-Zyklen" zu welchen bestimmte Module/Funktionen in einer gewissen Reife allen anderen zur Verfügung gestellt werden (jeden Freitag, Montag)
6. zu diesen Release-Zyklen erzeugt ihr auch die Umgebungen (DBs immer wieder neu)
7. wer Änderungen an der DB macht, hackt nicht nur irgendwelche ALTER Statements zusammen sondern schreibt auch ein Migrationsscript
8. setzt einem von euch den Hut auf, sich um die DB(s) zu kümmern
9. macht nicht jeden Tag ein "GetLatest" von eurem Sourcecode
10. Wer Scheisse baut und irgendwelchen Kot eincheckt und damit anderen die Umgebung zerschiesst, zahlt 5 Euro, Dollar, Franken, Birnen, Bier in die GemeinschaftskasseEs müssen nicht alle 10 Punkte umgesetzt werden.
Softwareentwicklung im Team ist mehr eine Frage des Prozesses als eine Frage der Tools.
Ich arbeite gleichzeitig in ca. 4 Projekten mit verschiedenen Leuten zusammen, Koordination ist mein täglich Brot. Und kostet natürlich auch Zeit, ca. 30% bis 50%.
Ein recht interessanter Ansatz ist z.b. YaM
Ciao, Frank
-
Hallo Frank,
wow, danke dir! Sehr interessante Ansätze!
Basierend auf deinen Anmerkungen läuft jetzt Subversion zentral, die DB aber lokal. Ich hab einen Workflow implementiert, mit dem jeder bei Bedarf seine Version der DB auf den aktuellen Stand updaten kann, und diese dann entweder mit seinen eigenen Daten oder mit den zentral von mir angelegten Testdaten befüllen kann. Das Datenmodell liegt zentral in SVN, da hat also jeder dieselbe Version.
Jetzt gucken wir mal, ob das Sinn macht!Und mit deinen weiteren Punkten werde ich michmal in Ruhe auseinander setzen!
Ralph
Hallo,
ihr habt kein Problem mit der Technik (vollkommen egal, ob da jetzt ein Windows 2000 Netzwerk ist oder irgendwas anderes) sondern mit euch selbst. Organisiert euch besser!
- Modularisiert eure Entwicklungsbereiche, jeder sollte so unabhängig wie möglich voneinander arbeiten
- Deklariert Interfaces / Schnittstellen, welche stabil bleiben und wo sich jeder dran zu halten hat
- checkt nur Code ein, der auch funktioniert (wenn alle auf nur einer DB hocken ist es noch schlimmer als wenn jeder seine eigene DB kaputtschiesst mit neuem Code.
- arbeitet mit "Sandboxen", jeder entwickler kann/soll sich seine eigene Umgebung bauen (das ist ein KANN ... kein MUSS)
- definiert "Release-Zyklen" zu welchen bestimmte Module/Funktionen in einer gewissen Reife allen anderen zur Verfügung gestellt werden (jeden Freitag, Montag)
- zu diesen Release-Zyklen erzeugt ihr auch die Umgebungen (DBs immer wieder neu)
- wer Änderungen an der DB macht, hackt nicht nur irgendwelche ALTER Statements zusammen sondern schreibt auch ein Migrationsscript
- setzt einem von euch den Hut auf, sich um die DB(s) zu kümmern
- macht nicht jeden Tag ein "GetLatest" von eurem Sourcecode
- Wer Scheisse baut und irgendwelchen Kot eincheckt und damit anderen die Umgebung zerschiesst, zahlt 5 Euro, Dollar, Franken, Birnen, Bier in die Gemeinschaftskasse
Es müssen nicht alle 10 Punkte umgesetzt werden.
Softwareentwicklung im Team ist mehr eine Frage des Prozesses als eine Frage der Tools.
Ich arbeite gleichzeitig in ca. 4 Projekten mit verschiedenen Leuten zusammen, Koordination ist mein täglich Brot. Und kostet natürlich auch Zeit, ca. 30% bis 50%.
Ein recht interessanter Ansatz ist z.b. YaM
Ciao, Frank
-
-
echo $begrüßung;
Es müsste doch möglich sein, eine zentrale Datenbank zur Verfügung zu stellen, auf der alle arbeiten.
Ja, warum auch nicht? Dafür ist MySQL ausgelegt. Mit umfangreichem Berechtigungskonzept. MySQL auf separatem Rechner aufsetzen, Netzwerkzugriff freigeben, Benutzer- und Berechtigungssystem verstehen und konfigurieren. Fertig. Noch Fragen? :-)
echo "$verabschiedung $name";