Gibt es jemanden mit Erfahrungen / Beispielen zur frühzeitigen Veröffentlichung / Veröffentlichung für kommerzielle Software? Funktioniert es?
Ich habe an VMware gedacht, wo es zwischen jeder Hauptversion viele Revisionen gibt. Und die Installationserfahrung war schrecklich, manchmal unterbrachen sie die vorhandenen VMs und andere Male, wenn die VMware Tools in den Gastbetriebssystemen nicht funktionierten / nicht installiert wurden. Es ist einfach schrecklich.
Und ich habe auch an ClickOnce-Bereitstellungen gedacht, da ClickOnce bei der Aktualisierung Ihrer Software automatisch alle Clients über die Veröffentlichung informiert und mit einem Klick auf die neue Version aktualisiert werden. Wenn Ihre Software Fehler aufweist, werden sie automatisch "aktualisiert", um auch diese Fehler zu bekommen.
Haben Sie Erfahrung \ sample \ suggestion zur Anwendung des Release Early / Release oft auf kommerzielle Software?
Ich möchte es auf einen anwenden.
Kenny hat Recht: Es kommt darauf an.
Wir arbeiten an Unternehmenssoftware, bei der ein Kunde ein internes mehr als drei Monate dauerndes Projekt ausführen kann, um auf eine neue Version zu aktualisieren. In dieser Umgebung funktionieren häufige Versionen nicht . Kunden bleiben jahrelang auf einem alten Release und wir müssen sie weiter unterstützen. Je mehr Releases aktiv sind, desto mehr Supportarbeit wird geleistet.
Auf der anderen Seite habe ich Google Chrome ausgeführt und über eine Beta-Aktualisierung gelesen. Ich habe nachgesehen, wie ich es bekommen kann, und festgestellt, dass Chrome sich bereits aktualisiert hat. Wenn es eine Benachrichtigung gab, habe ich es verpasst, und das ist in Ordnung für mich.
Die Hauptfrage ist, wie disruptiv eine neue Version ist . Wenn beispielsweise MS alle drei Monate neue Versionen von Visual Studio mit einer neuen .NET-Version, C-Laufzeit usw. veröffentlicht, dann würden wir einen großen Teil unserer Zeit damit verbringen, nur mit dem Upgrade zu arbeiten, was nicht gut wäre. Aber wenn sie neue Versionen von Windows Media Player mit einem neuen Widget veröffentlichen wollen, ist das für mich in Ordnung - mach einfach den Download / Installationsprozess so nahtlos wie möglich.
Ich denke, es wird immer von Ihrem Markt oder Kundenstamm abhängen. Das Ändern / Aktualisieren von Software ist in manchen Umgebungen und Unternehmen immer schmerzhaft und noch schmerzhafter. Schnelle Release-Zyklen können störend sein. Diese Störungen erstrecken sich oft auch auf Ihre internen Abläufe, abhängig davon, wie gut Feature Creep durch Marketing / Management verwaltet wird. So, der Klassiker immer wahr 'es kommt darauf an' Antwort klingelt wieder Sie fügen dem Produkt wirklich Wert hinzu, dann werden Kunden besonders neue es wünschen. Der beste Fall ist, den Upgrade-Change-Schmerz zu entfernen, da es in der gleichen Weise funktioniert, aber besser in naheliegender Weise. Großartig.
Achte auf den Mann hinter dem Vorhang. :
Die Sache, die Release Early - Release oft tun möchte, ist, dass sie früh und schnell versagt haben, anstatt am Ende des Projekts, wenn es zu spät ist. Es bietet Ihnen mehr Möglichkeiten, dem Endkunden zu zeigen, was Sie bauen, wertvolles Feedback zu erhalten und sich zu geringeren Kosten anzupassen. Die Person in der Rolle "Kunde" muss die neueste Version problemlos abrufen können. spielen Sie damit und antworten Sie so regelmäßig wie möglich mit konstruktivem Feedback.
Falls Sie etwas Wichtiges erstellen, z. etwas, das ein Kraftwerk überwacht oder steuert, möchten Sie wahrscheinlich vorsichtig mit dieser Praxis sein. Sie wollen keine Leute mit Fackeln als Feedback für Ihre neue Version. In solchen Fällen ist es sinnvoll, regelmäßig auf einem Testbett zu stationieren, es für X Tage zu beobachten (gemäß Ihrem Konfidenzniveau) und dann LIVE zu gehen! Sie können Ihren Kunden Zugang zu diesem Testbett geben, um seinen Vertrauenszähler zu spielen und aufzubauen.
Wenn es eine nicht-kritische Anwendung ist und Sie eine gute historische Aufzeichnung von guten Veröffentlichungen hatten, dann machen Sie etwas wie ClickOnce .. aber stellen Sie auch sicher, dass es für den Kunden genauso leicht rückgängig zu machen ist.
Wenn Sie das tun, stellen Sie sicher, dass die Leute, die Ihr Produkt kaufen, für ein Jahr oder einen anderen Zeitraum kostenlose Upgrades auf neue Versionen erhalten, damit sie nicht das Gefühl haben, dass sie abgezockt wurden wenn eine neue Version 2 Monate nach dem Kauf einer Kopie herauskommt. Stellen Sie außerdem sicher, dass Sie ältere Versionen unterstützen, damit diejenigen, die nicht upgraden möchten, nur Fehlerbehebungen durchführen möchten, ohne dass sie riskieren, ihre aktuellen Installationen mit neuen Versionen der Software zu unterbrechen. Ich persönlich denke, dass es mehr Arbeit wird, aber Sie werden mit einem besseren Produkt enden, und Sie werden Leuten, die Ihre Software verwenden, erlauben, schneller von neueren Funktionen zu profitieren, wenn sie es wollen.
Wir führen eine SaaS-Anwendung aus, so dass sie im Prinzip so oft aktualisiert werden kann, wie wir möchten.
Andererseits werden in der Praxis nur wenige Hauptversionen pro Jahr veröffentlicht (kleinere Patch-Releases werden typischerweise alle paar Wochen veröffentlicht).
Der Grund dafür ist, dass Releases Unterbrechungen für das Betriebspersonal verursachen; manchmal muss ein Teil der Anwendung entfernt werden. Für Änderungen, die nicht auf den Kunden zugeschnitten sind, gibt es eine Menge Arbeit, die in die Freigabe des Releases im Gegensatz zum Engineering geht.
Obwohl StackOverflow anscheinend alle paar Tage aktualisiert wird, machen wir so etwas nicht. Mehrere Fehler können an einem Tag behoben werden, aber sie werden in einer nachfolgenden Version behoben, die als "Big Bang" ausgeht. Oder etwas.
Es hängt von Ihren Ressourcen ab. Wenn Sie MicroSoft sind, können Sie eine fehlerbehaftete POS, die sich mit Sista reimt, frühzeitig veröffentlichen und sich auf Ihre Marketing-Power verlassen, damit die Leute ihre frühen Erfahrungen mit dem Produkt vergessen.
Wenn Sie auf gute Mund-zu-Mund-Propaganda hoffen, ist die Veröffentlichung einer frühen Version keine gute Idee (es sei denn, Sie planen, den Namen oder etwas vor der endgültigen Veröffentlichung zu ändern).
Tags und Links release release-management