Gerenciar UI Tests com cada branch

Olá pessoal,

Bom, atualmente estamos trabalhando com três branches: dev, staging e master

Meus testes de UI estão rodando em integração continua apontando somente para a branch dev e para a aplicação de dev também. As outras branches são ignoradas justamente porque todos os testes apontam somente para a aplicação de desenvolvimento (ex: dev.minhaapp.com.br).

Dúvidas:

  1. Como vocês estão administrando hoje em relação a branches x UITests?
  2. Cada branch aponta para uma URL específica para rodar os testes?

Att,
Rafael

Depende muito de como é organizado seu sistema de release… sé por tags/branchs ou se é codigo em master.

Anyway, o testes na minha empresa atual são rodados a noite para todas as branchs + master e a cada pedido merge é rodado todos os testes novamente ( assim temos certeza que codigo com problema durante o dia não impactará a master)

@Leonardo-Galani Aqui na verdade é por branchs, da master vai para produção.

Aqui funciona assim: A cada push que o desenvolvedor faz no ambiente DEV, os testes rodam e nós temos um feedback se o ambiente de DEV está saudável ou não (veja aqui: http://take.ms/2rLUx). Por enquanto é apenas isso, os testes rodando apenas contra o ambiente de DEV mesmo apontando para a aplicação de DEV (aonde os desenvolvedores fazem commit e push)

Mas como eu disse antes, eu bloqueei para que os testes na MASTER rodassem em integração contínua porque não faz sentido estar rodando na MASTER sendo que os UI Tests estão sendo apontados para o ambiente de DEV

A dúvida é: Estou certo em testar somente em DEV? Posso melhorar esse meu processo?

Sinceramente, não gosto desse modelo de usar várias “long-lived” branches. O modelo que mais curto trabalhar e que nunca tive problemas é usar feature-branches e só ter a master como branch principal.

Um dos projetos que trabalho tem pelo menos 12 times (de 6, 7 pessoas em média) trabalhando no mesmo repositório, então imagina a quantidade diária de trabalho… pra cada tarefa que tem que ser feita vc cria uma branch, cria um Pull Request e aí os testes todos (inclusive de UI) rodam nessa branch. O Pull Request só pode ser aprovado depois de reviews e de ter todos os testes passando. Estando tudo certo, faz merge pra master, e, no momento do merge, já rodam jobs do servidor de CI executando os mesmos testes (inclusive os de UI) apontando pra master.

Quanto a ambientes, se vc tem sua aplicação conteinerizada (como é o meu caso), tanto faz se vc está testando em um ambiente de dev ou staging, a aplicação vai ser “deployada” da mesma forma :smiley:

@stefanteixeira said in Gerenciar UI Tests com cada branch:

Estando tudo certo, faz merge pra master, e, no momento do merge, já rodam jobs do servidor de CI executando os mesmos testes (inclusive os de UI) apontando pra master.

@stefanteixeira

Mas como você consegue separar para que na branch “DEV” aponte os testes para a aplicação de dev e para a branch MASTER aponte para a aplicação de produção?

Na minha concepção, se você faz um merge DEV -> MASTER, todos os testes e arquivos de configuração (aonde está setado a sua URL de teste) vão parar lá também.

@rafa

Cara… cada ambiente deve ter seu config separado… se vc commita dados de ambiente OU deploy sobrescreve arquivos de config, tem alguma coisa bem errada com o seus ambientes

@Leonardo-Galani

Por exemplo: Estou testando com protractor e minha URL está adicionada no protractor.conf.js, neste caso, em cada branch eu devo ter um arquivo protractor.conf.js setando para a aplicação correta?

Eu gosto mais da abordagem de feature-branches também. Mantendo o projeto de testes dentro do projeto da aplicação diminui bastante a manutenção na configuração, pois quando uma nova branch for criada, os testes podem ser alterados sem quebrar as demais branches.
Outra coisa que pode te ajudar é talvez receber a url via argumento na execução dos testes. Se você estiver usando protractor isso já é implementado por default (tem que confirmar pq faz muito tempo que não uso o Protractor) usando o --baseUrl.

@Rafa Eu estou utilizando o Protractor também e para conseguir apontar os testes para uma determinada branch, eu configurei um parâmetro no conf.js chamado branch (por exemplo), onde eu passo qual é a branch que eu vou executar os testes.

Dentro do conf.js …

params: {
branch: ‘’,
},

Feito isso, para executar os testes em uma determinada branch, eu chamo pelo comando:
protractor conf.js --params.branch=BRANCH_NUMBER

No método que você chama a URL é só incluir o parâmetro (browser.params.branch).

@rafa
Não cara, os testes rodam tanto na feature branch quanto na master, mas é um ambiente de “dev” no final das contas. Isso indifere porque são containers, o deploy é sempre da mesma forma, só vão mudar arquivos de configuração dependendo do ambiente (dev, staging, prod). Os dados dos testes são gerados dinamicamente, mas dependendo do caso vc poderia usar um dump de produção pra ter dados bem similares, se isso for uma necessidade.

@rafa tudo depende cara, vc pode ter arquivos de config diferentes pra cada ambiente, aí no job do servidor de CI vc diz pra rodar o arquivo correspondente. OU, vc pode usar variáveis de ambiente e aí usar um arquivo de config só, mas no job do servidor de CI vc passaria essa variável dependendo da branch em que está rodando.

Log in to reply

Looks like your connection to Agile Testers was lost, please wait while we try to reconnect.