Ich habe ein paar Fragen an die Azure-Gurus da draußen. Ich arbeite für ein Softwareentwicklungshaus und wurde gebeten, unsere Azure-Infrastruktur zu entwickeln. Meine Idee ist, drei Pay-As-You-Go-Abonnements für die folgenden Abteilungen einzurichten:
1) Produktion (Live-Umgebung). 2) Qualitätssicherung. 3) Testen.
Meine Fragen sind:
1) Können Ressourcen wie Websites, virtuelle Maschinen usw. beim Erstellen zwischen den verschiedenen Abonnements migriert werden? Hier ein Szenario: Angenommen, wir starten eine neue Anwendung, müssen sie aber zuerst testen. Also platzieren wir sie zunächst im Test. Sobald strenge Tests durchgeführt wurden, verschieben wir sie in die Qualitätssicherung. Danach verschieben wir sie in die Produktion (Live-Umgebung), wenn alle Qualitätsprüfungen abgeschlossen sind. 2) Ich entwickle außerdem eine Sicherheitsmatrix, in der ein Benutzer einer Abteilung nichts in einer anderen Abteilung ändern kann.
Was sagen Sie, meine Damen und Herren? Ist das machbar?
Antwort1
Michael – der von Ihnen verwendete Migrationsprozess hängt stark von der zugrunde liegenden Infrastruktur/dem von Ihnen verwendeten Dienst ab.
Als Ausgangspunkt würde ich vorschlagen, sich anzuschauen, wie Sie Build-Dienste nutzen können, um die von Ihnen erstellte Software automatisch bereitzustellen.MSDN-Dokumentationist ein guter Ausgangspunkt.
- Websites und Cloud-Dienste (Web- oder Worker-Rollen): Sie müssen Ihren Code erneut in der entsprechenden Instanz im richtigen Abonnement bereitstellen. Sie können die zugrunde liegende Hosting-Infrastruktur nicht „verschieben“.
- Auf virtuellen Maschinen gehostete Dienste: Sie können VMs zwischen Abonnements verschieben, aber das erfordert einen ziemlichen Aufwand, je nachdem, welche anderen Abhängigkeiten Sie haben (Netzwerke, Datenbanken usw.). Am besten versuchen Sie, denselben Ansatz zu verwenden, den Sie für Websites/Cloud-Dienste verwenden würden.
- Azure SQL-Datenbank: Sie müssen die Datenbank zwischen den Abonnements sichern/wiederherstellen.
- Andere Azure-Dienste: hängen stark von der Bereitstellung ab (entschuldigen Sie, wenn dies vage ist, aber in Azure gibt es viele bewegliche Teile).
In der Regel wäre es in Ihrem Szenario sinnvoll, nach Möglichkeiten zu suchen, die Bereitstellung/Neubereitstellung der von Ihnen erstellten Lösungen per Skript zu erstellen oder zu automatisieren.
Antwort2
Wir verwenden Visual Studio Online (VSO) für automatisierte Builds und Bereitstellungen in unseren verschiedenen Azure-Umgebungen. Dies funktioniert unabhängig davon, ob Sie Ihre Umgebungen nach unterschiedlichen Abonnements trennen oder unterschiedliche Ressourcengruppen im selben Abonnement verwenden.
Unser Setup besteht darin, dass bei jedem Code-Check-in ein Build erstellt wird, die Komponententests ausgeführt werden und bei erfolgreichem Auslösen eine Bereitstellung in der Testumgebung erfolgt.
Dann stellt unsere QA-Abteilung routinemäßig einen Build über VSO in die Warteschlange und wählt dabei einen bestimmten Änderungssatz/ein bestimmtes Datum aus. Wenn der Build und die Unit-Tests erfolgreich sind, wird eine Bereitstellung für die QA ausgelöst. Dieser Build wird technisch gesehen auch für die Produktion erstellt, wird aber nicht für die Produktion bereitgestellt.
Sie erledigen ihre gesamte Qualitätssicherungsarbeit und wenn alles gut läuft, geben sie ihre Zustimmung zu ihrer Seite der in VSO integrierten Gatekeeper-Logik ab. Wir haben es dann so eingerichtet, dass zwei weitere Personen die Freigabe dieses Builds für die Produktion (die sofort oder nach Zeitplan erfolgen kann) unterzeichnen müssen.
Wenn Sie vor Ort sind, können Sie stattdessen deren TFS verwenden, was im Wesentlichen dasselbe ist.
TLDR: Sie können dies über VSO erreichen und es zur Authentifizierung und Steuerung in Azure Active Directory integrieren.