Verteilung von Konfigurationseinstellungen und Inhalten

SharePoint Sucks Als Antwort am 5 Aug. 2011 08:46

Hallo,

das Inhaltsbereitstellungsfeature könnte ggf. bei den Sitecollections helfen (bisher habe ich das aber nicht näher austesten können).

Die Konfig-Settings aus der Zentraladministration kann man aus meiner Sicht zu 99,9% nicht "deployen"! Was kann man überhaupt von der Test- bzw. Staging-Umgebung in eine Live-Umgebung deployen? NICHTS. Das ist ja ne Menge!

Ich sehe jede Umgebung mittlerweile als "Insel". Das heisst, dass bei Änderungen an Sitecollections oder entwickelten Webparts (fast immer) ein separates Deployment auf jeder Insel erneut erfolgen muss (teilweise auch von Hand, und das ist nicht im Ansatz "deployment"). Bei SharePoint kann man nicht in Produkten denken: was auf dem einen SharePoint (Test) läuft, kann nicht automatisch in eine Ziel-Umgebung deployt werden. Schade ...

(MfG) SharePoint Sucks!

Henning Eiben Als Antwort am 5 Aug. 2011 09:31

Das Übertragen von Konfigurationseinstellungen ist nicht so ohne weiteres Möglich.

Was du machen kannst, ist ein Backup von deinen Site-Collections in deiner Testumgebung, und dann dieses auf der Produktion wieder einspielen. Das funktioniert aber nur so lange, wie auf Produktion nicht eigene Inhalte eingestellt wurden.

Ansonsten solltest du alle Konfigurationsanpassungen auf der Test-Umgebung per Skript vornehmen. Das hat den Vorteil, dass du das gleiche Skript nach erfolgreichem Test auch auf die Produktionsumgebung anwenden kannst.

SharePoint Sucks Als Antwort am 5 Aug. 2011 09:46

Danke Henning ... ganz korrekt (vollständig) ist das aber noch nicht.

Die PowerShell Befehle können nicht ohne Änderung wiederverwendet werden, da sich Test- und Produktionsumgebung wohl bei der URL unterscheiden. Und alles was man von Hand an der Sitecollection geändert hat (z.B. Listenvorlagen), müsste manuell als Vorlage kopiert werden und in die Produktionsumgebung von Hand hochgeladen werden. Beim Aktivieren der Vorlage kam mir schon bei einer Release-gleichen (auch gleiches Patch-Level) SharePoint-Umgebung eine Korrelations-ID vor die Linse.

Fazit: von Deployment kann bei SharePoint nicht die Rede sein!

(MfG) SharePoint Sucks!

PS: SharePoint + "deployment" = Steinzeit

Henning Eiben Als Antwort am 5 Aug. 2011 16:37

Ich würde Listenvorlagen nicht unbedingt von Hand ändern. Wenn ich in einer verwalteten Umgebung arbeite, dann basieren mein Listenvorlagen auf List-Definitionen. Diese werden mit einem WSP auf dem Server installiert. Dieses WSP kann ich genauso auf dem Test und Produktionssystem einspielen. Will ich eine Anpassung machen, dann aktualisiere ich das WSP, spiele es neu ein und fertig.

Die Korrelations-ID sagt ja ersteinmal nichts aus - was für einen Fehler hattest du denn? Es kann ja auch an Inhalten im System liegen, oder unterschiedlichen Rechten. Vielleicht hast du die Vorlage auf Sites mit unterschiedlich aktivierten Features verwendet. Vielleicht waren Services auf dem einen System anders konfiguriert ... da gibt es viele Möglichkeiten, die auch bei gleichen Patch-Ständen zwischen zwei Systemen unterschiedliche sein können. Und schließlich kann deine Vorlage ja auch noch einen Fehler haben. Wenn die Vorlage nicht gut erstellt ist oder Fehlerhaft ist, dann funktioniert das Deployment auch nicht so richtig gut.

Dass so ein Deployment nicht einfach ist hat ja auch soweit erst einmal keiner behauptet. Wenn man ganz ordentlich deployen will, dann ist damit schon ein wenig Aufwand/Arbeit verbunden.

OK, du brauchst für einige Befehle die URL von Test und Produktion. Das betrifft aber idR ja nur den Hostname, denn die Struktur der Sites sollte ja identisch sein (weil mit gleichen Skripten erstellt). Das ist also eine Frage, wie intelligent du deine Skripte erstellst. Wenn du an allen möglichen Stellen immer wieder händisch die Portal-URL verwendest - tja, dann geht das mit dem Deployment nicht so gut. Wenn du aber z.B. eine Konfigurationsdatei verwendest, die die wichtigesten URLs beinhaltet, dann braucht man die nur einmalig zu erstellen.

Es kommt halt darauf an wie ordentlich du dein Deployment treibst.

MarioK Als Antwort am 5 Aug. 2011 21:48

Hallo,

also zum Thema Content Deployment von Inhalten einer Webanwendung kann ich nur sagen, es funktioniert!!! Wir nutzen bei uns im Unternehmen diese Funktion erfolgreich.

Wir nutzen dies für unser Redaktionssystem für unsere Internetseiten, genauer gesagt unsere Redakteure für die Internetwebseiten pflegen die Inhalte in einer SharePoint Umgebung welche sich in der Domäne befindet. Damit die Inhalte auch in die SharePoint Farm in der DMZ gelangen haben wir das Content Deployment eingerichtet.
Natürlich muss man auch hier einiges beachten, zum Beispiel sollten alle URLs  von internen Links welche im Redaktionssystem genutzt werden relative URL und keine absoluten URLs sein.

Soluions welche in ein Testsystem eíngespielt werden müssen natürlich auch in ein LiveSystem eingespielt und immer mit upgedatet werden. Sonst werden eigentlich alle Einstellungen, Inhalte und Designs innerhalb der zu veröffentlichten Websitecollection beim Content Deployment auf eine andere Farm übertragen.

Zu den Konfigurationen der Farm, helfen mir PowerShell Skripts die ich mir einmal erstellt habe und immer wieder schnell verwenden kann.

Kurz gesagt ContentDeployment funzt --> hat ja auch nur etwas mit Inhalten zu tun.

Gruß
Mario

share pointler Als Antwort am 8 Aug. 2011 10:49

Hallo zusammen,

interessante Diskussion die sich hier entwickelt hat...

Was ich daraus mitnehme und weitere Fragen:

• die Settings die ich in der Zentraladministration mache, kann man nicht systemübergreifend (Test -> Live) deployen. Auch nicht mit PowerShell Skripts. Hier ist reine Handarbeit gefragt - richtig ?
• Content Deployment z.B. ganzer SiteCollections mit PowerShell ist problemlos möglich. Das habe ich auch schon erfolgreich im Einsatz.
• Wie löst ihr aber das Problem, wenn ich z.B. 500 existierende Bibliotheken in meinen Sitecollections/Sites habe, und ich z.B. eine neue View einspielen möchte die ich ALLEN Bibliotheken bereitstelle will --> Skripte ? WSP ? etc ?
  Vielen Dank für einen möglichst detaillierten Lösungsweg bzw. eure Erfahrungen.

Henning Eiben Als Antwort am 8 Aug. 2011 10:58

Wie gesagt, wenn du die Settings per PowerShell einstellst, dann kannst du das auch "deployen", indem du das Skript sowohl auf Test als auch auf Produktion ausführst.

Das mit einer neuen View für 500 Listen - das ist schon ein kleines Problem. Das ist IMHO nicht vorgesehen. Dazu musst du Anpassungen an allen List-Instanzen machen. Ein neues WSP hilft da nicht. Per API kann man das ganze aber per Code anpassen. Somit könntest du dir eine Anwendung schreiben, die eine neue Ansicht für eine Mengen von Listen anlegt. Diese Anwendung kannst du dann sowohl auf Test als auch auf Produktion ausführen.

share pointler Als Antwort am 8 Aug. 2011 12:10

Hallo Henning,

ja - die Settings in der Zentraladministration per Skript umzusetzen wäre eine Möglichkeit. Habe ich gerade nochmals bei einer Einstellung getestet. Obwohl ich vmtl. die Einstellungen in der ZA weiterhin - soweit möglich - über die Oberfläche konfigurieren möchte. Jede einzelne Einstellung für die ZA zu skripten ist Stand heute ein zu großer Overhead.

Zu dem Punkt mit den Anpassungen an den 500 Bibliotheken. Das geht also nur über "Coding" via Visual Studio ?
Wie kann ich mir das grob vorstellen ? Ich schreibe Sourcecode der über alle 500 Bibliotheken bzw. Instanzen läuft und eine definierte View in jeder Instanz einfügt ?

Gilt dieses Vorgehen (Anwendung/Coding) auch, wenn man "nur" irgendwelche Standard-Bibliothekseinstellungen für alle Bibs anpassen will (z.B. "Inhaltsgenehmigung" von "Ja" auf "Nein" setzen) ?

Henning Eiben Als Antwort am 8 Aug. 2011 12:20

Also, es kommt halt drauf an was du genau machen willst. Aber mit Visual Studio hast du an dieser Stelle die meisten Möglichkeiten. Mit der API kannst du nahezu alle Einstellungen der Oberfläche vornehmen.

Das Vorgehen wäre dann in etwa wie von dir beschrieben. Also zunächst über alle Listen-Instanzen iterieren und dann dort eine Einstellung ändern.

Du könntest das auch per PowerShell machen, wobei du ggf. auch hier direkt auf die SharePoint-Assemblies zugreif müsstest, weil nicht alles in PowerShell-Cmdlets gekapselt ist. Daher würde ich gleich Visual Studio nehmen.