In einer idealen Welt würden unsere Entwicklungsprozesse perfekt sein, was zu regelmäßigen Releases führen würde, die so gründlich getestet wurden, dass es niemals nötig wäre, eine laufende Anwendung "hochzufixen".
Aber leider leben wir in der realen Welt, und manchmal rutschen Käfer an uns vorbei und stellen ihre hässlichen Köpfe erst wieder her, wenn wir schon beim nächsten Release beschäftigt sind. Und der Fehler muss behoben werden Jetzt . Nicht als Teil der nächsten geplanten Veröffentlichung. Nicht heute Abend, wenn der Verkehr abflaut. Jetzt .
Wie gehen Sie mit diesem Bedürfnis um? Es kann wirklich gegen gute Design-Praktiken, wie Refactoring Ihres Codes in nette, diskrete Klassenbibliotheken laufen.
Das manuelle Bearbeiten von Markups und gespeicherten Prozeduren auf einem Produktionsserver kann ein Rezept für ein Desaster sein, aber es kann auch ein Desaster verhindern.
Was sind gute Strategien für Anwendungsdesign und Bereitstellungstechniken, um ein Gleichgewicht zwischen Wartungsbedarf und guten Programmierpraktiken zu finden?
[Obwohl wir viel testen, bevor wir es veröffentlichen,] Was wir machen ist das:
Unser SVN sieht so aus:
%Vor%Wenn wir jetzt veröffentlichen, erstellen wir ein Tag, das wir in der Produktion auschecken. Bevor wir mit der Produktion beginnen, führen wir eine Inszenierung durch, die [weniger Server] ist als die Produktion.
Gründe für die Erstellung eines "Tags" sind unter anderem, dass einige Einstellungen unserer App im Produktionscode geringfügig von "trunk" abweichen (zB werden keine Fehler per E-Mail gesendet, sondern protokolliert), daher ist es sinnvoll, das Tag zu erstellen und begehen diese Änderungen. Und dann am Produktionscluster auschecken.
Jetzt, wo immer wir ein Problem beheben müssen, reparieren wir es zuerst in Tags / x und dann in svn update vom Tag und sind gut. Manchmal gehen wir durch Staging, mit einigen Problemen (z. B. geringfügige / triviale Fixes wie Rechtschreibung) umgehen wir das Staging.
Beachten Sie nur, dass Sie alle Patches von tags/x auf trunk anwenden.
Wenn Sie mehr als einen Server haben, ist Capistrano äußerst hilfreich, um all diese Operationen auszuführen.
Eine Strategie besteht darin, deklarative externe Konfigurationsdateien für die verschiedenen Komponenten zu verwenden.
Beispiele hierfür:
Auf diese Weise können Sie Schlüsselkomponenten häufig in separate Teile zerlegen, eine laufende Anwendung hotfixieren, ohne sie neu zu kompilieren, und nahtlos die Quellcodeverwaltung verwenden (insbesondere im Vergleich zu gespeicherten Prozeduren, die normalerweise einen manuellen Aufwand für die Quellcodeverwaltung erfordern). p>
Wir teilen unseren Code in Framework-Code und Geschäftsanpassungen ein. Business-Customization-Klassen werden mit einem separaten Classloader geladen, und wir verfügen über ein Tool zum Übergeben von Änderungen an eine laufende Instanz der Produktion. Wann immer wir eine Änderung in einer Klasse benötigen, ändern wir sie und senden sie an eine laufende Instanz. Die laufende Instanz lehnt den alten Klassenlader ab und verwendet einen neuen Klassenlader, um die Klassen erneut zu laden. Dies ist vergleichbar mit Jboss Hot Deploy von EJBs.
Tags und Links language-agnostic maintenance deployment