Wie stellen Sie eine C#-Webanwendung bei einem Kunden bereit und verwalten sie, die sich nur geringfügig von Ihrem Basisprojekt unterscheidet?

Question

Ich habe eine halbwegs große Webanwendung, die wir lokal ausführen, und ich muss sie an einem anderen Standort bereitstellen. Für den zweiten Standort sind einige geringfügige Änderungen am Projekt erforderlich (vor allem kosmetischer Art). Wie gehen Sie mit diesen Unterschieden um und was verwenden Sie, um die Website und Updates an einen solchen Kunden zu verteilen?

Bearbeiten: Im Moment läuft unsere Web-App intern und wir bauen mit Cruise Control .NET und MSBuild mit WDP. Was wäre eine gute Option für die Bereitstellung an den Kunden? Wir werden nicht ihre Website für sie zu aktualisieren, so eine Lösung, die einfach für sie zu implementieren und zu aktualisieren ist wünschenswert.

Answer 1

Verzweigen Sie Ihren Code.

Hoffentlich ist Ihr Code quellenkontrolliert (wenn nicht, fangen Sie jetzt damit an!), Sie sollten von der Basis in den Zweig "Kunde X" verzweigen und nur die kleinen kosmetischen Änderungen in diesem Zweig vornehmen. Dann bauen Sie einfach aus diesem Zweig für diesen Kunden und stellen ihn bereit.

Wenn die Änderungen geringfügig genug sind, können Sie außerdem versuchen, die Änderungen konfigurierbar zu machen. Auf diese Weise könnten Sie überall dieselbe Website bereitstellen und lediglich die Konfiguration so ändern, dass sie den Wünschen des Kunden entspricht. Je komplexer die Unterschiede sind, desto schwieriger wird es allerdings, sie konfigurierbar zu machen.

Nach Prüfung der Kommentare: Es ist gut zu wissen, dass Konfiguration praktisch ist, aber NUR, wenn die Anzahl der Änderungen gering ist, sonst verschmutzt man seinen Code mit Konfigurationslogik. (Danke Kommentatoren)

Also: Viele Änderungen --> Verzweigen (besser wartbar), wenige kleinere Änderungen --> Konfigurierbar machen (praktischer).

Answer 2

Das müssen wir immer wieder tun. Wir versuchen zu verallgemeinern und die Unterschiede zwischen den Versionen konfigurierbar zu machen. Die häufigsten Gründe für Anpassungen sind:

• zusätzliche Datenbankfelder: Wir haben eine dynamische Methode zur Speicherung dieser Elemente in der Datenbank implementiert
• UI-Layout: wir haben spezielle Ordner, in denen wir Bilder und CSS-Dateien ablegen, die bei Bedarf geladen werden
• verschiedene obligatorische Eingabefelder: wir speichern die Definition in der Konfiguration und aktivieren sie programmatisch
• Spezielle Berichte: Wir legen die Vorlagendateien in den benutzerdefinierten Ordner, damit sie anstelle der Standardvorlage ausgewählt werden können.

Einige Änderungen erfordern die Programmierung neuer Module. Wir kodieren sie in einer benutzerdefinierten Bibliothek, die innerhalb der Hauptanwendung dynamisch geladen wird.

Answer 3

Normalerweise machen wir diese Unterschiede, indem wir uns an Daten orientieren. Der Unterschied für den Kunden ist lediglich eine andere Einstellung; jeder andere Benutzer könnte später dieselben "benutzerdefinierten" Optionen wiederverwenden.

Die Erstellung von "Unikaten" lässt sich nicht skalieren.

Answer 4

Aus diesem Grund sind benutzerdefinierte Aufnäher ein Problem. Normalerweise verzweigen wir nur in unserem Versionskontrollsystem und wenden die Änderungen nach der Aktualisierung manuell mit einem Skript an. Wegen des zusätzlichen Aufwands raten wir von benutzerdefinierten Patches so weit wie möglich ab.