mepeisen

Eine sehr simple Frage an euch: Wie strukturiert ihr eure Projekt? Wie legt ihr was ab? Zielsetzung meiner Frage ist es, eine möglichst flexible Projektstruktur zu etablieren. Später soll das in Eclipse abgebildet werden, das ist jedoch Zukunftsmusik. Bitte die logische Strukturen einmal angeben. Ich weiss, dass beispielsweise in Eclipse das Layout teilweise vorgegeben ist. Oder dass ein Framework das Layout vorgibt.

Ich gebe einmal eine Beispielsstruktur vor, wie man sich das vorstellen könnte:

-> Projekt A
----> Version "Stufe 1"
-------> Projekt "Fachdoku"
-------> Version "V1.2.9"
----------> Projekt "UML"
----------> Projekt "Technische Doku"
----------> Projekt "Grafiken und Templates"
----------> Projekt "Quellcode"
-------> Version "V1.2.10-dev"
----------> Projekt "UML"
----------> Projekt "Technische Doku"
----------> Projekt "Grafiken und Templates"
----------> Projekt "Quellcode"
----> Version "Stufe 2"
-------> Projekt "Fachdoku"
-------> Version "V2.0.0-dev"
----------> Projekt "UML"
----------> Projekt "Technische Doku"
----------> Projekt "Grafiken und Templates"
----------> Projekt "Quellcode"


Bei diesem (logischen) Layout wird ein Projekt zunächst in fachliche Versionen unterteilt. Diese fachliche Versionen beinhalten dann bereits mögliche Teilprojekte, in diesem Fall eines zur Fachdoku, in dem eventuell auch Pflichtenhefte usw. abgelegt werden. Die fachliche Version ist feiner unterteilt in technische Versionen. Einmal echte Release-Versionen und dann natürlich Branches für die Weiterentwicklung/ Bugfixing-Phase.

Sinn dahinter: Ich habe vor, die Projektverwaltung etwas zu verbessern. Als Ziel soll es später aus Anwendersicht (Anwender = Projektmitarbeiter) so sein, dass man zunächst nur ein Projekt sieht, weil da ja auch der gedankliche Eintrittspunkt ist für jeden. Das ist das eigentliche Projekt A. Eine in sich geschlossene Gruppe von Projekten, Versionen usw. Nun soll man in der Lage sein, rein logisch für die Version V1.2.10-dev einen Bugfix zu machen, indem man genau diese Version auscheckt. Dass dabei mehrere technische Projekte ausgecheckt werden, soll mich im ersten Moment gar nicht interessieren. Sprich: Das Wissen, welche Teilprojekte ich auschecken muss, wo sich diese im SVN verstecken und was ich vielleicht doch nicht brauche, soll mir das System abnehmen.

Als Zielvorstellung sollte man dies auch noch über einen Bugtracker beispielsweise steuern können. Sprich: Mit dem Projekt A ist ein Bugtracker verknüpft. Eclipse zeigt Bugs zu diesem Projekt an. Will ich einen Bug bearbeiten, habe aber die Version noch nicht im Workspace, kann ich dies ebenfalls nun auschecken.

So, nun bin ich mal gespannt auf eure Antworten.

__________________
www.php-maven.org PHP und Maven vereint: Build/Deploy/Produktion/Konfiguration, Projekt Management, CI, PHPUnit, zahlreiche Frameworks
Twitter @ https://twitter.com/#!/mepeisen und Facebook @ http://t.co/DZnKSUih

Mister Ad

nikosch

Tja, das ist die Frage.

Kommt drauf an:
1. Was man alles zum Projekt zählt
- Korrespondenz
- Beistellungen (z.B. Pflichtenheft)
- Analysen und Entwürfe
2. Wie und welche Daten man versioniert
3. Welche Fremdmodule man verwendet, wie sie eingebunden sind und wie mit Versionswechseln im laufenden Projekt verfahren wird

usw.
Letztlich habe ich auch gemerkt, dass bspw. grafische Projekte bei mir eine ganz andere Projektstruktur erfordern, als der Themenbereich Softwareentwicklung.

__________________
--
One pixel is still too big. Please make it smaller. ASAP.

Initiative Mittelstand.
Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers.
--

mepeisen

Im Idealfall wird alles dazu gezählt, also auch die Korespondenz. Deswegen habe ich auch die logische Projektstruktur gemeint. Sachen, wie die Korrespondenz oder auch Bugs, sind ja im Normalfall nicht direkt im SVN, sondern in externen Systemen, wie einem Bugtracker/einer Datenbank oder auch einem IMAP-Ordner eines eMail-Kontos (bzw. mehreren).
In Eclipse im Fokus steht zunächst das, was direkt mit der Dokumentation und der Entwicklung, sowie dem Deploy zu tun hat. Insbesondere die Korrespondenz soll sich erst einmal darauf konzentrieren, dass per Plugin zu einem externen Modul (im einfachsten Fall einer URL eines Webmailers) verzweigt werden kann. Ich will mit Eclipse keine eMail-Software nachbauen.

Was man sich jedoch vorstellen kann: Sobald in Eclipse eine Version getaggt wird, sorgt ein Plugin dafür, dass diese version im Bugtracker eingetragen wird und dass ein eMail-Konto vorkonfiguriert wird, so dass die Nachrichten zu dieser Version in einen Ordner verschoben werden können, den man nicht extra anlegen muss.
Das Reagieren auf eine Entwicklungs-Aktion, wie dem Bau einer echten Version, obligt dann Plugins. Das will ich bewusst flexibel halten, um später ein komplexeres per Web steuerbares System einbinden zu können und für einfache Fälle ein Systemn, was lediglich mit Bugzilla und SVN direkt zusammenarbeitet.

Sieh es als eine Art große Projektakte.

Die Fremdmodule werden nur als symbolischer Link eingebunden. Also als Abhängigkeit. Der Inhalt selbst soll explizit nicht im Projekt landen. Es ist dann Aufgabe eines Projekt-Repositories oder eines Plugins in Eclipse, die Abhängigkeit aufzulösen.
Natürlich bedingt beispielsweise ein Zend-Framework-Projekt eine gewisse Struktur innerhalb des technischen Projektes "Quellcode". Das ist mir durchaus klar. Das will ich dann über eine Art Template-System lösen.
Es gibt dann meinetwegen das Template "Zend-Framework-Modul". Dieses hat ein vorgegebenes Layout für ein Eclipse-Projekt. Sobald es angelegt wird, werden entsprechende Verzeichnisstrukturen u.ä. etabliert.
Wenn man als Entwickler nun bereits spezielle Sachen anlegen will, kann man ein eigenes Zend-Framework-Template schreiben.


Was im übrigen ein Nebeneffekt wäre: Eine einheitliche Benutzerverwaltung. Sprich: In Eclipse nur einmalig die entsprechenden Benutzer mit Passwort pflegen und je nach angesprochenem Modul (SVN, Mailer, Bugtracker) wird dann der konfigurierte Account verwendet. Selbst wenn dann Eclipse nur eine Webseite anzeigt, finde ich, ist es eine kleine Arbeitserleichterung, weil man nicht mehr selbstständig über Bookmarks u.ä. ständig rumnavigieren muss bis man das zum Projekt zugehörige gefunden hat.


Frage: Wie sieht es denn bei den Grafikprojekten mit den logischen Strukturen aus?

__________________
www.php-maven.org PHP und Maven vereint: Build/Deploy/Produktion/Konfiguration, Projekt Management, CI, PHPUnit, zahlreiche Frameworks
Twitter @ https://twitter.com/#!/mepeisen und Facebook @ http://t.co/DZnKSUih

nikosch

Ich muss leider zugeben, ich weiß nicht, was Du mit „logischen“ Strukturen meinst.

__________________
--
One pixel is still too big. Please make it smaller. ASAP.

Initiative Mittelstand.
Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers.
--

mepeisen

Deinen Kopf. Ich will wissen, was du im Kopf hast.

Wie organisierst du dich und deine Projekte? Was nutzt du typischerweise für deine Projekte? In was für inhaltliche Themen unterteilst du sie? Was hast du dabei im Blick, wenn du ein Projekt über mehrere Stufen begleitest? Wie wichtig sind Versionsnummern eigentlich? Wie wichtig ist das Verzeichnislayout? Was passiert quasi in deinem Kopf, wenn du mehrere Versionen eines Projektes verwalten musst (Bugfixing/ Weiterentwicklung)? Was passiert, wenn du auf eine neue Version eines Frameworks umstellen willst?


Was ich finden will, ist ein Ansatz, der das projekt als Gesamtes so darstellt, wie man es im Kopf hat. Etwas was, wenn auch auf einfachem Weg, alles, was mit einem projekt zusammenhängt (also auch eMails, Bugs usw.) mal zusammenbringt und darstellt. Mehr nicht. Und dann natürlich Schritt für Schritt aus sowas einen Vorteil ziehen damit man nicht gesondert 5 Webseiten-Bookmarks und 3 Anwendungen öffnen muss um einfach die tägliche Arbeit zu erledigen.
In anderen Worten: Man soll nicht nachdenken, was man nun im Bugtracker auswählen muss, um die Bugs der Version uz sehen, deren Eclipse-Workspace man gerade geöffnet hat.

__________________
www.php-maven.org PHP und Maven vereint: Build/Deploy/Produktion/Konfiguration, Projekt Management, CI, PHPUnit, zahlreiche Frameworks
Twitter @ https://twitter.com/#!/mepeisen und Facebook @ http://t.co/DZnKSUih

xm22

Da hast Du aber viel Redundanz drin (Was ja nicht falsch sein muss - es ist mir nur aufgefallen). UML und Technische Doku sollte man in meinen Augen zusammen fassen (Kann ja auch noch sql usw. dazu kommen)

nikosch

Bei nem filesystembasierten Prinzip hast Du immer Redundanz.

Wenn man UML „richtig“, also in der Entwurfsphase macht, eigentlich nicht.

__________________
--
One pixel is still too big. Please make it smaller. ASAP.

Initiative Mittelstand.
Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers.
--

mepeisen

Zu den Redundanzen
Gut, lokal hast du grundsätzlich Redundanzen, ja. Checkst du das in SVN ein, werden neue Kopien erst einmal symbolische Referenzen auf die ursprüngliche Datei und erst mit Änderung wird das tatsächlich eine "neue" Datei. Und trotzdem ist es Dateibasierend. Bei GIT ist das ähnlich. Sprich: Rein technisch kann (und sollte) diese Projektakte natürlich in weiten Teilen die Unterstützung eines Versionierungssystems nutzen für alles, was mit Dateisystemen zu tun hat. Sobald du mit einer Versionierung arbeitest und ältere Versionen weiterpflegst (für Bugfixes u.ä.), hast du Redundanzen.
Aus SVN-Sicht: Version 1.2.9 wäre ein Tag, Version 1.2.10-dev ein Branch und Version 2.0.0-dev der Trunk.
Die Schwierigkeit ist noch, das so hinzubekommen, dass die Projektakte die Implementierungsdetails (Anlegen eines Branches u.ä.) weitesgehend unsichtbar erledigt. Jeder hat seine bevorzugte Arbeitsweise, sein bevorzugtes Layout. Aber wenn ich für mich einmal eine Arbeitsweise gefunden habe, will ich, dass ich nur noch sage "Neue Version" oder "Bugfix auf bestehender Version". Das ist dann mein fachlicher Anwendungsfall. Und nicht "Lege Branch an, trage im Bugtracker ein, informiere Kunden über Verknüpfung des Bugs mit Weiterentwicklungs-Branch". Dort für alle Projekttypen und für jede mögliche Variante einen allgemeingültigen Anwendungsfall zu finden, die sich dann auch technisch umsetzen lassen, fällt mir aktuell noch etwas schwer.

Betrachtet man einen Bugtracker, sind Redundanzen dadurch aufzulösen, dass man beispielsweise einen Bug einfach mehreren Versionen zuordnet. Den Bug gibt es dann nur einmal, dennoch ist er von zwei Versionen aus sichtbar.

Ich betrachte das aus zwei Ebenenen zur Zeit: Einmal aus einer abstrakten Ebene, was dann gleichzeitig in einer API resultieren wird. Und dann an konkreten Beispielen für die Realisierung, was dann in den Plugins zur Anbindung verschiedener Systeme und Projekttypen an die Projektakte resultieren wird. Die Bedienung soll sich weitesgehend identisch verhalten, egal ob ich eine SVN/Bugzilla-Kombi am Ende habe, ein komplexes Web-Frontend oder ob ich nur lokal auf dem Dateisystem arbeite ohne Versionssystem.

Zur Doku/UML

Mit obigem Beispiel wollte ich wirklich nur genau das zeigen: Ein Beispiel. Ich bin mir bewusst (und rein technisch soll es so flexibel sein), dass es genug Argumente gibt, die beiden Projekte zusammenzufassen. In einem anderen Unternehmen werden sich genug Argumente finden lassen, die Projekte zu trennen. Beispielsweise habe ich zur Zeit eine Lösung, die den UML-Teil als Maven-Projekt begreift. Damit wird - aus Sicht von Eclipse - der UML-Teil ein eigenes Projekt und die technische Doku damit ein zweites Projekt. Sobald ich mit Modul A eine Abhängigkeit zu Modul B habe, wird Maven angewiesen den UML-Teil aufzulösen und ich kann in meinem UML auf die Modellierung des abhängigen Projektes zugreifen.

Also zusammenfassend: Im Doku-Bereich wird sehr oft über Verzeichnislayout und Templates gearbeitet und jeder hat seinen eigenen Geschmack bzw. seine eigenen Vorlagen und Vorgehensweisen. In technischen Projekten, wie dem eigentlichen Quellcode, geben oft Strukturen eines Frameworks das Verzeichnislayout vor. Bei anderen Elementen (Bugzilla beispielsweise) gibt es wiederum einen völlig anderen Einfluss auf das "Layout". Bugzilla beispielsweise kann Teilmodule pflegen, die nicht zwangsläufig eins zu eins einem technischen Projekt entsprechen. Wer trennt schon permanent auch technisch seine Projekte in "Frontend", "Admin-Backend", "Datenbankklassen", "Business-Services" auf. Idealerweise wird diese Aufteilung über Namespaces u.ä. geregelt.


Generell aber bitte mal weiter diskutieren. Gerne am praktischen Beispiel. Denn dann kann ich auch schauen, was alles notwendig wäre um eure praktischen Beispiele umzusetzen und ob es Sinn macht bzw. wie flexibel das System sein müsste.

__________________
www.php-maven.org PHP und Maven vereint: Build/Deploy/Produktion/Konfiguration, Projekt Management, CI, PHPUnit, zahlreiche Frameworks
Twitter @ https://twitter.com/#!/mepeisen und Facebook @ http://t.co/DZnKSUih

mquadrat

- Sourcecode: SVN, Versionen getagged
- Unit-Tests: SVN
- Dokumente: Sharepoint
- Kundenabsprachen: CRM unserer WaWi
- Zeiterfassung: WaWi
- Issue-Tracking: Ticketsystem unserer WaWi

__________________
Wir suchen PHP Entwickler (Vollzeit) im Raum Darmstadt / Rhein-Main. Infos via E-Mail mueller@new-frontiers.de

nikosch

Ich würde Dir empfehlen, bei Deiner Anwendung unbedingt die durchschnittlichen Unternehmen nicht zu vergessen. Bei uns (KMU) läuft alles (!) per Gespräch oder E-Mail - ganz einfach weil sich die beteiligten Personen damit auskennen oder das in ihren Workflow integriert ist (ob jetzt normaler Client, CRM, PIM o.ä. sei mal dahin gestellt). Von daher wäre es wohl clever, E-Mail als Medium zum Teil der Anwendung zu machen, ähnlich wie es manche Bugtracker ja auch schon leisten. Auch wenn E-Mail nicht das Idealmedium dafür ist, imho ist es schon lange dazu "verkommen" von Arbeitsanweisung über Fehlerbericht bis Eingabedokumente komplett darüber zu versenden. Sicher - damit lässt sich bis auf Basics (verschiedene E-Mail-Adressen usw.) kaum eine technische Kategoriesierung der Inhalte erreichen, aber das ist beim durchschnittlichen Workflow ja auch nicht gegeben.

__________________
--
One pixel is still too big. Please make it smaller. ASAP.

Initiative Mittelstand.
Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers.
--