Olá Habr! Recentemente, lançamos uma nova versão do TeamCity - 2018.1. Este é o primeiro grande lançamento do nosso servidor de CI / CD este ano. E há algo para olhar.
A lista completa de mudanças é, como sempre,
impressionante . Mas aqui vamos nos concentrar em quatro características principais do lançamento. Vamos lá!
Nova DSC do TeamCity Kotlin
O TeamCity possui sua própria DSL (Linguagem Específica de Domínio), com a qual você pode descrever as configurações dos projetos e criar configurações no código Kotlin, incorporando os princípios de Infraestrutura como Código. Em 2018.1, reformulamos significativamente o formato deste DSL, tornando-o mais simples, mais conveniente e mais funcional.
Mais fácil . O formato DSL foi simplificado devido ao fato de o TeamCity não precisar mais de um servidor uuid e um ID do projeto, ele aprendeu como gerá-los independentemente do nome do projeto e criar configurações. Aqui, por exemplo, está todo o código necessário para descrever um simples projeto "Hello world" no TeamCity:
version = "2018.1" project{ buildType(HelloWorld) } object HelloWorld : BuildType({ name = "Hellow world" steps { scriptContent = "echo 'Hello world!'" } })
Arquivo único . Todo o código para descrever as configurações do TeamCity agora está armazenado em um arquivo - settings.kts, que deve ser adicionado ao diretório .teamcity.
Portabilidade . Como o código agora não tem ligação a um servidor ou projeto específico, ele pode ser reutilizado para outras instalações ou projetos no mesmo servidor. Apenas copie settings.kts para o repositório apropriado.
Crie projetos a partir de uma URL . Para que o TeamCity leia e aplique as configurações do código, basta fornecer um link para o repositório com .teamcity / settings.kts. Todas as configurações descritas serão executadas automaticamente.
Aqui está uma breve demonstração dos novos recursos Kotlin DSL da
antonarhipov (em inglês):
Alta disponibilidade e somente leitura
Em 2018.1, tornou-se possível iniciar o servidor no modo somente leitura. Isso permite configurar um cluster TeamCity altamente acessível, composto por dois servidores TeamCity: o principal e o sobressalente, trabalhando no modo somente leitura. Nesse caso, o servidor somente leitura terá acesso de leitura ao banco de dados e ao diretório de dados e aumentará constantemente as modificações de dados executadas pelo servidor principal. No caso de uma falha do servidor principal, o servidor somente leitura aceitará todas as solicitações. É importante entender que o servidor somente leitura somente poderá mostrar o último estado no momento do colapso do servidor principal, mas não permitirá alterar esse estado.
Isso vale para instalações grandes, que são importantes para ter acesso ininterrupto ao servidor de IC, durante falhas agendadas e durante atualizações agendadas.
Suporte aprimorado ao Docker
Anteriormente, escrevemos sobre o fato de o TeamCity suportar o Docker "pronto para uso": iniciando compilações no contêiner, criando imagens do Docker, adicionando e removendo-as do repositório, iniciando comandos do Docker, compondo o Docker.
Esta versão adiciona suporte para os corredores .NET CLI e Powershell, que permitem concluir essas etapas de compilação dentro do contêiner do Docker.
O próprio Docker runner também foi atualizado: suporta nativamente build, push e outros.
Como o suporte ao Docker funciona no TeamCity, você pode ver neste vídeo:
Armazenar artefatos no Amazon S3
O plugin TeamCity AWS S3 já existe há algum tempo, mas na versão 2018.1 corrigimos muitos problemas e o incluímos na distribuição principal. A integração do S3 lida com artefatos de dependência e artefatos de limpeza com tanta elegância e é tão integrada à UI do TeamCity que um usuário desavisado pode não perceber que os artefatos estão armazenados no bucket do S3.
Aqui está uma demonstração:
Outras melhorias
Entre outras melhorias, vale destacar um trabalho mais conveniente com as etapas de montagem herdadas dos modelos. Agora, em particular, agora é possível definir etapas pré e pós no modelo e indicar que as etapas de configuração estão entre elas.
A nova versão também melhorou significativamente o trabalho com o feed NuGet. Agora, ele pode ser ativado no nível de um projeto específico, e não globalmente em todo o servidor, o que causou problemas de desempenho no passado. Como resultado, vários feeds do NuGet em diferentes projetos agora são suportados.
Se alguns de seus serviços na rede funcionarem para certificados SSL que não são assinados por uma autoridade conhecida, em vez do processo bastante complicado de importar esses certificados para servidores e agentes Java, você pode simplesmente carregá-los no projeto do servidor raiz por meio de uma interface da web conveniente. O servidor e os agentes começarão imediatamente a usar os novos certificados.
Recentemente, tivemos um webinar, durante o qual
antonarhipov demonstrou todas as
opções acima em ação. Você pode vê-lo na entrada:
Você pode baixar (e executar na AWS, no Azure ou no contêiner Docker) a versão mais recente do TeamCity 2018.1 em nosso
site . Deixe comentários e sugestões sobre a nova versão em nosso
rastreador de erros .
Lembramos que o TeamCity Professional fornece 100 compilações de configurações e 3 compilações de um agente de forma totalmente gratuita , sem restrições de tempo e funcionalidade.
Tenha uma boa construção!