¿Cuáles son las mejores prácticas de Team City para la implementación en varias etapas?

Tenemos 3 entornos:

  • Desarrollo: Team City se despliega aquí para commits de Subversion en trunk.
  • Staging: La aceptación del usuario se realiza aquí, en compilaciones que son candidatas a la versión.
  • Producción: Cuando se pasa UAT, el conjunto de código de paso se despliega aquí.

Estamos usando Team City y solo tenemos una configuración de integración Continua con nuestro entorno de desarrollo. No quiero guardar artefactos para cada implementación de desarrollo ese Team City sí. Quiero que una persona asignada pueda activar una configuración de compilación que implementará una cierta implementación de desarrollo exitosa en nuestro servidor de pruebas.

Entonces, quiero que cada implementación provisional guarde artefactos. Cuando una implementación provisional pasa UAT, quiero implementar ese paquete en Producción.

No estoy seguro de cómo configurar esto en Team City. Estoy usando la versión 6.5.4, y soy consciente de que hay un " Promover..."acción / disparador, pero creo que depende de guardado artefacto. No quiero guardar las implementaciones de desarrollo cada vez como artefactos, pero sí quiero que la persona que ejecuta la implementación en etapa pueda especificar qué implementación de desarrollo exitosa implementar en etapa.

Soy consciente de que puede haber múltiples maneras de hacer esto, ¿hay una mejor práctica? ¿Cuál es su configuración y por qué lo recomienda?

Actualización:

Tengo una respuesta hasta ahora, y es una idea que habíamos considerado internamente. Me gustaría saber si cualquiera tiene una forma algo automatizada de implementar en un entorno de puesta en escena/producción a través de la propia Ciudad del Equipo, donde solo las personas con cierto rol/permiso pueden ejecutar un script de implementación en producción en lugar de tener que lidiar manualmente con cualquier tipo de paquete de artefactos. ¿Alguien?

Actualización 2

Todavía tengo 1 día para otorgar recompensas, y pensé que la respuesta a continuación no respondía a mi pregunta, pero después de releerla veo que mi pregunta no era lo que pensé que era.

Son ¿hay alguna forma de usar Team City para algún tipo de implementación automatizada en entornos de producción/Puesta en escena?

Author: JustinP8, 2011-10-14
Source

3 answers

Creo que en realidad estás haciendo dos preguntas diferentes aquí; una es sobre el control de los derechos de acceso a las compilaciones de TeamCity y otra es sobre la logística de la gestión de artefactos.

Con respecto a los permisos, asumo lo que quiere decir con "solo las personas con cierto rol / permiso pueden ejecutar un script de implementación en producción" y su respuesta a Julien es que probablemente no desea que los desarrolladores implementen directamente en producción, pero quiere que puedan ver otras compilaciones en el proyecto. Esto es posiblemente también similar al escenario de Julien cuando luego toma el proceso "fuera de línea" de TeamCity (ya sea eso o simplemente está haciendo lo que hace e insistiendo en que deben usar un proceso separado y totalmente ineficiente porque "así es como lo hacemos" - ¡no me hagas empezar con eso!)

El problema es simplemente que todos los permisos en TeamCity se aplican contra el proyecto y nunca contra la compilación así que si tienes un proyecto con todas tus compilaciones, hay no se puede aplicar granularidad de permisos a las compilaciones de desarrollo frente a las de producción. Anteriormente he tratado esto de dos maneras:

  1. Manejarlo socialmente. Todo el mundo sabe cuáles son sus responsabilidades y no corres lo que no estás destinado a correr. Si lo haces, es auditado y rastreable hasta TI. Funciona bien cuando hay madurez, una idea clara de responsabilidades y no el requisito de cumplimiento que lo prohíbe.
  2. Crear proyectos separados. No me gusta tener que hacer esto pero soluciona el problema. Aún puede usar artefactos de otro proyecto, lo que significa que simplemente termina con un proyecto que contiene compilaciones que se implementan en entornos a los que todos los desarrolladores pueden acceder y otro proyecto en entornos sensibles. La desventaja es que si la compilación de producción falla, ¡las mismas personas de las que probablemente quieras soporte no podrán acceder a ella!

Con respecto a la gestión de artefactos, no hay problema con retenerlos en el compilación de desarrollo, simplemente defina una política de limpieza que solo guarde los artefactos de las últimas compilaciones de X si le preocupa la capacidad. Muchas personas quieren certeza de que están implementando el mismo resultado compilado en cada entorno, lo que significa que una vez que lo construyes, quieres mantenerlo para usarlo más tarde.

Una vez que tenga estos artefactos de su implementación de desarrollo, puede volver a implementarlos en sus otros entornos a través de compilaciones separadas. Tendrá un problema con las transformaciones de configuración (asumiendo usted los está usando), pero tenga una lectura de esta serie de 2 partes para algunas ideas sobre cómo abordar eso (todavía tengo que absorberlo en detalle, pero creo que está en el camino correcto).

¿Eso responde a tu pregunta? ¿Aún falta algo?

 15
Author: Troy Hunt,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2014-01-24 08:12:08

También usamos TeamCity como nuestro servidor de compilación, así que permítanme explicar nuestra configuración. Tenemos 4 ambientes

  • Desarrollo utilizado por Dev para verificar confirmaciones en un entorno de servidor
  • QA para fines de prueba
  • Preparación para comprobaciones de despliegue y algunos UAT
  • Producción

Solo usamos TeamCity para implementar en Desarrollo (Nightly builds) y en QA (bajo demanda). La compilación Dev usa la rama trunk y la compilación de QA usa una rama diferente RC.

La implementación en la etapa y la Producción son administradas por el equipo de TI y, por lo tanto, no están automatizadas.

Lo que hacemos en su lugar es que usamos TeamCity para producir artefactos a partir de la compilación de QA. Los artefactos son los kits de implementación enviados para implementaciones de Etapa / Producción.

Dicho esto, no estoy seguro de si TeamCity le proporcionaría un control completo sobre qué compilación puede promoverse a qué entorno. Básicamente controlamos esto en el lado SVN con ramas, y tenemos diferentes construcciones para esas ramas. Usted podría (debería) ser capaz de manejar esto de la misma manera. Por lo tanto, puede garantizar lo que se está implementando.

Entiendo que sus necesidades pueden ser ligeramente diferentes a las nuestras, pero espero que esto le ayude a encontrar la mejor configuración.

 8
Author: Julien Jacobs,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2011-10-31 19:00:03

Creo que deberías probar algo como Octopus Deploy o BuildMaster. Proporcionan una buena estructura para las prácticas de implementación que está tratando de automatizar. Ambas herramientas se integran muy bien con TeamCity.

Básicamente, seguiría utilizando TeamCity para CI, y también podría continuar implementando en su entorno de desarrollo con TeamCity, pero utilizaría una de las herramientas de implementación para promover una compilación (existente) a la etapa y producción.

Edit 2014-02-05-Update

Los creadores de BuildMaster tienen una nueva característica de despliegue – ProGet Deploy – para su herramienta de servidor NuGet, ProGet. Es muy similar a Octopus Deploy, aunque todavía no he jugado con él, por lo que Octopus puede tener una mejor visualización de qué versiones se han implementado en qué entornos; todavía uso BuildMaster debido a esa importante característica.

Además, actualmente estoy usando ambos TeamCity, BuildMaster, ProGet y yo nunca queremos volver a no tener compilaciones automatizadas. Actualmente, todas mis aplicaciones se crean e implementan a través de BuildMaster. Todos mis proyectos de biblioteca están integrados en TeamCity y se implementan en ProGet. Ser capaz de administrar mis dependencias internas a través de la infraestructura de NuGet es agradable.

 3
Author: Kenny Evitt,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2014-02-05 12:36:36