O documento discute o conceito de continuous building com TeamCity, abordando seu objetivo de eliminar o problema de 'works on my machine'. Ele explica o ciclo básico do processo, que inclui baixar mudanças, executar builds e testes, e destaca a importância do compromisso da equipe em corrigir falhas rapidamente. Além disso, o texto oferece dicas práticas para configuração e utilização do TeamCity para otimizar o fluxo de trabalho de desenvolvimento.

1. Continuous Building
usando
TeamCity
ANDRÉ MINELLI
MAIO / 2016

2. Continuous Building
Objetivo Principal:
Eliminar problema do “works on my machine”

3. Continuous Building
Ciclo básico:
◦Baixar mudanças de um repositório de código
◦Executar build do código
◦(Opcional) Executar testes automatizados
◦(Opcional) Executar análise estática / cobertura do código
◦(Opcional) Produzir artefatos (binários)
◦(Opcional) Fazer deploy de artefatos
◦Alertar se algum passo falhar

4. Continuous Building
Necessário COMPROMISSO do time:
Se o build quebrar, deve ser corrigido o
quanto antes!

5. Continuous Building
Benefícios adicionais:

6. Continuous Building
Benefícios adicionais:
◦Feedback rápido sobre mudanças do código

7. Continuous Building
Benefícios adicionais:
◦Feedback rápido sobre mudanças do código
◦Histórico da evolução do código

8. Continuous Building
Benefícios adicionais:
◦Feedback rápido sobre mudanças do código
◦Histórico da evolução do código
◦Confiabilidade

9. Continuous Building
Benefícios adicionais:
◦Feedback rápido sobre mudanças do código
◦Histórico da evolução do código
◦Confiabilidade
◦Transparência

10. Continuous Building
Diferente de Continuous Integration:
◦Integração depende da interação da equipe com o
repositório
◦NÃO depende somente de uma ferramenta

11. TeamCity
Servidor de continuous building da Jetbrains
Implementado em Java (acreditem se quiser )
Servidor
◦ Gerencia configurações
◦ Monitora repositórios
◦ Registra histórico, logs e estatísticas
◦ Armazena artefatos
Agentes
◦ Executam as etapas do ciclo de build

12. TeamCity – Configuração Básica
Projetos
◦(Subprojetos)
◦Configurações de build
◦Repositório
◦Build steps
◦Triggers

13. MÃO NA MASSA!

14. TeamCity – Configurações de build
Dicas:
◦Name – adicione prefixo com o número de ordem do
‘pipeline’ de build
◦Name – adicione sufixo indicando o tipo de trigger
(automático ou manual)
◦Build Number Format – adicione o ‘major version’ (fixo ou
parametrizado)

15. TeamCity – Repositórios
Dicas (Git):
◦Branch specification – adicione o(s) caminho(s) de
branches adicionais para serem monitorados
◦Branch specification – use parênteses para encurtar o
nome dos branches
◦Authentication > Password – crie um personal access
token no VSTS

16. TeamCity – Build steps
Dicas:
◦Use “runners” específicos sempre que possível
◦Plugins!
◦Log e status mais integrado
◦Fique atento ao “execute step” escolhido
◦Alguns “runners” não causam falha do ‘step’
◦Ex: Testes (Nunit, MSTest, etc)
◦Use “Only if build status is successful” nestes casos

17. TeamCity – Triggers
Dicas:
◦VCS Trigger – filtre pastas de acordo com seu pipeline
◦Ex: somente código precisa de build e testes
◦VCS Trigger – filtre branches de acordo com seu pipeline
◦Ex: package Nuget só deve ser gerado do master
◦Finish Build Trigger - conecte steps de um pipeline
◦Scheduled Trigger – gere ‘nightly builds’

18. TeamCity – Saindo do básico
General Settings
◦Salve artefatos produzidos no build
◦APKs, Nuget Packages, relatórios de testes, screenshots,
etc
◦Podem ser usados nos próximos build do ‘pipeline’
◦Use o status widget no README do projeto
◦ https://teamcity.takenet.com.br/httpAuth/app/rest/builds/buildT
ype:(id:Lime_Master)/statusIcon

19. TeamCity – Saindo do básico
Version Control Settings
◦Limpe todos os arquivos antes do build
◦Mesmo efeito de ‘git clone’ a cada build
◦Só desabilite se o tempo de transferencia impactar
◦Mostre as mudanças vindas de builds dependentes
◦Maior transparência em um ‘pipeline’

20. TeamCity – Saindo do básico
Build Steps
◦Adicione cobertura de código
◦ Runners de testes (.NET) e gradle (Java) possuem integração
◦ Pode impactar testes que dependem de tempo
◦Adicione inspeções de código
◦ FxCop, Resharper Inspections, Duplicates, outros via plugin
◦Copie steps entre projetos
◦Desabilite steps para testes/melhorias

21. TeamCity – Saindo do básico
Failure Conditions
◦Falhe o build de acordo com métricas
◦ Ex: cobertura reduziu, tamanho de um artefato aumentou
Build Features
◦Altere o AssemblyInfo para casar com o build number
◦Crie uma tag no repositório em caso de sucesso
◦ Muito útil principalmente ao gerar releases

22. TeamCity – Saindo do básico
Dependencies
◦Configure o ‘pipeline’ (chamado Build Chain)
◦Usará o mesmo commit em cada build step do ‘pipeline’
◦Permite visualizar o ‘pipeline’ para cada número de
versão
◦Copie artefatos gerados em builds anteriores do
‘pipeline’

23. TeamCity – Saindo do básico
Parameters
◦Adicione detalhes de configuração de steps
◦Explícito, em um único lugar
◦Ex: Usuário, senha, URL, Major version, etc
◦Inclua variáveis de ambiente
◦Utilizadas por exemplo com NodeJS e .NET Core

24. TeamCity – Saindo do básico
Agent requirements
◦Limite quais agentes possuem recursos específicos
◦ Ex: acesso a redes externas (VPNs, rede pública)
◦ Ex: recursos licenciados (Xamarin, Delphi)
◦Idealmente todos os agentes têm os mesmos recursos

25. TeamCity – Saindo do básico
Investigations
◦Permite declarar a responsabilidade em resolver um
‘build quebrado’
◦Comunicação interna também funciona bem ;)

26. TeamCity – Saindo do básico
Notificações
◦Email
◦ IMPORTANTE: configure corretamente seu usuário
◦Diretamente nas IDEs (VS, IntelliJ/AS)
◦Feed RSS, Windows Tray
◦Slack (plugin)
◦Webhooks (plugin)

27. TeamCity – Saindo do básico
Notificações
◦Casamento de username configurável por
repositório/projeto
◦Regras de notificações
◦ Somente falhas causadas por mim
◦ Somente sucesso após falha

28. TeamCity – Saindo do básico
Pre-tested commit
◦Garante que todos commit está livre de falhas
◦Submete mudanças para serem executadas ANTES de
serem ‘commitadas’
◦ Em caso de sucesso, faz merge das alterações
◦Requisitos:
◦ Somente com integração pela IDE (VS e IntelliJ/AS)
◦ Git ainda não é (bem) suportado

29. TeamCity – Exemplos de pipelines
GitFlow
◦1. CB (Auto) – build and unit tests
◦ todos os branches
◦2. Acceptance tests (Auto)
◦ develop, master e releases apenas
◦3. Deploy Hmg (Manual)
◦ releases apenas
◦4. Deploy Prod (Manual)
◦ master apenas

30. TeamCity – Exemplos de pipelines
Master only
◦1. CB (Auto) – build e unit tests
◦todos os branches
◦2. Acceptance tests (Auto)
◦develop e master apenas
◦3. Deploy (Manual) - gera package para Octopus
◦master apenas

31. Referências e material adicional
TeamCity User Guide (canal official JetBrains)
◦ https://www.youtube.com/watch?v=dmGa6_4OXdo
TeamCity Documentation
◦ https://confluence.jetbrains.com/display/TCD9/Creating+and+Editi
ng+Build+Configurations
Ícone com interrogação em toda a interface Web
◦ Remete à documentação, para aquele contexto