Ich verwende Teamcity, um die Bereitstellung in der QA-Umgebung zu automatisieren (Einzelklick). Momentan werden Inhaltselemente bereitgestellt, aber die QA-Mitglieder müssen dann manuell eine erneute Veröffentlichung der Site auslösen.
Gibt es trotzdem die Verwendung von TDS, Sitecore Rocks oder A.N.Other, um die erneute Veröffentlichung am Ende des Bereitstellungsprozesses zu automatisieren.
Ich weiß, dass ich Sitecore so konfigurieren kann, dass es automatisch alle x Minuten veröffentlicht, aber ich möchte das deaktiviert lassen, da QA auch Lasttests durchführt und ich möchte nicht, dass der Scheduler in die Quere kommt.
Wir haben dies getan, indem wir auf unseren täglichen Build- und QA-Websites einen ASPX eingerichtet haben, der eine Veröffentlichung auslöst. Der Build hat dann einen Powershell-Aufruf, um dies auszulösen. Das haben wir mit CruiseControl, TeamCity und Team Build gemacht.
Die Konfiguration für TeamCity verwendet einen zusätzlichen Build-Schritt, nachdem Sie Dateien und TDS bereitgestellt haben:
Skriptquelle:
$ r = [System.Net.WebRequest] :: Erstellen ('http: //myqasite/SomePath/Publish.aspx'); $ resp = $ r.GetResponse ();
Der Code für unsere Veröffentlichungsseite lautet etwa so:
%Vor%Während ich auf eine Antwort wartete, teilte ich die Frage auf Twitter, woraufhin Stephen Pope ( seinerseits eine leitende Hand erhielt) Antwort ) Er schlug vor, die PowerShell-Erweiterungen von Sitecore Rocks zu verwenden, es dauerte eine Weile (Dokumentation ist dünn auf dem Boden), aber Ich habe das Ergebnis erreicht, nach dem ich gesucht habe:)
Als eine Aufzeichnung von dem, was ich gefunden habe, wird das folgende als eine mögliche Antwort auf meine eigene Frage zur Verfügung gestellt, obwohl großer Dank an Jay S, die Lösung hätte ich verwendet, wenn nicht für das ..
Wie auch immer .. Mit einem zusätzlichen Build-Schritt in der Build von Teamcity habe ich folgendes:
Skriptquelle:
Import-Modul '. \ Build-Module \ SiteCore \ SiteCore.psd1';
Neu -PsDrive
-name "rockt" -psp SitecoreRocks -root "" -host "% QA.Url%" -usr "% QA.sitecore.user%" -pwd "% QA.sitecore.password%" -databaseName "Master" -scope "Skript";
Set-Standort Felsen:
Publish-SCDatabase;
Die Magie passiert innerhalb des Publish-SCDatabase-Befehlsletts, das beim Ausführen von Get-Help eine Reihe von Parametern anzeigt, es stellt sich heraus, dass nur zwei der Parameter verwendbar sind -Name und - Modus
Es war unmöglich, eine Dokumentation zu finden, die über den oben genannten vs-plugins-Link hinausging. Ein bisschen Internet-Reflektion und eine gute Portion Geduld zeigen, dass die Parameter die folgenden Optionen haben:
Natürlich wäre eine bessere Dokumentation und möglicherweise zusätzliche Informationen über das Get-Help-Kommando schön. Wenn das Rocks-Projekt Open Source wäre, hätte ich das Projekt vielleicht gegabelt, um zusätzliche Hilfe zu generieren.
Nun, da es zwei sehr gute Lösungen für diese Frage gibt, werde ich die Stimmen der Völker entscheiden lassen, welche die beste Antwort ist. In ein paar Tagen werde ich die Stimmen überprüfen und die am meisten gewählte Stimme als akzeptierte Antwort markieren.
>Whist diese beiden sind gute Lösungen (die benutzerdefinierte aspx und die Powershell über Rocks one), sie haben beide einige Mängel.
Benutzerdefinierte aspx-Seite. Es sei denn, Sie gehen in Ihrer C # -Lösung zur Veröffentlichung in die Stadt, um eine sehr ausgefeilte Möglichkeit zum Ändern von Veröffentlichungszielen, Root-Knoten und anderen Optionen (z. B. intelligent, inkrementell) zu bieten und den Aufruf dieser Optionen so flexibel wie möglich zu ermöglichen Sie riskieren, dass Sie Ihren Code ändern müssen, um die Bereitstellungsstrategien in regelmäßigen Abständen zu ändern. Der Kommentar von Richard R unter der Rocks-Antwort räumt das ein. Vergleichen Sie das mit einer Art Skriptlösung. Die Tatsache, dass es kein kompilierter Code sein würde, eignet sich dazu, gehackt und verändert zu werden und sich sogar zu vielen verschiedenen Skripten für verschiedene Zwecke zu vermehren.
Powershell über Rocks. Auch hier gibt es Mängel bei der Anpassung. Sie sind darauf beschränkt, welche Commandlets (und letztendlich CRUD-Operationen) von dieser bestimmten Implementierung unterstützt werden. Ganz zu schweigen davon, dass es sich um eine geschlossene Quelle und begrenzte Dokumentation handelt.
Ich muss wahrscheinlich ein wenig über die Anwendungsfälle, die ich im Hinterkopf habe, etwas näher ausführen. Was ist, wenn es für uns besonders wichtig ist, nur Teile des Inhaltsbaums auf Deploys zu veröffentlichen (Aspekte wie / templates, / system, / layouts)? In unseren Bereitstellungen haben wir riesige / content und / media library Sektionen, deshalb ist es wesentlich präziser, was für bestimmte Bereitstellungen veröffentlicht wird, um die Bereitstellung zu beschleunigen. Nun, während es durchaus möglich ist, eine eigene /Publish.aspx-Seite zu erstellen, die die Root-Elemente angibt und diese (tief) für Sie veröffentlicht, wäre es viel eleganter, dies über eine Art Skript zu tun. Nicht nur das, sondern auch die unzähligen anderen Operationen, die Sie vielleicht bei Scripted-Bereitstellungen und Umgebungseinstellungen automatisieren möchten, wie z. B. das Hinzufügen von Inhalten und die Anwendung von Workflows e.t.c.
Vergleiche beides mit Adam Najmanowicz 'PowerShell Console / Extensions. Wenn Sie Powershell-Skripte in Sitecore entwickeln können, können Sie mit einer Skripts-Lösung effektiv erstellen und sogar von einem externen Tool aus aufrufen, um dies zu einem Schritt in einem CI-Server oder Orchestrator zu machen: Ссылка
Tags und Links continuous-integration sitecore sitecore6 tds