Despliegue automatizado utilizando el servidor de CI

Question

En nuestro proyecto, la implementación siempre es un problema, principalmente debido a los errores cometidos por el equipo de gestión de versiones. O arruinan la configuración o obtienen la versión incorrecta instalada de alguna manera. Utilizamos teamcity como nuestro servidor de CI, y produce los artefactos como archivos zip (dll y exe) que generalmente se pasan al equipo de publicación. Mi pregunta es, ¿hay alguna manera de automatizar todo el proceso de implementación?

¿Existe alguna herramienta comercial que admita esto?

Vamos a querer hacer lo siguiente:

• Actualizar los archivos de configuración con los valores específicos del entorno.

• Instalar servicios de Windows en el servidor.

• Cargue el paquete UI (WPF) en la ubicación centralizada (que se abre mediante otra aplicación, una especie de iniciador).

• Cambie las cadenas de conexión de base de datos.

hacer todo lo anterior para diversos entornos (como int, UAT y prod)

despliegue DB ya es una bestia separada, como tal, no necesita ser cubierto en este.

Las mejores prácticas, herramientas o soluciones serán de gran ayuda.

Gracias, -Mike

Answer 1

He utilizado TeamCity para algunos proyectos bastante grandes y he automatizado todos los aspectos de las implementaciones además de la base de datos. Los pasos principales que utilizo para cada proyecto son:

1. Consigue un agente TeamCity instalado en el servidor de producción
2. tienen la acumulación conseguir todo de control de código fuente (usted tiene todo en control de código fuente ¿verdad?).

3. Tiene un paso de compilación que se desarrolla y publica su solución. Esto se puede lograr mediante la adición de la siguiente argumento de línea de comandos para su llamada MSBuild:

   /p: Configuración = [Su Config]; DeployOnBuild = true; PackageAsSingleFile = False

   Los archivos publicados (y archivos de configuración tranformed) se escribirá en el directorio siguiente:

   [su proyecto del directorio] \ obj \ [su Config] \ Package \ PackageTmp

4. el uso de un lenguaje de script (en mi caso Powershell) para copiar los artefactos publicadas a su directorio de implementación y realice los cambios específicos del entorno que mencionó. P.ej. la extracción de archivos, copiar archivos, iniciar/detener sitios web, etc ..

5. Ejecutar cualquier prueba automatizado (por ejemplo nUnit, selenio, etc ...)

me parece la mejor estrategia es tener un .Net evento post-build que invoca un script apropiado de powershell pasando detalles relevantes como la ruta de la solución y el nombre de la configuración (alternativamente, también hice que TeamCity pase el nombre del entorno al script de Powershell) para que sepa lo que tiene que hacer (p. ej. , Producción, etc.). Debería encontrar que un lenguaje de scripts como Powershell puede hacer todo lo que puede hacer una persona (y aproximadamente 100x más rápido y 100% confiable).

Hay tanto contenido en Powershell que puedes buscar en google todo lo que necesites hacer en Powershell y obtendrás un ejemplo. P.ej. "PowerShell desplegar WPF", "PowerShell cargar FTP", etc.

En un trabajo anterior tenía que implementar servicios de Windows de forma remota y encontré que con suficiente investigación, pude obtener el MSI para que el servicio se desinstalara el servicio existente e instale el nuevo completamente silenciosamente (es decir, no hay cuadros de diálogo). Esto ayudará mucho en su búsqueda de automatización. Puedo explayarme sobre esto si lo desea.

A continuación se muestra un ejemplo de una secuencia de comandos posterior acumulación Powershell Yo generalmente uso:

Nota cómo utilizo algunos valores de los parámetros por defecto para que pueda ejecutar el script directamente de mi editor de Powershell para simular y probar diferentes configuraciones de mi máquina local.

param(
    [string]$configurationName="Debug", 
    [string]$sourceDirectory="C:\SVN\<Your local solution location>") 
Set-StrictMode -v latest 
$ErrorActionPreference = "Stop" 

# Load required functions 
$private:scriptFolder = & { (Split-Path $MyInvocation.ScriptName -Parent) } 
. (Join-Path $scriptFolder DebugBuild.ps1) 
. (Join-Path $scriptFolder StagingBuild.ps1) 
. (Join-Path $scriptFolder ProductionBuild.ps1) 
. (Join-Path $scriptFolder CommonBuildFunctions.ps1) 

#Execute appropriate build 
switch ($configurationName) { 
    "Debug" { RunDebugBuild $sourceDirectory } 
    "Staging" { RunStagingBuild $sourceDirectory } 
    "Production" { RunReleaseBuild $sourceDirectory } 
} 

para ejecutar una publican en las máquinas de desarrollo, I fijó un VS perfil de publicación para la solución que se ha comprometido a SVN por lo que los otros desarrolladores pueden usarlo. Este perfil se publica directamente en el directorio de implementación local.

Answer 2

Nuestro equipo de publicación utiliza Hormiguero Pro - esto también tiene capacidad de hacer CI, sino que sólo lo utilizan para distribuir paquetes (en nuestro caso sobre todo el código del sitio web). Lo bueno de Anthill es la configuración completa del servidor cliente (agente), por lo que atraviesa cortafuegos, NAT, etc. con cierto esfuerzo. Y tiene aprobación y programación de flujo de trabajo.

En cuanto a las configuraciones, esta es una bestia diferente. Desafortunadamente, tanto los desarrolladores como el equipo de lanzamientos tienen que cambiar estos, y de alguna manera fusionar el resultado. Considere que desea agregar una nueva clave de configuración, pero el equipo de publicación debe agregar configuraciones de producción para la conexión de BD. El truco es que los desarrolladores no deben saber la secuencia de conexión de DB de producción. Por lo tanto, esto no es automático (en nuestro caso, de todos modos).

Answer 3

Soy parcial de TeamCity, que es un producto de Jetbrains, la compañía que hace el ReSharper esencial (no, yo no trabajo para ellos, no tengo la suerte). TeamCity, al menos la última vez que lo comprobé, es un producto gratuito para hasta 20 usuarios y 20 configuraciones de compilación. Tiene algunas buenas características de autocompilación y culpa. Excelente, realmente.

Answer 4

usted menciona una herramienta comercial ...

TFS, o específicamente equipo de construcción, completamente apoya la construcción del código y su despliegue. Cada vez que creamos una aplicación web, se implementa automáticamente en nuestros servidores Dev y QA. Después del despliegue, lo procesamos a través de un conjunto de pruebas web para garantizar que todo esté funcionando. Entonces la verdadera diversión comienza con nuestro equipo QA;)

Aunque no implementamos automáticamente a la producción, sin duda podríamos hacer eso.

Answer 5

Utilizamos TeamCity para nuestras implementaciones además de CI y funciona muy bien. Aquí hay un par de cosas que pueden ayudar:

• Si está utilizando VS2010, consulte SlowCheetah plugin. Puede hacer que el archivo de configuración se transforme para hacer lo que necesita para reemplazar cadenas de conexión DB y otras variables sensibles al medio ambiente. Estas transformaciones ocurren automáticamente cuando construyes en base a la configuración de construcción seleccionada.
• Consulte MSDeploy. Si bien la mayor parte de su atención se centra en la implementación de aplicaciones web, puede hacer muchas otras cosas, como instalar servicios de Windows y sincronizar archivos en un directorio de destino. Si bien la mayoría de las personas lo instalan como un complemento de IIS, se puede instalar como un servicio independiente que no tiene dependencias en IIS.

Si no se está usando VS2010 (o no quieren utilizar SlowCheetah), así es como lo que podríamos manejar los ajustes de configuración:

• crear una aplicación de configuración para cada entorno diferente (I Supongo que tiene una configuración de compilación configurada para cada entorno). Agregue el nombre de configuración al final del archivo de configuración, por lo que en Prod tenemos App.config.Prod y QA tenemos App.config.QA.
• Ponga su configuración completa para cada entorno en su respectivo archivo de configuración para ese entorno.

• Como parte de su compilación (usamos el objetivo "BeforeBuild" en el archivo de proyecto), use msbuild para copiar el app.config ambientalmente específico sobre el real. Aquí hay un objetivo msbuild a medida que usamos para hacer esto:

  <PropertyGroup> 
      <EnvironmentAppConfig>App.config.$(Configuration)</EnvironmentAppConfig> 
  </PropertyGroup> 
  
  <Target Name="ReplaceAppConfig"> 
      <Message Condition="Exists('$(ProjectDir)$(EnvironmentAppConfig)')" 
         Text="Copying $(EnvironmentAppConfig) -> App.config" Importance="high" /> 
  
      <Message Condition="!Exists('$(ProjectDir)$(EnvironmentAppConfig)')" 
         Text="No $(EnvironmentAppConfig) found. Leaving App.config as is." Importance="high" /> 
  
      <Copy SourceFiles="$(ProjectDir)$(EnvironmentAppConfig)" 
        DestinationFiles="$(ProjectDir)App.config" 
        Condition="Exists('$(ProjectDir)$(EnvironmentAppConfig)')" /> 
  
  </Target> 
  

Avísame si necesita cualquier otro detalle.

Answer 6

TeamCity + Octopus desplegar

pulpo para el servicio automatizado ventanas despliega