Auch wenn man derzeit (noch) keine verteilte Entwicklung hat, muss heute ein SCCM darauf ausgerichtet sein. Mindestens muss man wissen, wie man damit umgehen will, wenn es einmal so weit ist. Und dieser Tag ist meistens näher als man meint.

Einst die Regel, heute die Ausnahme: die Entwicklungsabteilung mit allen Entwicklern an einem Ort. Selbst wenn es nur einen Entwicklungsstandort gibt, trägt sicher eine Mitarbeiterin ihre Arbeiten auf dem Laptop mit und ein Entwickler arbeitet zu Hause. Schon haben wir eine verteilte Entwicklung. So geht es weiter mit Filialen und Niederlassungen, mit Externen, Near- und Offshoring und Outsourcing und was es sonst noch gibt an Formen der Auslagerung und Verteilung.

Es geht nicht um die Frage, wie sich eine solche Arbeit organisieren lässt oder ob sie sinnvoll ist. Die verteilte Entwicklung ist ein Faktum, selbst wenn man sie gar nicht anstrebt. Denn der transportable Laptop und das omnipräsente Internet führen die Verteilung einfach und schleichend ein. Das Konfigurationsmanagement muss damit effizient umgehen können. Wenn nicht, machen seine Unzulänglichkeiten  den Nutzen der Verteilung mehr als zunichte.

Die Kommunikationsinfrastruktur, die die dezentralisierte Entwicklung ermöglicht, ermöglicht auch das dezentrale SCCM. Die Open-Source-Welt hat vorgelebt und bewiesen, dass verteiltes Konfigurationsmanagement mit einer weltumspannnenden, quasi anonymen Entwicklergemeinschaft möglich ist.

Moderne, meist browserbasierte Konfigurationsmangementsysteme können von Haus aus mit dezentraler Entwicklung umgehen. Man darf sich trotzdem nicht dem falschen Glauben hingeben, dass das Werkzeug auch die organisatorischen Probleme aus der Welt räumt. Organisationsregeln braucht es genau gleich, das Werkzeug ist lediglich das Mittel, das einem bei der Durchsetzung der Regeln unterstützt.

Aller Möglichkeiten der modernen Werkzeuge zum Trotz muss man danach trachten, die Strukturen und Abläufe klar und einfach zu halten. Denn komplizierter wird’s von allein. So ist es einfacher, und mit den heutigen Kommunikationsmitteln auch möglich, mit einer zentralen Datenbank (Repository) zu arbeiten. Damit erspart man sich das  Synchonisieren redundanter Daten, die trotz sorgfältigstem Abgleichen von Natur aus zum Auseinanderlaufen neigen.

Releaseplanungen, klare Arbeitsteilung und Abläufe mit definierten Teststufen und Abnahmekriterien sind bei der verteilten Entwicklung nötiger denn je. Und auch bei dieser Best Practice gilt schliesslich, dass die Automatisierung möglichst vieler Tätigkeiten die Sicherheit und die Effizienz steigert.

Weitere Beiträge in der Best-Practices-Reihe:

(9): Kennzahlen – Grundlage für Prozessverbesserungen
(8): Plan your environment carefully
(7): Structure for distributed development
(6): Baselines — die sichere Basis
(5): Change-Pakete bilden
(4): Merge and Integrate as often as possible
(3): Wiederherstellbarkeit
(2): Private Arbeitsbereiche
(1): Forget One-Size-Fits-All SCM / Design Scaleable Best Practices

Tags: Best Practices

Trackback URI | Kommentare als RSS