deployment - remotas - habilitar tcp/ip sql server 2012

¿Cómo despliego de forma programada los artefactos BIDS a la instancia remota de SQL Server?

Question

Me gustaría automatizar la implementación de mis artefactos SSIS y SSAS en instancias remotas de SQL Server 2005 y 2008 de forma programada.

¿Cuál sería la mejor solución para esto? Estoy usando TFS 2008 como el sistema de control de origen, por lo que me gustaría integrar la solución con MSBuild y una compilación de equipos programada.

Answer 1

No puedo ayudar con SSIS pero puedo ayudar con SSAS y TFS 2010.

Un proyecto de SSAS no se compilará con Team Build en 2010. Para que una compilación funcione se necesitará un proyecto de msbuild que llame a devenv.exe para hacer la compilación y luego copiar los archivos en el directorio de salida Team Build.

Aquí hay un proyecto de ejemplo que he usado antes:

    <Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
        <Target Name="Build">
             <PropertyGroup>
                  <DevEnvTool Condition="''$(DevEnvTool)''==''''">C:/Program Files (x86)/Microsoft Visual Studio 9.0/Common7/IDE/devenv.exe</DevEnvTool>
                  <DevEnvBuildCommand>"$(DevEnvTool)" "$(MSBuildProjectDirectory)/Nexus_VS2008.sln" /Build</DevEnvBuildCommand>
             </PropertyGroup>
             <Exec Command="$(DevEnvBuildCommand)" />
             <ItemGroup>
                 <SSASSourceFiles Include="$(MSBuildProjectDirectory)/Readify.Nexus.Analysis/bin/Readify.Nexus.Analysis.*"/>
             </ItemGroup>

             <Copy SourceFiles="@(SSASSourceFiles)" DestinationFolder="$(OutDir)" />
        </Target>
    </Project>

Esto creará los artefactos de SSAS en la carpeta desplegable de la compilación de TFS. Con un poco de powershell, los cubos de SSAS se pueden crear e implementar con la ayuda de TFS Deployer. Como mínimo, el script de powershell necesita ejecutar "microsoft.analysisservices.deployment.exe". El script también se puede usar para cambiar varias configuraciones de configuración para SSAS.

Answer 2

En primer lugar, siempre recomiendo separar los procesos de compilación e implementación. No son lo mismo, y la separación facilita el uso de flujos de trabajo de administración de configuración más maduros. Un ejemplo de esto sería ser capaz de promover una compilación previa (que ha pasado por un entorno de sistema y dado el todo claro) a un entorno UAT como candidato de lanzamiento. No desea reconstruir para realizar esto. Capture sus artefactos de construcción e impleméntelos por separado.

De todas formas...

SSIS es bastante sencillo: todo lo que hace la compilación es copiar paquetes en la carpeta de salida, por lo que solo necesita capturarlos de alguna manera (depende de lo que use para compilar - Uso TeamCity). Luego, en su proceso de implementación, puede usar fácilmente SMO para subirlos al servidor SSIS:

$app = new-object Microsoft.SqlServer.Dts.Runtime.Application
$app.SaveToSqlServerAs($packageObj, $null, "//$folderName/$($packageObj.Name)$packageNameSuffix", $serverName, $null, $null);

(Curiosamente, esto no parece ir a través del servicio SSIS en sí, sino a través de la API proc almacenada MSDB. No importa que sea muy diferente, pero funciona incluso cuando el usuario no tiene acceso al servicio SSIS de forma remota porque de ese problema DCOM )

SSAS es mucho más difícil. Aunque puede hacer un montón de cosas con AMO , lo cual hago como parte de mis implementaciones, nunca he encontrado una manera fácil de tomar los resultados de la compilación de la solución (como el archivo .asdatabase) y convertirlos en el XMLA requerido para crear el esquema de la base de datos olap desde cero. Falta una transformación, que no me molestaría escribir.

En su lugar, utilizo la utilidad de implementación SSAS , que se puede utilizar desde la línea de comandos como parte de un proceso de implementación, hacer que genere el XMLA y luego ejecutarlo:

$asDeploy = "$programfiles32/Microsoft SQL Server/100/Tools/Binn/VSShell/Common7/IDE/Microsoft.AnalysisServices.Deployment.exe"

write-host "Generating XMLA"
start-process -wait -FilePath:$asDeploy -ArgumentList:"$pwd/../bin/MyOlap/MyOlap.asdatabase","/d","/o:$pwd/MyOlap.xmla"
if (-not $?){
    throw "Failed to generate XMLA: errors were reported above";
}

write-host "Deploying SSAS Database"
./ascmd.exe -S $olapServer -i "$pwd/MyOlap.xmla"
if (-not $?){
    throw "Failed to deploy cube: errors were reported above";
}

Me aseguro de que la implementación anterior no procese el cubo (vuelvo a escribir el archivo .deploymentoptions) para poder utilizar de forma secundaria AMO para ejecutar el cubo implementado y actualizar las fuentes de datos según sea necesario para ese entorno. Entonces comienzo un proceso.

No lo hizo, pero para SSRS puede tomar los RDL de la compilación y usar la API de servicio web para implementarlos, y obviamente para las bases de datos que usaría un proyecto SQL GDR, y usar allí la herramienta de implementación de línea de comandos. En conjunto, puede implementar un proyecto completo de BI a partir de un único script con un control bastante estricto sobre el control de versiones, etc.

He utilizado estos enfoques durante los últimos 5 años más o menos en varios proyectos, y acrued una biblioteca de PowerShells realmente útil para hacer esto. Un día los limpiaré y los liberaré.

[17 / mayo] Nota: la versión SQL 2008 R2 del asistente de implementación (en la carpeta SQL / 100 /) está marcada como una aplicación GUI, no como una aplicación de consola (como 2005), por lo que el script escrito anteriormente no funciona ¡espero a que se complete! El código anterior cambió para usar el proceso de inicio con ''-wait'' explícito en su lugar. Este es un juego desagradable .

Answer 3

Encontré muchas publicaciones que abogaban por la creación de scripts VS para automatizar la compilación, lo que no siempre es posible en un entorno de CI.

Con un poco más de excavación también encontré http://sqlsrvanalysissrvcs.codeplex.com/ que incluye una tarea msbuild para crear archivos .asdatabase en msbuild.

Answer 4

SSIS es el más fácil, cuando estaba usando SSIS, almacenamos nuestros paquetes en un archivo y todo lo que teníamos que hacer era copiar el archivo al directorio correcto en C: / Archivos de programa / Microsoft SQL Server / 90 / DTS / Packages. Lo cual puedes hacer agregando una tarea de copia al final de tu MSBuild. No estoy seguro de si el xml estará disponible de forma predeterminada en el directorio de salida, así que ten cuidado.

En cuanto a SSAS, nunca llegué a automatizarlo, pero, querrás ver Analysis Analysis Objects (AMO), sacando de Books en línea dice:

Analysis Management Objects (AMO) proporciona una interfaz programática para el conjunto completo de comandos para Analysis Services disponible para el desarrollador. Por lo tanto, AMO se puede utilizar para la implementación y también para los muchos comandos administrativos que de otro modo es compatible. Para obtener más información sobre el usuario de AMO para automatizar cualquier tipo de tarea administrativa, vea Objetos de administración de análisis (AMO).