Verhindern des Löschens von Benutzern beim Veröffentlichen eines DACPAC mithilfe von SqlPackage.exe

Question

Gibt es eine Möglichkeit zum Verhindern, dass Benutzer beim Veröffentlichen eines DACPAC mit SqlPackage.exe gelöscht werden, abgesehen von der Änderung der folgenden Einstellung, die verhindert, dass alle Objekte gelöscht werden, wenn sie nicht in der DACPAC.

<DropObjectsNotInSource>True</DropObjectsNotInSource> 

Wir stellen für eine Reihe von Umgebungen mit jeweils unterschiedlichen Benutzern bereit. Aktuelle Abhilfen sind entweder:

1. Script die Benutzer für jede Umgebung, sie neu zu erstellen, nachdem
2. Verwendung /Action:Script Bereitstellung und manuell den Deployment-Skript ändern.

dieser Weder sind zwar ideal ...

Answer 1

In der Version Februar 2015 gibt es (endlich) Unterstützung für das Ausschließen bestimmter Objekte, die nicht gelöscht werden sollen.

http://blogs.msdn.com/b/ssdt/archive/2015/02/23/new-advanced-publish-options-to-specify-object-types-to-exclude-or-not-drop.aspx

Answer 2

Wir behandeln diese in Skripten Post bereitstellen. Es ist ein bisschen schwieriger einzurichten, aber wenn es einmal eingerichtet ist, können Sie ein etwas anderes Skript für jede Umgebung konfigurieren. Wir verwenden dies in Verbindung mit Publish-Profilen mit einem anderen Profil pro Umgebung. Im Grunde verwenden Sie Powershell, um eine Reihe von Skripts für Benutzer und Berechtigungen zu generieren, fügen Sie diese Skripts zu Ihren Projekten hinzu und fügen Sie dann die Dateien in das Projekt ein. Fügen Sie dem Post-Deployment-Skript das hinzu, was im Blogpost als "SecurityAdditionsWrapper.sql" bezeichnet wird, und Sie sollten gut sein. Entfernen Sie einfach die andere Sicherheit aus Ihrem Projekt, um sicherzustellen, dass sie korrekt eingestellt ist.

http://schottsql.blogspot.com/2013/05/ssdt-setting-different-permissions-per.html

Es gibt auch Optionen in SSDT für: "Drop Berechtigungen nicht in der Quelle" - Falsch "Drop Rollenmitglieder nicht in der Quelle definiert" - Falsch "Berechtigungen ignorieren" - Wahre „Ignore Rolle Mitgliedschaft "- True

Wir verwenden diese, aber wenn Sie eine bessere Kontrolle über Ihre Benutzer/Berechtigungen durch die Umwelt benötigen, würde ich dringend empfehlen, diesen Blog-Post. (Mit Dank an Jamie Thomson für die ursprüngliche Idee.)

Answer 3

Ich stieß auf das gleiche Problem und verwendete Pre/Post Deployment-Skripte, um Benutzer, Berechtigungen, Rollen, etc. wie den vorgeschlagenen Blog-Post wieder einzufügen. Dies wurde jedoch auf lange Sicht nicht mehr aufrecht erhalten (Benutzer können sich während der Bereitstellung nicht authentifizieren. Wenn die Bereitstellung fehlschlägt, werden Berechtigungen nicht wiederhergestellt, Sicherheitsänderungen erfordern die Quellcodeverwaltung und erneute Bereitstellung).

Kürzlich habe ich das Problem neu bewertet, als wir unsere Bereitstellungsplattform migrierten. Mit der Freigabe DacFx API (und bug fixes) konnte ich den Bereitstellungsprozess in SSDT erweitern, indem ich einen DeploymentPlanModifier erstellte. Sie bieten eine , mit einfachen Modifikationen ich filter alle Tropfen für Erlaubnis basierte Objekttypen (mit /p:AdditionalDeploymentContributors Argument).

[ExportDeploymentPlanModifier(UserMappingFilter.PlanFiltererContributorId, "1.0.0.0")] 
public class UserMappingFilter : DeploymentPlanModifier 
{ 
    public const string PlanFiltererContributorId = "Dac.UserMappingFilter"; 

    protected override void OnExecute(DeploymentPlanContributorContext context) 
    { 
     DeploymentStep next = context.PlanHandle.Head; 
     while(next != null) 
     { 
      DeploymentStep current = next; 
      next = current.Next; 

      DropElementStep dropStep = current as DropElementStep; 
      if(dropStep != null && ShouldFilter(dropStep)) 
      { 
       base.Remove(context.PlanHandle, dropStep); 
      } 
     } 
    } 

    private bool ShouldFilter(DropElementStep createStep) 
    { 
     TSqlObject target = createStep.TargetElement; 


     if(target.ObjectType.Name == "RoleMembership" || target.ObjectType.Name == "User" || target.ObjectType.Name == "Role") 
     { 
      return true; 
     } 


     return false; 
    } 
} 

Answer 4

Verwendung SqlPackage.exe-Parameter (seit Februar 2015 Release: New Advanced Publish Options to Specify Object Types to Exclude or Not Drop):

Hier die aktuellen Parameter in unserer Bereitstellung verwenden:

/p:DropObjectsNotInSource=True 
/p:ExcludeObjectTypes=Users;Logins;RoleMembership;Permissions 

Die erste Zeile reinigt alle, aber die nächste Zeile weiter verfeinert, was nicht fallen zu lassen. Diese Kombination erwies sich als die effektivste Methode, um alle unnötigen Objekte zu löschen und trotzdem die Login-Mappings beizubehalten.

Ausführliche Dokumentation aller Parameter und ihre möglichen Werte können von MSDN - SqlPackage.exe