Hola Habr! Recientemente lanzamos una nueva versión de TeamCity - 2018.1. Este es el primer lanzamiento importante de nuestro servidor CI / CD este año. Y hay algo que mirar.
La lista completa de cambios es, como siempre,
impresionante . Pero aquí nos centraremos en cuatro características principales del lanzamiento. Vamos!
Nuevo TeamCity Kotlin DSL
TeamCity tiene su propio DSL (lenguaje específico de dominio), con el que puede describir la configuración de proyectos y configuraciones de compilación en el código de Kotlin, incorporando los principios de infraestructura como código. En 2018.1, modificamos significativamente el formato de este DSL, haciéndolo más simple, más conveniente y más funcional.
Más fácil El formato DSL se simplificó debido al hecho de que TeamCity ya no necesita un servidor uuid y un ID de proyecto, aprendió cómo generarlos independientemente del nombre del proyecto y las configuraciones de compilación. Aquí, por ejemplo, está todo el código necesario para describir un proyecto simple de "Hola mundo" en TeamCity:
version = "2018.1" project{ buildType(HelloWorld) } object HelloWorld : BuildType({ name = "Hellow world" steps { scriptContent = "echo 'Hello world!'" } })
Archivo único . Todo el código para describir la configuración de TeamCity ahora se almacena en un archivo: settings.kts, que debe agregarse al directorio .teamcity.
Portabilidad Dado que el código ahora no tiene enlace con un servidor o proyecto específico, puede reutilizarse para otras instalaciones o proyectos dentro del mismo servidor. Simplemente copie settings.kts en el repositorio apropiado.
Crea proyectos desde una URL . Para que TeamCity lea y aplique la configuración del código, es suficiente darle un enlace al repositorio con .teamcity / settings.kts. Todos los ajustes descritos se ejecutarán automáticamente.
Aquí hay una breve demostración de las nuevas características de Kotlin DSL de
antonarhipov (en inglés):
Alta disponibilidad y solo lectura
En 2018.1, se hizo posible iniciar el servidor en modo de solo lectura. Esto le permite configurar un clúster de TeamCity altamente accesible, que consta de dos servidores TeamCity: el principal y el de reserva, que funcionan en modo de solo lectura. En este caso, el servidor de solo lectura tendrá acceso de lectura a la base de datos y al directorio de datos, y bombeará constantemente las modificaciones de datos realizadas por el servidor principal. En el caso de una falla del servidor principal, el servidor de solo lectura aceptará todas las solicitudes. Es importante comprender que el servidor de solo lectura solo podrá mostrar el último estado en el momento del colapso del servidor principal, pero no permitirá cambiar este estado.
Esto es cierto para instalaciones grandes, que son importantes para tener acceso ininterrumpido al servidor CI, tanto durante fallas programadas como durante actualizaciones programadas.
Soporte Docker mejorado
Anteriormente escribimos sobre el hecho de que TeamCity admite Docker "fuera de la caja": iniciar compilaciones en el contenedor, crear imágenes de Docker, agregarlas y eliminarlas del repositorio, iniciar comandos de Docker, componer Docker.
Esta versión agrega soporte para los corredores .NET CLI y Powershell, lo que le permite completar estos pasos de compilación dentro del contenedor Docker.
El propio Docker Runner también se ha actualizado: admite de forma nativa build, push y otros.
Cómo funciona el soporte de Docker en TeamCity, puedes verlo en este video:
Almacenar artefactos en Amazon S3
El complemento TeamCity AWS S3 ya existe desde hace algún tiempo, pero en la versión 2018.1 solucionamos muchos problemas y lo incluimos en la distribución principal. La integración S3 maneja los artefactos de dependencia y artefactos de limpieza con tanta elegancia y está tan integrado en la interfaz de usuario de TeamCity que un usuario desprevenido puede no notar que los artefactos están almacenados en el bucket de S3.
Aquí hay una demostración:
Otras mejoras
Entre otras mejoras, vale la pena señalar un trabajo más conveniente con pasos de ensamblaje heredados de las plantillas. En particular, ahora es posible establecer pasos previos y posteriores en la plantilla e indicar que los pasos de configuración se encuentran entre ellos.
La nueva versión también mejoró significativamente el trabajo con NuGet feed. Ahora se puede habilitar a nivel de un proyecto específico, y no globalmente en todo el servidor, lo que causó problemas de rendimiento en el pasado. Como resultado, ahora se admiten varios feeds NuGet en diferentes proyectos.
Si algunos de sus servicios en la red funcionan para certificados SSL que no están firmados por una autoridad bien conocida, entonces, en lugar del complicado proceso de importar dichos certificados a servidores y agentes Java, simplemente puede cargarlos al proyecto del servidor raíz a través de una interfaz web conveniente. Tanto el servidor como los agentes comenzarán inmediatamente a usar los nuevos certificados.
Recientemente tuvimos un seminario
web , durante el cual
antonarhipov demostró todo lo anterior en acción. Puedes verlo en la entrada:
Puede descargar (así como ejecutar en AWS, en Azure o desde el contenedor Docker) la última versión de TeamCity 2018.1 desde nuestro
sitio web . Deje comentarios y sugerencias sobre la nueva versión en nuestro
rastreador de errores .
Le recordamos que TeamCity Professional proporciona 100 compilaciones de configuraciones y 3 compilaciones de un agente de forma totalmente gratuita , sin restricciones de tiempo y funcionalidad.
Que tengas una buena construcción!