Wie pflege ich eine Demoversion einer Anwendung?

Ich muss in der Lage sein, unsere Produktionsanwendung potenziellen Kunden vorzuführen. Die Art und Weise, wie ich es heute eingerichtet habe, ist einfach. Die Demo-Anwendung ist ein genaues Duplikat des Produktionssystems, mit der Ausnahme, dass die Daten in der Datenbank verschleiert sind, um die Daten unserer aktuellen Kunden zu schützen. Dies funktioniert hervorragend, da keine Anwendungsänderungen erforderlich sind.

Boss hat heute eine potenzielle BOMBSHELL fallen lassen und gesagt, dass das Demosystem einen speziellen Link enthalten muss und dass NUR in der Demo angezeigt wird . Er fuhr fort zu erklären, dass es in Zukunft möglicherweise viel größere Unterschiede zwischen der Demo und den Produktions-Apps geben wird (z. B. einen ganzen Funktionsbereich). Was mache ich jetzt?

Einige Dinge, über die ich nachgedacht habe:

Pflegen Sie einen anderen Zweig in Subversion, der für das Demosystem spezifisch ist
Erstellen Sie ein Installationspaket mit den Änderungen für die Demo, setzen Sie es zurück und erstellen Sie ein Produktionsinstallationspaket
Modularisieren Sie die Anwendung (keine Ahnung wie)
Sag: "Scheiß auf dich! Ich werde es nicht tun!" (LOL)
Verwenden Sie eine bedingte Logik in der App, um festzustellen, ob es sich um eine Demo oder eine Produktions-App handelt. ZB (wenn die URL 'Demo' enthält, dann zeige else hide).

Wenn Sie bis jetzt noch nicht geraten haben, handelt es sich um eine Webanwendung

Wie auch immer, ich habe in diesem Szenario keine Erfahrung, welches besser ist oder ob keines davon gut ist. Hat jemand eine Antwort, Strategie, etwas!?

c# asp.net deployment maintenance

— OO
quelle

Verzweigen Sie den Code nicht darüber, wenn Sie helfen können. Haben Sie keine separate Installation, wenn Sie helfen können. Fügen Sie keine "Demo" in die URL ein - dies lässt das Produkt gefälscht erscheinen. Sie sollten in der Lage sein, es zu einem Konfigurationsparameter zu machen. Im Idealfall haben Sie keine if-Anweisungen, die die Konfiguration im gesamten Code überprüfen, möglicherweise einen Aufruf, um festzustellen, ob eine Funktion unterstützt wird, und nur das implementierte Objekt, das weiß, warum - hängt von Ihrer Anwendung ab.

— Psr

Antworten:

Pflegen Sie einen anderen Zweig in Subversion, der für das Demosystem spezifisch ist
- Ja! Das hilft wirklich. Aber sei vorsichtig, wie du es machst. Das Beste ist, wenn sich das Hauptsystem weiterentwickelt, sollten Sie wissen, wie Sie Ihre Änderungen so nah wie möglich bringen können.
Erstellen Sie ein Installationspaket mit den Änderungen für die Demo, setzen Sie es zurück und erstellen Sie ein Produktionsinstallationspaket
- Dies könnte funktionieren - aber wenn Sie viele Demos machen, verlieren Sie Ihren guten Teil Ihres Lebens damit.
Modularisieren Sie die Anwendung (keine Ahnung wie)
- Dies ist die beste Antwort. Siehe unten.
Sag: "Scheiß auf dich! Ich werde es nicht tun!" (LOL)
- Auf jeden Fall nein! Nicht weil du Angst haben solltest. Aber ein guter Ingenieur gibt die Herausforderungen nicht auf.
Verwenden Sie eine bedingte Logik in der App, um festzustellen, ob es sich um eine Demo oder eine Produktions-App handelt. ZB (wenn die URL 'Demo' enthält, dann zeige sonst verstecken).
- Auf jeden Fall nein! Dies würde Ihr Produkt im Laufe der Zeit sehr schwach machen.

Wenn Sie an ein Demo-Produkt denken (es sei denn, Sie sprechen von Trail-Versionen), denken Sie nicht wie ein "separates Produkt", sondern wie eine "separate Umgebung". Wenn Sie und ich beide die WordPress-Engine auf unseren jeweiligen Websites installieren, haben wir dasselbe Produkt, aber unterschiedliche Daten. Sie müssen Ihr Produkt so gestalten, dass installations- (und verwendungsspezifische) Inhalte wie die Erstellung verschiedener Inhaltsquellen erstellt werden können. In ähnlicher Weise - zum Beispiel - wenn Sie eine native .NET- oder JAVA-Anwendung erstellen, bleibt die Funktionalität dieselbe - können jedoch verschiedene Ordner (einschließlich Begrüßungsbildschirme und Schaltflächen) verwendet werden, um sie in unterschiedlicher Form anzuzeigen. Später - die Nachfrage wird kommen, um sogar die Layouts zu ändern - dann wissen Sie, dass Sie mehr Vorlagen benötigen!

Springen Sie nicht auf einmal zur Modularisierung. Beginnen Sie bei Bedarf zunächst einen separaten Zweig (Entwicklungslinie) und geben Sie die Demo! (Da alle Demos normalerweise am nächsten Morgen um 10:30 Uhr stattfinden). Die Abweichung, die Sie jetzt erstellt haben, gibt an, welche Modularisierung vorhanden sein sollte, um von externen Ressourcen übernommen zu werden. Wenden Sie das an und führen Sie es wieder zusammen. Beim nächsten Mal ist dieselbe Demo Ihre Standardversion (mit unterschiedlicher URL).

Fast immer, wenn Sie am Ende "separates Produkt" als Demo erstellen - Sie laden Ärger oder Schmerz oder beides ein!

Dipan.

— Dipan Mehta
quelle

Ich mag deine Antwort wirklich. Zum einfachen Ausblenden und Anzeigen eines Links kann ich mit einem separaten Zweig davonkommen - wie Sie sagten.

— OO

Ich stimme einigen Punkten dieser Antwort nicht zu. Das Erstellen eines anderen Zweigs unterscheidet sich nicht wesentlich vom Erstellen eines "separaten Produkts", vor dem Sie das OP (korrekt) warnen. Ein langfristiger Zweig, der nicht mit der Hauptentwicklungslinie zusammengeführt wird, ist nichts anderes als eine Kopie, die separat gepflegt werden muss. Um dies zu vermeiden, gibt es den bekannten Ansatz, Feature-Toggles zu verwenden , was "bedingte Logik in der App" bedeutet und oft eine viel bessere Lösung ist, als SVN-Zweige dafür zu missbrauchen.

— Doc Brown

@DocBrown - Sie haben die Frage und Antwort nicht gelesen. Die vier Optionen wurden von OP angegeben und die Antwort zeigt nur die Auswirkungen. Die Antwort zeigt, dass schnelle Vorteile sowie Fallstricke für jeden. Während das Feature bei mehreren Varianten definitiv die besten Lösungen umschaltet, ist die SVN-Verzweigung im Wesentlichen ein einfacher Ausweg für solche Änderungen. Es hängt wirklich alles von der kurzfristigen oder langfristigen Sichtweise ab, wie wahrscheinlich diese Abweichungen sind. Und aus meiner Sicht bewertet die Antwort wirklich alle Optionen und ihre Auswirkungen ziemlich neutral!

— Dipan Mehta

Und ehrlich gesagt - was ist so schlecht an dieser Antwort, dass sie -1 Stimme verdient?

— Dipan Mehta

Keine Notwendigkeit mich zu beleidigen. In meinem Kommentar geht es genau um Ihre Auswirkungen. Sie haben geschrieben: "Pflegen Sie einen anderen Zweig in Subversion - Ja! ". Meine Meinung hier: " Nein , tu das nicht, das ist ein sehr schlechter Rat, da die Demo wahrscheinlich ein langfristiges Feature ist." Und Sie haben geschrieben: "Verwenden Sie eine Art bedingte Logik in der App - definitiv nein! ". Dies steht jedoch im Widerspruch zur Verwendung von Funktionsumschaltern. Wenn Sie Probleme mit der Abstimmung haben, bearbeiten Sie Ihre Frage und lösen Sie diese Widersprüche. Vielleicht haben Sie die Dinge anders gemeint.

— Doc Brown

Der beste Ansatz wäre die Modularisierung, damit Sie Elemente in jeder App ein- oder ausschalten können.

Ihre Demo ist eine Produktinstallation mit einer Konfiguration, die andere Dinge als die eigentliche Produkt-App aktiviert und auf eine andere Datenbank verweist.

— CaffGeek
quelle

+1 für eine einfache Antwort auf eine ziemlich einfache Anfrage seines Chefs.

— dodgy_coder