Usando Go CD con .NET

Me gustaría utilizar Go CD con proyectos de la API web .NET y Git.

Me gusta la idea de promocionar un artefacto de construcción específico para algunos entornos a través de tuberías. Actualmente estamos usando TeamCity y ramificándonos en Git. Usamos MSBuild para comstackr e implementar con una Transformación de configuration específica (Prueba, Puesta en escena, En vivo).

Nuestros arguments de command-line de MSBuild son los siguientes:

/p:Configuration=%DeployConfiguration% /p:Platform=AnyCPU /t:WebPublish /p:WebPublishMethod=FileSystem /p:DeleteExistingFiles=True /p:publishUrl=%DeployPath% 
  • %DeployConfiguration% es un parámetro para cada entorno; Test, Staging, Live y usa .NET Config Transforms para transformar Web.config para un entorno específico.
  • %DeployPath% es un parámetro para cada proyecto para cada entorno. Entonces AuthAPI Live sería algo así como: \\liveServer\path\to\AuthAPI\ .

Mi única pregunta con respecto a esto es: ¿Cómo usar una configuration de entorno específica (usando transformaciones de configuration .NET) cuando el artefacto de construcción se promueve a la siguiente etapa en la tubería? Entonces, por ejemplo, cuando la compilation se promueve para probar el entorno, quiero usar Web.Test.config, pero cuando se promueve el entorno de ensayo, quiero usar Web.Staging.config, etc.

También me gustaría saber si tiene alguna experiencia con Go CD con proyectos .NET.

No he experimentado el uso de Go CD con proyectos .NET, pero tal vez mi consejo sea útil.

1. Cree el file TransformStaging.csproj con contenido:

 <Project ToolsVersion="4.0" DefaultTargets="Transform" xmlns="http://schemas.microsoft.com/developer/msbuild/2003"> <Import Project="$(MSBuildProjectDirectory)\MSBuild\Microsoft.Web.Publishing.targets" /> <Target Name="Transform"> <Copy SourceFiles="$(Source)" DestinationFiles="$(Source).tmp"/> <TransformXml Source="$(Source).tmp" Transform="Web.Staging.config" Destination="$(Source)" /> </Target> </Project> 

2. Llamar a msbuild con

 msbuild.exe TransformStaging.csproj /p:Source=$configFilePath 

Hay partes de la configuration que son específicas del entorno (tendrá una connection db diferente para Dev, QA, UAT, entornos de producción, por ejemplo), y luego hay configuraciones que no cambian de un entorno a otro, llamemos a estos valores de configuration específicos de la aplicación. Un ejemplo de esto sería que usted configura un componente de registrador y sin tener en count en qué aplicación de entorno desea que los files de logging vayan a una determinada carpeta, c: \ logs.

Sugeriría mantener la configuration específica de la aplicación en su file App.Config (estos se implementan de un env a otro usando xcopy), pero los que son específicos del entorno, se eliminan. Implementación separada de la configuration del entorno desde la implementación de su aplicación. Deben implementarse en la máquina cuando está construida / configurada.

Las variables específicas del entorno se pueden configurar almacenadas en Variables de entorno del sistema operativo, Machine.config, location de file conocido, etc.

De esta manera, tu aplicación solo tiene que consultar: Environment.GetEnvironmentVariable ("MyAppDBName")
Y los entornos / serveres Dev, QA y Production tendrán respuestas diferentes.

Y desplegará los mismos binarys en cada entorno.

Nermin Dibek señala la forma correcta de hacer las cosas, pero me gustaría agregar algo más específico a su respuesta.

Implementé el process en mi organización y después de migrar a variables de entorno (con esto evitas comprometer el file de configuration que contiene keys secretas ( pérdidas de security)) , en GoCD hay un entorno de llamada de lugar que te permitirá personalizar la canalización donde estas corriendo. Por ejemplo, en mi Org tengo Staging env, Testing env, Prod y puede continuar tantas como quiera, esto le da una buena característica porque puede asignar a diferentes entornos diferentes agentes y diferentes canalizaciones, por ejemplo, solo estamos ejecutando testing unitaria en Pruebas así que pongo el agente más lento para esa tarea.