Esta página contém uma lista de novos recursos que estamos ativamente desenvolvendo ou projetando para o TeamCity. Isto vai dar uma prévia dos anúncios que você pode esperar para o próximo ano.
As informações nesta página são atualizadas após cada lançamento. Este é o status atual dos recursos do roadmap:
Queremos que o TeamCity tenha tudo o que você precisa para deixar seus pipelines de CI/CD rápidos e econômicos. É por isso que estamos trabalhando em uma variedade de recursos que permitirão que você configure e execute seus builds na nuvem com mais facilidade.
Desenvolvedores em todo o mundo adoram as integrações completas do TeamCity com ferramentas de build e serviços externos, e nos esforçamos bastante para dar a essas integrações o melhor suporte possível. Nesta seção, você poderá ler sobre as novas integrações que pretendemos acrescentar.
Executar vários servidores do TeamCity e fazê-los trabalhar juntos pode elevar sua solução de CI/CD a um nível totalmente novo de desempenho e confiabilidade. Estamos melhorando a forma como o TeamCity funciona em um ambiente de cluster, ampliando os recursos de servidores secundários.
A integração contínua está no cerne do processo de desenvolvimento e é fundamental manter um fluxo de trabalho que minimize o risco de expor dados a terceiros ou de ser vítima de ataques cibernéticos. Estamos trabalhando em vários novos recursos para melhorar a segurança dos seus pipelines de CI/CD.
Estamos contentes em ver que mais e mais usuários estão armazenando suas configurações de CI/CD como código. Num futuro próximo, pretendemos tornar o Kotlin DSL ainda mais expressivo e acrescentar mais maneiras de começar a usá-lo.
Para lhe proporcionar um maior controle sobre o seu processo de CI, estamos trabalhando em uma variedade de novos recursos que facilitarão a automação dos seus pipelines de DevOps e ajudarão você a organizar o seu processo de desenvolvimento de forma mais eficiente.
Continuamos na nossa missão de criar uma interface de usuário que seja rápida e fácil de usar e que permita o máximo de flexibilidade para todos os tipos de fluxos de trabalho e práticas de desenvolvimento.
O TeamCity Cloud é uma versão gerenciada do TeamCity, totalmente hospedada e administrada pela JetBrains. Ele tem seu próprio roadmap e diversos recursos adicionais.
TeamCity Pipelines é o codinome de um novo produto no qual estamos trabalhando. Ele proporcionará uma experiência simples e intuitiva no desenvolvimento de pipelines de CI/CD, com a inteligência característica dos produtos da JetBrains.
Queremos que o TeamCity tenha tudo de que você precisa para tornar os seus pipelines de CI/CD rápidos e econômicos. É por isso que estamos trabalhando numa variedade de recursos que permitirão que você configure e execute seus builds na nuvem com mais facilidade.
Equipes que usam TeamCity na nuvem devem poder concluir seus builds tão rapidamente quanto se usassem instalações locais. Caches persistentes na nuvem permitirão que agentes de build em nuvem transfiram rapidamente entre si dependências de build, tais como artefatos do Maven e pacotes do NPM, economizando tempo e custos de rede.
Além disso, precisar de menos downloads é bom para o planeta. Isto economiza eletricidade e reduz a pegada de carbono. Portanto, este recurso vai lhe ajudar a investir no verde, mesmo quando seus builds ficam verdes mais rapidamente.
Recentemente, lançamos um novo sistema de gerenciamento de credenciais — o AWS Connection — que fornece credenciais temporárias aos recursos de build e integrações na nuvem do TeamCity. Essas credenciais têm apenas os direitos necessários para executar uma tarefa específica. Nossa próxima etapa é implementar o suporte ao AWS Connection em todos os plug-ins disponíveis no TeamCity. Isso tirará dos ombros da sua equipe o encargo de configurar manualmente o acesso ao EC2, ECR, S3 e outros recursos.
Cada vez mais dos nossos clientes estão interessados em executar agentes de build na nuvem, porque isto permite que eles aumentem rapidamente a capacidade de seus canais de entrega, quando necessário. Para oferecer suporte aos usuários que estão migrando para o Microsoft Azure, planejamos melhorar e incluir o plug-in TeamCity Azure.
Com o criador de imagens do TeamCity, você poderá criar imagens personalizadas das máquinas virtuais dos agentes de build do TeamCity em vários ambientes. Isso ajudará a acelerar seus builds, usando repositórios de VCS, dependências de build, imagens do Docker e outros recursos já prontos.
Gostaríamos de dar suporte a um agendador comum, como Kubernetes, HashiCorp Nomad, AWS ECS ou semelhante, para executar tarefas simples de build sem a exigência de especificar e manter um agente de build.
Isso permitiria que você começasse a definir configurações de build para um projeto sem ter que pensar em quais workers executarão as suas builds.
Essa abordagem seria útil para tarefas pequenas e simples que não precisem de caches locais de raízes de VCS, dependências, etc. Também aumentaria a utilização de recursos usando agendadores. Estes poderiam executar várias tarefas em paralelo no mesmo nó do cluster, desde a instalação.
Estamos pensando em adicionar mais opções de agentes hospedados pela JetBrains no TeamCity Cloud. Isso incluiria recriar agentes por minuto no macOS e oferecer agentes baseados em ARM para o Linux.
Atualmente, o TeamCity Cloud fornece um servidor separado para cada cliente. Estamos pensando na possibilidade de hospedar vários projetos no mesmo servidor. Isso nos ajudaria a reduzir custos e talvez até nos permitisse oferecer uma versão gratuita do TeamCity Cloud.
Desenvolvedores em todo o mundo adoram as integrações completas do TeamCity com ferramentas de build e serviços externos, e nos esforçamos bastante para dar a essas integrações o melhor suporte possível. Abaixo está uma lista dos novos recursos de integração que planejamos acrescentar.
Atualmente, o recurso de build de solicitações pull amplia as especificações de branch de uma raiz de VCS para incluir os branches de solicitações pull abertas que atendam a determinados critérios de filtragem.
Queremos estender este recurso para que você possa disparar builds automaticamente para um subconjunto de solicitações de pull e, ao mesmo tempo, ainda possa iniciar builds manualmente para outros branches.
Este recurso permitirá que você configure uma conexão (por exemplo, ao GitHub) no nível de projeto. Você poderá indicar se precisa que o TeamCity colete quaisquer solicitações de pull e dados do rastreador de issues diretamente das configurações da conexão e quais configurações de build precisam publicar seus status.
Este recurso lhe poupará bastante tempo, pois você poderá definir as configurações uma só vez no nível de projeto.
Os tokens OAuth emitidos via Connections são armazenados num repositório de tokens interno do TeamCity. No momento, os tokens são extraídos do armazenamento quando certos parâmetros (por exemplo, a raiz de um VCS ou um recurso de build) forem configurados através da interface de usuário de administração.
Queremos introduzir uma interface de usuário para gerenciamento de tokens. Isso permitirá que você verifique o uso e o escopo dos seus tokens, além de:
Grandes corporações adoram a capacidade do TeamCity de se expandir para milhares de agentes de build e dezenas de milhares de projetos. No entanto, em algum momento, adicionar novos projetos deixa de ser divertido e se torna um fardo necessário que você precisa repetir a cada novo empreendimento.
Com este recurso, estamos pensando em adicionar a capacidade de criar automaticamente um projeto no TeamCity quando for criado um novo repositório .teamcity.
O TeamCity tem suporte dedicado a solicitações pull do GitHub. Do ponto de vista do TeamCity, solicitações pull são um branch especial. Vamos marcar esses branches na interface de usuário para que possam ser claramente reconhecidos.
Com o suporte a GitHub Checks, vamos fornecer aos usuários relatórios mais informativos do que aconteceu durante a build, com base nos dados obtidos do GitHub.
Os principais benefícios deste recurso incluem:
Atualmente, há apenas um filtro de branch-alvo no recurso de solicitações pull em builds do TeamCity. Estamos pensando em adicionar novos filtros, como status de revisões, rótulos, funções de autores, etc.
O TeamCity combina recursos e versatilidade que nenhuma outra ferramenta de CI tem. Não surpreende que ele seja uma das ferramentas de CI mais populares para uso no desenvolvimento de jogos. Estamos começando a explorar as contribuições que ele pode dar a esse setor em três áreas principais:
Interessado em usar o TeamCity para criar seus jogos? Convidamos você a se inscrever aqui para participar da nossa pesquisa.
O TeamCity oferece integração nativa com o Perforce Helix Core, um dos sistemas de controle de versões mais populares no desenvolvimento de jogos. Eis o que planejamos para o suporte ao Perforce.
O uso do check-out do Perforce no lado do agente cria espaços de trabalho do Perforce. Atualmente, esses espaços de trabalho continuam no servidor do Perforce quando um agente do TeamCity não está mais em uso.
Para evitar consumir recursos do servidor, vamos introduzir a exclusão automática de espaços de trabalho do Perforce criados por agentes do TeamCity que não estão mais ativos.
Atualmente, o publicador do status de commit dá informações sobre cada etapa do build (enfileirado, iniciado, bem-sucedido/falhado, etc.) e essas informações podem ser excessivas.
Vamos dar a você mais controle sobre quais comentários são enviados e quais estados os geram.
Atualmente, o TeamCity gera automaticamente o nome do espaço de trabalho do Perforce durante o check-out no lado do agente. Planejamos adicionar a opção de especificar um padrão personalizado para o nome do espaço de trabalho. Esse padrão permitirá o uso de:
O Unreal Engine é um dos mecanismos de jogo mais populares no desenvolvimento de jogos. Estamos trabalhando em um novo plug-in do Unreal Engine, que oferecerá os seguintes recursos aos usuários do TeamCity:
Executar vários nós do TeamCity e fazê-los trabalharem juntos pode elevar sua solução de CI/CD a um patamar totalmente novo de desempenho e confiabilidade. Estamos melhorando a forma como o TeamCity funciona em ambientes de cluster, implementando novos recursos nas configurações com múltiplos nós.
A manutenção do servidor não deve impedir que os desenvolvedores executem seus builds. Planejamos investir mais em recursos para aumentar a disponibilidade do TeamCity, incluindo a conversão automatizada de um nó secundário em um nó primário, e continuaremos a eliminar a dependência de um diretório de dados compartilhado em configurações com múltiplos nós.
Planejamos começar a armazenar todos os arquivos de configuração em um repositório local de Git. Esse repositório poderá ser usado para compartilhar arquivos de configuração entre nós do TeamCity, em configurações com múltiplos nós.
Isso também nos ajudará a configurar notificações de transação a respeito de quaisquer alterações nesses arquivos, garantindo a atomicidade dessas alterações e também das notificações dos nós secundários a respeito dessas alterações.
Em uma configuração com vários nós, todos os nós funcionam com arquivos de logs de builds armazenados em um diretório de dados compartilhado. Na maioria das vezes, um nó "é o proprietário" de um arquivo de log correspondente a alguma build. Esse nó pode gravar nesse arquivo, enquanto os outros nós podem apenas lê-lo.
Se um nó do TeamCity achar que o nó "proprietário" do arquivo de log foi encerrado com erro (quando na verdade está funcionando bem), esse outro nó pode começar a gravar no mesmo arquivo e corrompê-lo.
Gostaríamos de implementar um serviço autônomo de logs de build que possa ser acessado via HTTPS a partir de cada nó. Essa nova abordagem nos permitiria eliminar a possibilidade de arquivos de log serem corrompidos como resultado de dois nós gravando no mesmo arquivo.
A ideia por trás deste recurso é fazer commit e push de todas as alterações (tanto as relativas ao projeto quanto as globais) em um determinado repositório de Git. Esse repositório poderia então ser usado para compartilhar arquivos de configuração entre nós do TeamCity, em configurações com vários nós.
Esse repositório também poderia ser usado para fazer auditoria de todas as alterações nas configurações do TeamCity (feitas através da interface de usuário, API Rest ou configurações versionadas).
A integração contínua está no cerne do processo de desenvolvimento e é fundamental manter um fluxo de trabalho que minimize o risco de expor dados a terceiros ou de ser vítima de ataques cibernéticos. Além do nosso trabalho contínuo em melhorias relacionadas à segurança do produto, vamos introduzir os seguintes recursos:
Este recurso permitirá ao TeamCity buscar o valor de um parâmetro localizado em uma unidade externa de armazenamento logo antes de executar um build. Você poderá ir até a interface de usuário do TeamCity e adicionar um parâmetro que referencie o parâmetro externo. Este recurso será útil para equipes que armazenam parâmetros em unidades externas, como a AWS Parameter Store, HashiCorp Vault, Azure App Configuration, Azure Key Vault, etc.
Esse repositório também poderia ser usado para fazer auditoria de todas as alterações nas configurações do TeamCity (feitas através da interface de usuário, API Rest ou configurações versionadas).
Estamos desenvolvendo um recurso que detectará solicitações pull e merge de forks de todos os hosts de VCS com suporte. Para reforçar a segurança, também vamos implementar a aprovação manual obrigatória para builds acionadas desta maneira.
Graças à expressividade do Kotlin DSL, nossos usuários estão começando a armazenar suas configurações de IC/DC (Integração Contínua/Deployment Contínuo) na forma de código. Queremos melhorar este recurso e estas são as principais alterações que planejamos fazer no futuro próximo.
Usar a DSL do Kotlin permite que usuários mais experientes do TeamCity reutilizem configurações de build de forma mais natural, poupando tempo e esforço às equipes. Como a DSL do Kotlin usa tipos estáticos, usá-la em um IDE também simplifica a descoberta das APIs disponíveis.
Ao mesmo tempo, compreendemos que o nível de conhecimento de Kotlin ou a necessidade de trabalhar com um IDE específico não deveria ser um obstáculo à configuração de pipelines no TeamCity. É por isso que estamos pesquisando maneiras de simplificar a experiência do usuário e facilitar ainda mais o trabalho com o TeamCity.
Para simplificar a edição de arquivos do Kotlin em editores de código que não fazem parte de um IDE, vamos eliminar a necessidade de especificar explicitamente as importações de pacotes relacionados à DSL em arquivos .kt. As importações serão processadas automaticamente no lado do servidor do TeamCity.
Isso permitirá que você compile o código em qualquer editor. O TeamCity garantirá que isso realmente funcione.
Embora a DSL do Kotlin lhe dê a capacidade de configurar pipelines exatamente do jeito que você precisa para que eles sejam executados, projetos menores podem não precisar de toda a complexidade que a DSL do Kotlin acarreta. A esse respeito, vamos simplificar a DSL básica para projetos menores, para que você possa facilmente copiar e colar exemplos de código em DSL a partir da documentação. Isso ajudará a acelerar o processo de configuração dramaticamente.
Embora a DSL do Kotlin ofereça uma maneira poderosa de configurar os seus projetos de CI/CD, talvez algumas pessoas prefiram usar YAML na configuração de pipelines.
Estamos pensando na oportunidade de adicionar YAML como uma opção ao configurar projetos como código.
Se você usar a DSL do Kotlin para defnir suas configurações versionadas e precisar fazer alterações, o TeamCity poderia levar você ao arquivo correspondente no repositório de um sistema externo onde o código correspondente esteja armazenado. Isso significaria o fim da navegação para procurar aquele arquivo específico no repositório!
Queremos permitir que você gerencie suas licenças de Servidor e de Agente de forma transparente e flexível através da Conta da JetBrains. Também queremos que o TeamCity possa obter essas licenças em tempo real, sem ter que gerar e baixar chaves de licença off-line.
Estamos planejando o seguinte:
Planejamos adicionar um novo recurso que permitirá que o TeamCity use um conjunto de parâmetros para executar um build para cada combinação deles — matriz de builds. Este recurso é útil especialmente quando você precisa executar o mesmo build ou testá-lo em diferentes ambientes — por exemplo, em diferentes sistemas operacionais, versões do Java e .NET, navegadores, etc.
As matrizes de builds diminuirão significativamente o tempo e o esforço, permitindo que você especifique um só conjunto de parâmetros uma única vez (por exemplo, o sistema operacional e o ambiente) e depois execute o mesmo conjunto paralelamente em outras configurações de build.
Tornaremos possível salvar um histórico de builds implantados.
Graças a este novo recurso, você poderá verificar o estado atual de todas as implantações, como qual versão está implantada em produção e qual na preparação.
Você também poderá acessar relatórios sobre o histórico de implantação em todas as instâncias. No painel de implantação, você encontrará uma lista das instâncias, seus estados atuais (em andamento, bem-sucedida, falhada) e informações relevantes sobre o build (horários, agente, quem iniciou o build, etc.)
Você já teve vontade de poder agendar uma build para não ser executada imediatamente e sim em um determinado horário?
Estamos desenvolvendo um recurso que permitirá que você agende a build para ser executada em um determinado horário (incluindo o fuso horário) ou prazo (por exemplo, daqui a duas horas).
A build será adicionada à fila imediatamente e esperará até o horário agendado.
Estamos pensando na possibilidade de passar um valor bloqueado numa build composta para suas builds de dependência. No futuro, também gostaríamos de dar aos usuários do TeamCity a capacidade de bloquear recursos para um conjunto de builds vinculadas a dependências de snapshots.
A maioria dos desenvolvedores usa suas soluções de CI/CD todos os dias e queremos que eles se sintam em casa com o TeamCity.
Na versão 2022.10, a interface de usuário Sakura é padrão no TeamCity. Agora estamos trabalhando para atingirmos a total equivalência de recursos entre as interfaces de usuário Classic e Sakura. Para isso, vamos implementar novamente as páginas da interface Classic e finalizar o subsistema de plug-ins para integrar as abas de plug-ins na interface Sakura.
O TeamCity é um poderoso sistema de CI/CD com inúmeros recursos avançados. Para ajudar os usuários a se familiarizarem com o TeamCity e configurarem o software exatamente como eles desejam que ele funcione, vamos oferecer guias para iniciantes dentro da solução. Os guias interativos e as dicas ensinarão os usuários iniciantes a usarem o TeamCity de forma eficaz e ajudarão os clientes consolidados a migrarem da interface de usuário Classic para a Sakura.
Para melhorar a integração dos usuários, vamos introduzir projetos de demonstração de modelos no TeamCity. Com a ajuda desses projetos de modelos, você poderá experimentar o TeamCity sem se conectar a sua própria base de código à ferramenta de CI/CD e obter mais rapidamente a sua primeira build sem erros.
Guias interativos ajudarão você a ter uma visão geral dos principais recursos do TeamCity diretamente na interface de usuário. Os guias apresentarão cenários e casos de uso diferentes, para você se familiarizar mais rapidamente com o TeamCity.
Estamos trabalhando para melhorar o desempenho em grandes instalações do TeamCity. Nosso foco primário é nos agentes e nas páginas de projeto. Nosso objetivo é diminuir as métricas do tempo até o primeiro byte, mudança cumulativa de layout e tempo até a interatividade, além de outras métricas essenciais para a Web. Os usuários do TeamCity podem esperar que as páginas do aplicativo sejam carregadas e exibidas mais rapidamente em todos os navegadores.
O TeamCity fornece uma visão geral dos problemas e investigações atuais em nível de projeto e de build. Os usuários podem revisar erros de configuração de builds, testes falhados e problemas sob investigação, e verificar seus usuários designados e status.
Estamos reformulando a interface para dar aos nossos usuários uma melhor visão geral de todos os problemas e seus status em um determinado projeto. Agora essas informações podem ser encontradas na aba comum Problems.
Lá, os usuários poderão filtrar os problemas por tipo (testes falhados, problemas com a build ou com sua configuração), status (silenciado ou não) e investigador (usuário designado).
Com esta atualização, estamos nos esforçando para dar aos nossos usuários uma maneira mais conveniente e concisa de revisar os problemas existentes nas builds, bem como seus status.
O TeamCity Pipelines proporcionará uma experiência simples e intuitiva para desenvolver pipelines de CI/CD com a inteligência característica dos produtos da JetBrains.
Com o TeamCity Pipelines, nosso plano é mudar o foco das etapas individuais de automação de builds e testes para a experiência geral de configuração de pipelines de entrega. O TeamCity Pipelines proporcionará uma experiência simples e intuitiva para desenvolver pipelines de CI/CD com a inteligência característica dos produtos da JetBrains.
O editor visual de pipelines totalmente novo no TeamCity Pipelines facilita o trabalho com pipelines de CI/CD de qualquer grau de complexidade, usando o mecanismo de CI/CD do TeamCity, que consegue lidar com cargas de trabalho de nível corporativo. A assistência inteligente à configuração incorporada ao TeamCity Pipelines guiará você através de todas as etapas da configuração de pipelines e, nesse processo, sugerirá otimizações automaticamente.
Estes são alguns dos novos recursos nos quais estamos trabalhando para o TeamCity Pipelines:
A DSL do Kotlin é uma maneira poderosa de configurar os seus pipelines como código. Porém, alguns usuários talvez achem mais fácil iniciar a configuração dos seus projetos de CI/CD usando YAML, a linguagem mais amplamente usada no setor de CI/CD.
O TeamCity Pipelines oferecerá aos usuários a oportunidade de usarem YAML para armazenar configurações de build e definir tarefas e suas dependências.
O TeamCity poderá paralelizar suítes de teste automaticamente através de um algoritmo inteligente, sem nenhuma interação adicional por parte do usuário. Este terá apenas que escolher quantos agentes de build seus testes deverão executar em paralelo. Isso ajudará a reduzir significativamente o tempo de build na próxima execução.
Às vezes, pode ser difícil para os usuários entenderem que software está instalado nos agentes de build do TeamCity, qual sistema operacional específico esses agentes estão usando e como modificar os agentes de build hospedados pela JetBrains.
Gostaríamos de desenvolver uma espécie de playground de agentes, que desse às pessoas a possibilidade de executar seus scripts no agente, sem executar o pipeline. Assim, os usuários poderiam se conectar aos agentes do playground depois do término da build, para fins de investigação e depuração.
Também daríamos aos usuários a capacidade de abrir terminais do agente diretamente na interface de usuário do TeamCity Pipelines, para verificar rapidamente o ambiente do agente e depurar os problemas de um agente específico.
Se o software do qual você precisa para configurar o seu pipeline não estiver disponível em um agente, você pode optar por executar as suas builds em um container do Docker.
The enhanced Docker integration in TeamCity Pipelines will allow you to use the autocomplete feature to find the correct Docker image from https://hub.docker.com/. Também mostrará uma lista de imagens do Docker usadas anteriormente e dará um link para cada resultado encontrado de imagem do Docker. Isso tornará mais fácil e rápido encontrar uma imagem necessária do Docker.
Estamos avaliando a possibilidade de fornecer uma solução amigável para o caso de uma imagem específica não existir no Docker Hub. Talvez os usuários possam referenciar um arquivo do Docker a partir do seu repositório de VCS atual.
Graças à sua paralelização inteligente de testes, reutilização de builds, caches e outros recursos, o TeamCity pode ajudar as organizações a reduzirem seu tempo de build significativamente. Atualmente, o TeamCity mostra o tempo total otimizado (poupado) em cada execução de uma build.
Para expandir esse recurso, vamos oferecer uma visualização mais abrangente de quais otimizações foram aplicadas na execução da build. Também estamos trabalhando em fornecer uma lista das otimizações que poderiam potencialmente ser aplicadas para reduzir ainda mais o tempo de build.
Você pode se inscrever para o acesso antecipado ao TeamCity Pipelines aqui.
Queremos que nossos usuários possam desenvolver sem o trabalho de ter que instalar e manter uma infraestrutura de build. Para isso, fornecemos o TeamCity Cloud, uma solução de CI/CD totalmente gerenciada e completamente hospedada e administrada pela JetBrains. Ele tem a mesma funcionalidade da versão local, exceto por vários recursos administrativos que não são necessários na instalação em nuvem.
Embora tudo que desenvolvemos esteja presente em ambas as versões, o TeamCity Cloud tem seu próprio roadmap, com uma série de recursos adicionais: