deployment - tool - ¿Cuáles son las mejores prácticas de Team City para el despliegue de múltiples etapas?

teamcity is a build scheduler or build tool

Question

Disponemos de 3 entornos:

• Desarrollo: Team City se despliega aquí para los envíos de Subversion en el troncal.
• Puesta en escena: la aceptación del usuario se realiza aquí, en las compilaciones que son candidatos de lanzamiento.
• Producción: cuando se pasa UAT, el conjunto de códigos de paso se implementa 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 que hace Team City. Quiero que una persona asignada pueda disparar una configuración de compilación que implementará un cierto despliegue de desarrollo exitoso en nuestro servidor de pruebas.

Luego, quiero que cada despliegue de prueba guarde los artefactos. Cuando una implementación de prueba 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 una acción / activador "Promocionar ...", pero creo que depende de los artefactos guardados. No quiero guardar las implementaciones de desarrollo cada vez como artefactos, pero sí quiero que la persona que ejecute la implementación de prueba pueda especificar qué implementación de desarrollo exitosa implementará en la organización.

Soy consciente de que puede haber varias formas de hacer esto, ¿existe una mejor práctica? ¿Cuál es su configuración y por qué la recomienda?

Actualizar:

Tengo una respuesta hasta ahora, y es una idea que hemos considerado internamente. Realmente me gustaría saber si alguien tiene una forma un tanto automatizada de implementar en un entorno de almacenamiento / producción a través de Team City, 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. ¿Nadie?

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.

¿Hay alguna forma de usar Team City para algún tipo de implementación automatizada en entornos de producción / estadificación?

Answer 1

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

Con respecto a los permisos, asumo lo que quiere decir con que "solo las personas con cierto rol / permiso pueden ejecutar un script de implementación para la producción" y su respuesta a Julien es que probablemente no desee que los desarrolladores se implementen directamente en la producción, pero sí quiere que sean Capaz de ver otras construcciones en el proyecto. Es posible que esto también sea similar al escenario de Julien cuando, a continuación, el equipo de TI desconecta el proceso de TeamCity (ya sea eso o simplemente hace lo que hace la TI e insiste en que debe usar un proceso separado, completamente 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 al proyecto y nunca a la compilación, por lo tanto, si tiene un proyecto con todas sus compilaciones, no hay capacidad para aplicar la granularidad de permisos a las compilaciones de producción en comparación con las de producción. Anteriormente he tratado esto de dos maneras:

1. Manejarlo socialmente. Todos saben cuáles son sus responsabilidades y usted no ejecuta lo que no debe correr. Si lo haces, es auditado y rastreable a USTED. Trabaje bien cuando haya madurez, una idea clara de responsabilidades y no un requisito de cumplimiento que lo prohíba.
2. Crear proyectos separados. No me gusta tener que hacer esto pero soluciona el problema. Aún puede usar artefactos de otro proyecto y significa que simplemente termina con un proyecto que contiene compilaciones que se despliegan en entornos a los que está feliz para que todos los desarrolladores accedan y otro proyecto para entornos sensibles. El inconveniente es que si la compilación de producción falla, la gente de la que probablemente quiera contar con soporte no podrá acceder a ella.

Con respecto a la administración de artefactos, no hay ningún problema en mantenerlos en la compilación de desarrollo, simplemente defina una política de limpieza que solo mantenga los artefactos de las últimas compilaciones de X si le preocupa la capacidad. Mucha gente quiere tener la certeza de que está implementando la misma salida compilada en todos los entornos, lo que significa que una vez que la construya, querrá mantenerla para su uso posterior.

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 que las está utilizando), pero lea esta serie de 2 partes para obtener algunas ideas sobre cómo abordar eso (todavía no lo he analizado en detalle, pero creo que está en el camino correcto).

Eso responde tu pregunta? ¿Hay algo que todavía falta?

Answer 2

Creo que es posible que desee revisar algo como Octopus Deploy o BuildMaster . Proporcionan una buena estructura para las prácticas de implementación que está intentando automatizar. Ambas herramientas se integran muy bien con TeamCity.

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

Edición 2014-02-05 - Actualización

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

Además, actualmente estoy usando TeamCity, BuildMaster y ProGet y nunca quiero volver a no tener compilaciones automatizadas. Actualmente, todas mis aplicaciones se crean y despliegan a través de BuildMaster. Todos mis proyectos de biblioteca están integrados en TeamCity y se implementan en ProGet. Poder administrar mis dependencias internas a través de la infraestructura de NuGet es bueno .

Answer 3

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

• Desarrollo utilizado por Dev para verificar las confirmaciones en un entorno de servidor.
• Control de calidad para fines de prueba
• Puesta en escena para verificaciones de despliegue y algunos UAT
• Producción

Solo usamos TeamCity para implementar en Desarrollo (compilaciones nocturnas) y para control de calidad (a pedido). La compilación Dev usa la rama troncal y la compilación QA usa una ramificación diferente que se usa para el RC.

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

Lo que hacemos en cambio es que usamos TeamCity para producir artefactos a partir de la compilación de control de calidad. Los artefactos son los kits de implementación enviados para las implementaciones de producción / 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 sucursales, y tenemos diferentes compilaciones para esas sucursales. Usted podría (debería) ser capaz de manejarlo de la misma manera. Por lo tanto, puede asegurarse de lo que se está desplegando.

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