c# - Despliegue automatizado utilizando el servidor de CI

wpf msbuild

Question

En nuestro proyecto, la implementación siempre es dolorosa, principalmente debido a los errores cometidos por el equipo de gestión de lanzamientos. 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?

¿Hay alguna herramienta comercial que lo soporte?

Vamos a querer hacer lo siguiente:

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

• Instale los servicios de Windows en el servidor.

• Suba el paquete UI (WPF) a la ubicación centralizada (que se baja por otra aplicación, una especie de iniciador).

• Cambie las cadenas de conexión de DB.

Haz todo lo anterior para varios entornos (como int, uat y prod)

El despliegue de DB ya que es una bestia separada como tal, no necesita ser cubierto en esto.

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

Gracias, Mike

Answer 1

Nuestro equipo de lanzamiento utiliza Anthill Pro; esto también tiene la capacidad de hacer CI, pero solo lo usan para implementar paquetes (en nuestro caso principalmente código de sitio web). Lo bueno de Anthill es la configuración de todo el 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 lanzamiento tienen que cambiar esto y fusionar el resultado de alguna manera. 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. Entonces esto no es automático (en nuestro caso, de todos modos).

Answer 2

Soy parcial de TeamCity, que es un producto de Jetbrains, la compañía que fabrica 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 3

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

• Si usa VS2010, consulte el complemento SlowCheetah . 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.
• Echa un vistazo a 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 está usando VS2010 (o no quiere usar SlowCheetah), así es como podemos manejar la configuración de configuración:

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

• Como parte de su compilación (utilizamos el objetivo "BeforeBuild" en el archivo de proyecto), utilice msbuild para copiar la aplicación.config ambientalmente específica sobre la actual. Aquí hay un objetivo personalizado de msbuild 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íseme si necesita otros detalles.

Answer 4

Usted menciona una herramienta comercial ...

TFS, o específicamente Team Build, es completamente compatible con la construcción del código y su implementación. 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 de control de calidad;)

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

Answer 5

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 principales pasos que uso para cada proyecto son:

1. Obtenga un agente de TeamCity instalado en el servidor de producción
2. Haga que la compilación saque todo del control de la fuente (usted tiene todo en control de fuente ¿verdad?).

3. Tenga un paso de compilación que genere y publique su solución. Esto se puede lograr agregando el siguiente argumento de línea de comando a su llamada de MSBuild:

   / p: Configuración = [Su configuración]; DeployOnBuild = True; PackageAsSingleFile = False

   Sus archivos publicados (y los archivos de configuración transformados) se escribirán en el siguiente directorio:

   [Su directorio de proyectos] / obj / [Su configuración] / Package / PackageTmp

4. Usar un lenguaje de scripting (en mi caso, Powershell) para copiar los artefactos publicados en su directorio de implementación y realizar los cambios específicos del entorno que mencionó. Por ejemplo, extraer archivos, copiar archivos, iniciar / detener sitios web, etc.

5. Ejecute cualquier prueba automática (por ejemplo, nUnit, Selenium, etc.)

Encuentro que la mejor estrategia es tener un evento posterior a la creación de .Net que invoque una secuencia de comandos adecuada de powershell que transmita detalles relevantes como la ruta de la solución y el nombre de la configuración (alternativamente, también hice que TeamCity pasara el nombre del entorno al script de Powershell) que sabe lo que tiene que hacer (por ejemplo, estadificación, producción, etc.). Debería encontrar que un lenguaje de scripts como Powershell puede hacer todo lo que una persona puede hacer (y aproximadamente 100 veces más rápido y 100% confiable).

Hay tanto contenido en Powershell que puedes buscar todo lo que necesites hacer en Powershell y obtendrás un ejemplo. Por ejemplo, "powershell deploy WPF", "powerhell upload FTP", etc ...

En un trabajo anterior, necesité implementar servicios de Windows de forma remota y descubrí que, con suficiente investigación, pude obtener el MSI para que el servicio desinstale el servicio existente e instale el nuevo completamente en silencio (es decir, sin diálogos). 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 un script de compilación posterior de Powershell que generalmente uso:

Tenga en cuenta cómo uso algunos valores de parámetros predeterminados para poder ejecutar el script directamente desde mi editor Powershell para simular y probar diferentes configuraciones en 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 publicación en máquinas de desarrollo, configuro un perfil de publicación VS para la solución que está comprometida con SVN para que los otros desarrolladores puedan usarla. Este perfil se publica directamente en el directorio de implementación local.

Answer 6

Despliegue de Teamcity + Octopus

Octopus para implementaciones automatizadas del servicio de Windows