Was ist die beste Lösung für den Umgang mit Multiplattform-Entwicklung (dev/integ/valid/prod...)? Auslieferungsprozess

Question

Ich bin nicht so erfahren, aber ich habe an einigen großen Java EE-Projekten (mit Maven2) gearbeitet, bei denen die Installation / Bereitstellung auf den verschiedenen Plattformen sehr unterschiedlich gehandhabt wurde.

1) Eine davon war, Snapshots für die Entwicklung zu verwenden und dann ein Maven-Release von Komponenten und Haupt-Webanwendungen zu erstellen. So ist die Lieferung:

• war/ear-Dateien
• Posten auflisten
• Eigenschaftsdateien
• sgdb-Dateien
• einige andere

Und die Teams werden diese Dateien verwenden, um die neuen Anwendungsversionen auf den verschiedenen Plattformen zu installieren. Ich denke, dieser Prozess ist streng und erlaubt es, die verschiedenen Konfigurationen, die in der Produktion übergeben werden, immer einfach zu halten, aber er ist nicht wirklich flexibel, der Prozess ist ein bisschen schwerfällig und er hat uns dazu gebracht, manchmal einige schmutzige Dinge zu tun, wie das Überschreiben einer Klasse eines War, um eine Regression zu patchen... Es handelt sich um eine E-Commerce-Website mit 10 Millionen Besuchern pro Monat und einer Verfügbarkeit von 99,89 %.

2) Eine andere Möglichkeit, die ich gesehen habe, ist, die Quellen auf jeder Plattform auszuchecken und dann die Snapshot-Artefakte in einem lokalen Repository zu installieren. Dann wird der Anwendungsserver diese Snapshots des Ordners .m2 verwenden. Es gibt keinen wirklichen Auslieferungsprozess, denn um eine neue Version in Produktion zu bringen, müssen wir nur die Quellen der Komponenten/Webapps aktualisieren, eine Maven Clean Install durchführen und den Anwendungsserver neu starten. Ich denke, es ist flexibler, aber ich sehe einige Nachteile und dieser Ansatz scheint mir gefährlich. Diese Website hat ein Frontoffice, ich kenne die Zahlen nicht, aber es ist viel weniger als die 1. Sie hat auch ein großes Backoffice, das für die meisten Mitarbeiter eines Unternehmens mit 130 000 Mitarbeitern zur Verfügung steht.

Ich denke, je nach Website, ihrer Darstellung in der Öffentlichkeit und der erforderlichen Verfügbarkeit müssen wir die Bereitstellungsstrategie an den Bedarf anpassen.

Ich bin nicht hier, um zu fragen, welche Lösung die beste ist, sondern frage mich, ob Sie verschiedene Dinge gesehen haben und welche Strategie Sie in welchem Fall anwenden würden?

Answer 1

Ohne mich mit Websites zu befassen, musste ich am Release-Management-Prozess für verschiedene große (Java-)Projekte in einer heterogenen Umgebung teilnehmen:

• Entwicklung auf "PC", d.h. in unserem Fall Windows - leider immer noch Windows Xp - (und Unit-Tests)
• Kontinuierliche Integration und Systemtests unter Linux (weil sie billiger zu installieren sind)
• Vorproduktion und Produktion auf Solaris (z. B. Sun Fire)

Die übliche Methode, die ich gesehen habe, war:

• Binärabhängigkeit (jedes Projekt verwendet die vom anderen Projekt erstellten Binärdateien, nicht deren Quellen)
• keine Neukompilierung für Integrationstests (die auf dem PC erzeugten Jars werden direkt auf Linux-Farmen verwendet)
• vollständige Neukompilierung in der Vorproduktion (d. h. die im Maven-Repository gespeicherte Binärdatei), um zumindest sicherzustellen, dass tout wird mit demselben JDK und den Verkaufsoptionen neu kompiliert.
• kein VCS (Version Control System, wie SVN, Perforce, Git, Mercurial, ...) auf einem Produktionssystem: alles wird von pre-prod durch rsynch bereitgestellt.

---

Die verschiedenen Parameter, die bei einem Freigabemanagementprozess zu berücksichtigen sind, sind also:

• Sind Sie bei der Entwicklung Ihres Projekts direkt von den Quellen oder den Binärdateien der anderen Projekte abhängig?
• Wo speichern Sie Ihre Einstellwerte?
  Parametrisieren Sie sie und wenn ja, wann ersetzen Sie die Variablen durch ihre endgültigen Werte (nur beim Start oder auch während der Laufzeit?)
• kompilieren Sie alles auf dem endgültigen (Vorproduktions-)System neu?
• Wie greifen Sie auf Ihr Produktionssystem zu, kopieren es und stellen es bereit?
• Wie können Sie Ihre Anwendungen stoppen/neustarten/patchen?

(und diese Liste ist nicht vollständig.
Je nach Art der Anwendungsfreigabe müssen weitere Aspekte berücksichtigt werden)

Answer 2

Die Antwort darauf ist je nach den genauen Anforderungen und Teamstrukturen sehr unterschiedlich.

Ich habe Prozesse für einige sehr große Websites mit ähnlichen Verfügbarkeitsanforderungen implementiert, und es gibt einige allgemeine Grundsätze, die sich meiner Meinung nach bewährt haben:

• Externalisieren Sie jede Konfiguration, so dass derselbe erstellte Artefakt in allen Ihren Umgebungen ausgeführt werden kann. Erstellen Sie die Artefakte dann nur einmal für jede Version - ein erneutes Erstellen für verschiedene Umgebungen ist zeitaufwändig und riskant, z. B. wenn es sich nicht um dieselbe Anwendung handelt, die Sie getestet haben.
• Zentralisierung des Ortes, an dem die Artefakte gebaut werden. - So müssen z.B. alle Warps für die Produktion auf dem CI-Server verpackt werden (das Maven Release Plugin auf Hudson funktioniert bei uns gut).
• Alle Änderungen zur Freigabe müssen nachvollziehbar sein (Versionskontrolle, Audit-Tabelle usw.), um Stabilität zu gewährleisten und schnelle Rollbacks und Diagnosen zu ermöglichen. Dies muss kein schwerfälliger Prozess sein - siehe den nächsten Punkt
• Automatisieren Sie alles: Erstellung, Tests, Freigabe und Rollbacks. Wenn der Prozess verlässlich, automatisierbar und schnell ist, kann derselbe Prozess für alles verwendet werden, von schnellen Korrekturen bis hin zu Notfalländerungen. Wir verwenden denselben Prozess für eine schnelle 5-Minuten-Notfallkorrektur und für eine größere Version, weil er automatisiert und schnell ist.

Einige zusätzliche Hinweise:

Siehe meine Antwort Standort des Platzhalters einer anderen Eigenschaft für eine einfache Möglichkeit, verschiedene Eigenschaften pro Umgebung mit Spring zu laden.

http://wiki.hudson-ci.org/display/HUDSON/M2+Freigabe+Plugin Wenn Sie dieses Plugin verwenden und sicherstellen, dass nur der CI-Server über die richtigen Anmeldeinformationen für die Durchführung von Maven-Releases verfügt, können Sie sicherstellen, dass alle Releases konsistent durchgeführt werden.

http://decodify.blogspot.com/2010/10/how-to-build-one-click-deployment-job.html Eine einfache Möglichkeit, Ihre Veröffentlichungen zu verteilen. Bei großen Websites benötigen Sie jedoch wahrscheinlich etwas Komplizierteres, um keine Ausfallzeiten zu verursachen - z. B. die gleichzeitige Bereitstellung für die Hälfte des Clusters und das Umschalten des Webverkehrs zwischen den beiden Hälften. http://martinfowler.com/bliki/BlueGreenDeployment.html

http://continuousdelivery.com/ Eine gute Website und ein Buch mit einigen sehr guten Mustern zum Freigeben.

Ich hoffe, das hilft - viel Glück.

Answer 3

Um meine vorherige Antwort zu ergänzen: Im Grunde handelt es sich um ein CM-RM-Problem:

• CM (Änderungsmanagement)
• RM (Freigabeverwaltung)

Mit anderen Worten: Nach der ersten Veröffentlichung (d. h. nach der anfänglichen Hauptentwicklung) müssen Sie weiterhin Veröffentlichungen vornehmen, und das ist es, was CM-RM verwalten soll.

Die Umsetzung des RM kann entweder 1) oder 2) in Ihrer Frage sein, aber mein Punkt wäre, diesen Mechanismus zu ergänzen:

• angemessenes CM, um alle Änderungswünsche zu verfolgen und ihre Auswirkungen zu bewerten, bevor eine Entwicklung in Angriff genommen wird
• ein angemessenes RM, um die "Release"-Tests (System-, Leistungs-, Regressions- und Bereitstellungstests) durchführen zu können, und dann die Freigabe selbst zu planen, zu terminieren, durchzuführen und zu überwachen.

Answer 4

Ohne zu behaupten, es sei ein am besten Lösung, so geht mein Team derzeit mit Staging und Bereitstellung vor.

• Die Entwickler entwickeln zunächst auf ihrem lokalen Rechner, das Betriebssystem ist frei wählbar, aber wir raten dringend dazu, dieselbe JVM zu verwenden, die auch in der Produktion eingesetzt wird.
• Wir haben eine DEV Server, auf den häufig Snapshots des Codes übertragen werden. Dies ist einfach ein scp aus dem von der IDE erzeugten binären Build. Wir planen jedoch, direkt auf dem Server zu bauen.
• En DEV Server wird von den Beteiligten genutzt, um die Entwicklung kontinuierlich mitzuverfolgen. Es liegt in der Natur der Sache, dass er unbeständig ist. Dies ist allen Nutzern dieses Servers bekannt.
• Wenn der Code gut genug ist, wird er verzweigt und in einem BETA Server. Auch dies ist eine scp eines binären Builds aus der IDE.
• Testen und allgemeine QA findet auf dieser Seite statt. BETA Server.
• In der Zwischenzeit haben wir für den Fall, dass dringende Änderungen an der derzeit in Produktion befindlichen Software erforderlich sind, einen dritten Staging-Server, den UPDATE Server.
• En UPDATE Server wird zunächst nur für sehr kleine Korrekturen verwendet. Auch hier verwenden wir scp um Binärdateien zu kopieren.
• Nachdem alle Tests an folgenden Stellen durchgeführt wurden UPDATE kopieren wir den Build von UPDATE a LIVE . Nichts geht jemals direkt an die Live-Server, sondern immer über den Update-Server.
• Wenn alle Tests abgeschlossen sind auf BETA wird der getestete Build vom Betaserver auf den UPDATE Server und eine abschließende Prüfung der Unbedenklichkeit wird durchgeführt. Da dies genau der Build ist, der auf dem Betaserver getestet wurde, ist es sehr unwahrscheinlich, dass in dieser Phase Probleme gefunden werden, aber wir halten uns an die Regel, dass alles, was auf dem Live-Server bereitgestellt wird, über den Update-Server läuft und dass alles auf dem Update-Server getestet werden sollte, bevor es weitergegeben wird.

Diese gleitende Strategie ermöglicht es uns, für 3 Versionen parallel zu entwickeln. Version N, die derzeit in Produktion ist und über den Update-Server bereitgestellt wird, Version N+1, die die nächste Hauptversion sein wird, die kurz vor der Veröffentlichung steht und auf dem Beta-Server bereitgestellt wird, und Version N+2, die die nächste Hauptversion ist, für die derzeit entwickelt wird und auf dem Entwicklungsserver bereitgestellt wird.

Einige der Entscheidungen, die wir getroffen haben:

• Eine vollständige Anwendung (eine EAR) hängt in der Regel von Artefakten aus anderen Projekten ab. Wir entscheiden uns dafür, die Binärdateien dieser anderen Projekte einzubinden, anstatt das Ganze aus dem Quellcode zu erstellen. Dies vereinfacht die Erstellung und bietet eine größere Sicherheit, dass eine getestete Anwendung mit genau den richtigen Versionen aller Abhängigkeiten gebündelt ist. Der Preis dafür ist, dass eine Korrektur in einer solchen Abhängigkeit manuell an alle Anwendungen verteilt werden muss, die davon abhängen.
• Die Konfiguration für jedes Staging ist in die EAR eingebettet. Wir verwenden derzeit eine Namenskonvention und ein Skript kopiert die richtige Version jeder Konfigurationsdatei an den richtigen Ort. Eine Parametrisierung des Pfades für jede Konfigurationsdatei, z. B. durch Verwendung eines einzelnen {stage}-Platzhalters in einer Root-Konfigurationsdatei, wird derzeit in Betracht gezogen. Der Grund, warum wir die Konfigurationsdatei in der EAR speichern, ist, dass die Entwickler diejenigen sind, die die Konfiguration einführen und von ihr abhängig sind, daher sollten sie auch für die Pflege verantwortlich sein (neue Einträge hinzufügen, unbenutzte entfernen, bestehende optimieren usw.).
• Wir verwenden eine DevOps Strategie für ein Einsatzteam. Es besteht aus einer Person, die nur Entwickler ist, zwei Personen, die sowohl Entwickler als auch Operator sind, und zwei Personen, die nur Operator sind.

Die Einbettung der Konfiguration in die EAR könnte umstritten sein, da der Betrieb traditionell die Kontrolle über z.B. die DB-Datenquellen haben muss, die in der Produktion verwendet werden (auf welchen Server sie zeigen, wie viele Verbindungen ein Verbindungspool haben darf usw.). Da wir jedoch Personen im Entwicklungsteam haben, die auch im operativen Bereich tätig sind, können sie die von anderen Entwicklern an der Konfiguration vorgenommenen Änderungen leicht auf ihre Richtigkeit überprüfen, während sich der Code noch in der Entwicklung befindet.

Parallel zum Staging führt der Continuous-Build-Server nach jedem Einchecken (maximal einmal alle 5 Minuten) einen skriptgesteuerten (ANT-)Build durch und führt Unit-Tests und einige andere Integritätstests durch.

Es bleibt schwierig zu sagen, ob dies eine best-of-breed und wir versuchen ständig, unseren Prozess zu verbessern.

Answer 5

Ich bin ein großer Befürworter einer ein einziges Deployment, das alles enthält (Code, Konfig, DB Delta, ...) für alle Umgebungen , die zentral auf dem CI-Server erstellt und freigegeben werden.

Die Hauptidee dahinter ist, dass Code, Config & DB Delta sind eng gekoppelt sowieso. Der Code ist davon abhängig, dass bestimmte Eigenschaften in der Config gesetzt sind und einige Objekte (Tabellen, Views, ...) in der DB vorhanden sind. Warum sollte man das also aufteilen und seine Zeit damit verbringen, alles zu verfolgen, um sicherzustellen, dass es zusammenpasst, wenn man es einfach von vornherein zusammen ausliefern kann.

Ein weiterer wichtiger Aspekt ist Minimierung der Unterschiede zwischen den Umgebungen um die Fehlerursachen auf ein absolutes Minimum zu reduzieren.

Mehr Details in meinem Kontinuierliche Bereitstellung über Parleys sprechen: http://parleys.com/#id=2443&st=5