O documento discute integração contínua, incluindo seus conceitos, benefícios e pré-requisitos. A integração contínua envolve construir e testar automaticamente o software sempre que novas mudanças são implementadas para garantir que o software esteja sempre em um estado funcional. Isso ajuda a detectar bugs cedo e manter o software de alta qualidade. Pré-requisitos incluem controle de versão, builds automatizados e testes automatizados.
Testar é somente apertar botões?
A apresentação foi feita para demonstrar a importância do testes de software, na construção de um software de qualidade.
Testar é somente apertar botões?
A apresentação foi feita para demonstrar a importância do testes de software, na construção de um software de qualidade.
SAPO Session on Continuous Integration. Talk presented on September 15th, 2010.
An insight on what is continuous integration and some of the tools available to implement it. A real use case scenario briefly mentioned.
Uma reflexão sobre desenvolvimento de software, qualidade e como o TDD pode nos ajudar a melhorar em tudo isso.
A versão em PPT, que possui comentários adicionais para cada Slide, pode ser baixada no Google Drive: https://drive.google.com/folderview?id=0B4k-4pdeaM58SEpYcHZSbFdoS0E&usp=sharing
Para maiores informações sobre a palaestra, acesse: http://luizricardo.org/2014/10/pensando-tdd/
[DevOps Summit]Importância de testes automatizados para sustentar Continuous...Samanta Cicilia
O mercado tem exigido cada vez mais rapidez nas entregas dos times de desenvolvimento, para atender as demandas de negócio e manter a competitividade. Para garantir que essas entregas aconteçam no tempo esperado e com qualidade, é muito importante investir em todos os níveis de teste automatizados. Vamos ver quais são esses níveis de teste e alguns exemplos práticos usando Python de testes unitários, integração, funcionais, performance e mutação.
Alcançando qualidade de software através de entrega contínuaSamanta Cicilia
Entregar software que atenda as objetivos do negócio, em pouco tempo e com um alto padrão de qualidade ainda é um desafio para muitas empresas. Processos de desenvolvimento são muitas vezes burocráticos. O desenvolvimento ágil veio para nos mostrar que a forma que pensávamos em software podia ser melhorada. A Entrega Contínua veio para potencializar a entrega desde a primeira linha de código até produção. Nessa palestra vamos mostrar como estamos implementando Entrega Contínua na Infoglobo. Serão abordados os seguintes temas: Introdução à Entrega Contínua de software - Pipeline de Entrega - Estágio de Commit - Deploys nos ambientes de teste - Smoke Tests -Testes de Performance Automatizados - Análise de Log - Promoção dos pacotes para cada ambiente - Testes Regressivos (Automatizados/Manuais) - Deploy em Produção - Desafios Culturais -Próximos Passos
Apresentação sobre Automação de Teste de Software no 3° BRATESTE - Seminário Brasileiro de Teste de Software em 18/06/2010
Esta apresentação contém material teórico sobre Automação de Teste, Geração de Frameworks de Automação de Teste, como definir a arquitetura da automação e um hands on com Selenium
Apresentação sobre TDD(Test-Driven Development) realizada em 18/04/2013.
Tópicos abordados:
- Motivos que contribuem para a falta de testes
- Quais os impactos da falta de testes?
- Visão geral dos diferentes tipos de testes na área de software
- Testes unitários e a plataforma .NET
- TDD: conceitos gerais
- Implementação de um exemplo prático
- Testes unitários e o Visual Studio 2015
SAPO Session on Continuous Integration. Talk presented on September 15th, 2010.
An insight on what is continuous integration and some of the tools available to implement it. A real use case scenario briefly mentioned.
Uma reflexão sobre desenvolvimento de software, qualidade e como o TDD pode nos ajudar a melhorar em tudo isso.
A versão em PPT, que possui comentários adicionais para cada Slide, pode ser baixada no Google Drive: https://drive.google.com/folderview?id=0B4k-4pdeaM58SEpYcHZSbFdoS0E&usp=sharing
Para maiores informações sobre a palaestra, acesse: http://luizricardo.org/2014/10/pensando-tdd/
[DevOps Summit]Importância de testes automatizados para sustentar Continuous...Samanta Cicilia
O mercado tem exigido cada vez mais rapidez nas entregas dos times de desenvolvimento, para atender as demandas de negócio e manter a competitividade. Para garantir que essas entregas aconteçam no tempo esperado e com qualidade, é muito importante investir em todos os níveis de teste automatizados. Vamos ver quais são esses níveis de teste e alguns exemplos práticos usando Python de testes unitários, integração, funcionais, performance e mutação.
Alcançando qualidade de software através de entrega contínuaSamanta Cicilia
Entregar software que atenda as objetivos do negócio, em pouco tempo e com um alto padrão de qualidade ainda é um desafio para muitas empresas. Processos de desenvolvimento são muitas vezes burocráticos. O desenvolvimento ágil veio para nos mostrar que a forma que pensávamos em software podia ser melhorada. A Entrega Contínua veio para potencializar a entrega desde a primeira linha de código até produção. Nessa palestra vamos mostrar como estamos implementando Entrega Contínua na Infoglobo. Serão abordados os seguintes temas: Introdução à Entrega Contínua de software - Pipeline de Entrega - Estágio de Commit - Deploys nos ambientes de teste - Smoke Tests -Testes de Performance Automatizados - Análise de Log - Promoção dos pacotes para cada ambiente - Testes Regressivos (Automatizados/Manuais) - Deploy em Produção - Desafios Culturais -Próximos Passos
Apresentação sobre Automação de Teste de Software no 3° BRATESTE - Seminário Brasileiro de Teste de Software em 18/06/2010
Esta apresentação contém material teórico sobre Automação de Teste, Geração de Frameworks de Automação de Teste, como definir a arquitetura da automação e um hands on com Selenium
Apresentação sobre TDD(Test-Driven Development) realizada em 18/04/2013.
Tópicos abordados:
- Motivos que contribuem para a falta de testes
- Quais os impactos da falta de testes?
- Visão geral dos diferentes tipos de testes na área de software
- Testes unitários e a plataforma .NET
- TDD: conceitos gerais
- Implementação de um exemplo prático
- Testes unitários e o Visual Studio 2015
Esta apresentação, fundamentada nos mais modernos estudos sobre o assunto, enfatiza a necessidade do uso das atividades de inteligência e contrainteligência para a segurança e desenvolvimento competitivo das organizações. Os participantes terão oportunidade de aprender sobre os riscos do atual ambiente competitivo, complexo e volátil, que podem ameaçar seus negócios e como enfrenta-los adequadamente.
Solicitação de cursos: mratreinamento@gmail.com
Inteligência emocional as 5 chaves fundamentaisManuela Selas
A Inteligência Emocional é uma das áreas preferenciais de intervenção do Coaching.
O processo de Coaching desenvolve-se em 5 etapas entre a terceira e a quinta, trabalhamos as diferentes áreasda inteligência emocional que farão toda a diferença no processo de desenvolvimento pessoal do coachee (cliente)
Roteiro
- O que é Entrega Contínua e DevOps?
- O que é Integração Contínua?
- Erros Comuns em Entrega de Software;
- Princípios de Entrega Contínua;
- Práticas em Arquitetura de Software;
Aprenda um pouco sobre um poderoso conjunto de serviços e ferramentas na gestão de infraestrutura em nuvem, que contribuem com práticas e metodologias ágeis de testes e desenvolvimento.
Ferramentas e serviços envolvidos: Visual Team Services + Azure + Integração contínua(testes e build automatizados) + deploy.
Teste automatizado com Selenium é uma abordagem para testar aplicativos da web usando o Selenium WebDriver, uma ferramenta de automação de teste de código aberto. O objetivo é verificar se o aplicativo funciona conforme o esperado em diferentes cenários.
Para criar um teste automatizado com Selenium, você precisará seguir os seguintes passos:
Escolha uma linguagem de programação: O Selenium suporta várias linguagens de programação, como Java, Python, C#, etc. Escolha uma linguagem que seja adequada para você.
Configure o ambiente de teste: Você precisará configurar o ambiente de teste com o Selenium WebDriver, o navegador da web e o ambiente de desenvolvimento integrado (IDE) da sua escolha.
Identifique elementos da página: Use o inspetor de elementos do navegador para identificar os elementos da página que você deseja testar, como botões, caixas de texto, menus suspensos, etc.
Escreva o código de teste: Use o código da linguagem de programação escolhida para escrever o teste. O código pode incluir as seguintes etapas:
Navegar para a página que contém os elementos que você deseja testar.
Localizar os elementos na página usando seus identificadores únicos, como ID, nome, classe, etc.
Interagir com os elementos, como clicar em um botão, preencher um formulário, selecionar uma opção em um menu suspenso, etc.
Verificar se o aplicativo se comporta conforme o esperado.
Executar o teste: Execute o teste no ambiente de teste configurado. O Selenium abrirá o navegador, navegará para a página e executará as etapas de teste que você escreveu.
Analisar os resultados do teste: Verifique se o teste passou ou falhou e analise os logs para identificar quaisquer erros ou problemas.
Repita para diferentes cenários: Repita os passos 3 a 6 para diferentes cenários de teste, como diferentes entradas de formulário, diferentes caminhos de navegação, etc.
Os testes automatizados com Selenium podem ser integrados ao processo de integração contínua para garantir que o aplicativo da web seja testado regularmente. Isso ajuda a identificar e corrigir problemas antes que se tornem críticos. Além disso, a automação de testes pode economizar tempo e esforço, permitindo que os testes sejam executados mais rapidamente e com menos erros humanos.
“Integração Contínua é uma pratica de desenvolvimento de software onde os membros de um time integram seu trabalho frequentemente, geralmente cada pessoa integra pelo menos diariamente – podendo haver multiplas integrações por dia. Cada integração é verificada por um build automatizado (incluindo testes) para detectar erros de integração o mais rápido possível. Muitos times acham que essa abordagem leva a uma significante redução nos problemas de integração e permite que um time desenvolva software coeso mais rapidamente.” Martin Fowler
Integração contínua - Prática de desenvolvimentoMario Mendonça
Integração Contínua é uma pratica de desenvolvimento de software onde os membros de um time integram seu trabalho frequentemente, geralmente cada pessoa integra pelo menos diariamente – podendo haver múltiplas integrações por dia. Cada integração é verificada por um build automatizado (incluindo testes) para detectar erros de integração o mais rápido possível. Muitos times acham que essa abordagem leva a uma significante redução nos problemas de integração e permite que um time desenvolva software coeso mais rapidamente.
O Visual Studio Summit 2016 é o maior evento sobre Visual Studio realizado no Brasil que está chegando a 5ª edição voltado para desenvolvedores de software que tem o objetivo de promover networking, apresentar tendências e principais estratégias atuais ligadas ao desenvolvimento de software na plataforma Microsoft usando Visual Studio, Azure e mobilidade. Durante o Keynote Ramon Durães abordou o tema transformação digital e DevOps.
Uma introdução a testes de unidades, independente de linguagem de programação, explicando fundamentos de testes de unidade, passando desde o que é e por que criar, até a sua estrutura, ciclo de vida, mocks, inversão de controle e TDD.
Apresentação realizada no dia 18/08/2018 no evento RP Tec Com (http://rpteccom.com/) em conjunto com o Felipe Muniz. #rpteccom
TDC 2013 7 Dicas para acelerar os testesFelipe Freire
Apresentação realizada no TDC 2013, na trilha de testes contendo dicas de como utilizar técnicas e ferramentas atuais para acelerar os testes de software e obter resultados mais efetivos.
Quebrando barreiras entre desenvolvimento e operação de software com DevOpsJosé Alexandre Macedo
Apresentado para o Pop-ES e NPD da Ufes. Conheça o significado de DevOps e como ele pode apoiar entregas mais rápidas de software por meio da mudança de cultura, automatização entre outras...
Scrumetes - Uma Comunidade de Práticas - Agile Brazil_2014ScrumHalf Tool
De um Scrum Master espera-se que ele seja capaz de cuidar do processo, cuidar da Equipe Scrum, estudar novas técnicas, resolver problemas, ser criativo, ter sempre uma solução para os desafios apresentados e fazer tudo isso naturalmente. Mas seria o Scrum Master um “super-herói”? Será que esse “herói” não precisa de um outro “herói” para ajudá-lo? Será que ele não precisa de uma troca de ideias na “sala da justiça” para voltar com todo o gás para a luta? Para nos ajudar nisso criamos as Scrumetes - uma comunidade de prática para Scrum Masters. E você? O que tem feito para te apoiar neste trabalho?
Se você tem interesse em ensinar sobre Kaban, mas está em dúvida de qual a melhor didática para ensinar o que é o Kaban, seus conceitos e princípios sugiro que você opte por ensinar usando o método mão-na-massa. Não tem erro!
Mais detalhes em: http://blog.myscrumhalf.com/?p=9204
2. Realidade
• Estranho, mas comum…
– Que por um longo tempo, durante o processo de
desenvolvimento, a aplicação não está funcional.
• A Razão? É fácil de entender…
– Ninguém tenta usar a aplicação como se esta
estivesse no ambiente de produção.
3. Realidade, ainda…
• A maioria dos projetos agenda fases para
integração ao final do desenvolvimento
– Tempo para Integração pode ser extremamente
longo.
– Não há como prever o tempo.
4. Integração Contínua
• Toda vez que alguém “commita” alguma
mudança, toda a aplicação é construída (build) e
um conjunto expressivo de testes automatizados
são executados a fim de testá-la.
• Se o build ou os testes falham toda a equipe para
o que quer que estejam fazendo e acertam os
problemas imediatamente.
• Software em estado funcional a todo o tempo.
6. Conceitos que justificam
• Se a integração do código está funcionando,
por que não fazê-la a todo instante?
• Mudança de paradigma:
– Sem a integração contínua seu software está
quebrado até que alguém prove o contrário.
7. Vantagens
• Equipes que adotam a IC são capazes de
efetivamente entregar software mais rápido e
com menos bugs.
• Bugs são detectados previamente, quando são
baratos de serem solucionados, provendo
menos gastos de custo e tempo.
8. O que é preciso antes de iniciar?
1. Controle de Versão
– Repositório de tudo do projeto:
código, testes, scripts de BD, build, scripts de
deployments e o que mais for preciso para:
criar, instalar, rodar e testar a aplicação.
9. O que é preciso antes de iniciar?
2. Build Automático
– Deve ser possível iniciar o build pela linha de
comando. Razão?
• Deve ser possível compilar a aplicação de forma
automática do ambiente de IC, para quando algo der
errado que seja possível de ser auditado.
• Seu script de build tem que ser como o código do
projeto. Deve ser testado e constantemente
refatorado, para estar sempre arrumado e
compreensível. Importante à medida que o projeto
vai se tornando mais complexo.
10. O que é preciso antes de iniciar?
3. Combinado entre todos os membros da
equipe
• Integração contínua é uma prática e não uma
ferramenta.
• Requer um grau de comprometimento e disciplina dos
membros da equipe.
• É preciso que todos “comitem” frequentemente
pequenos incrementos/mudanças.
• A tarefa de maior prioridade é consertar qualquer
mudança que tenha quebrado a aplicação.
11. Sistema Básico para IC
• Hudson e CruiseControl (open source)
• Pré-condições para iniciar o uso.
– Informar onde encontrar o código no repositório.
– Que script executar para compilar o projeto.
– Que script executar para rodar os testes.
– Como informar a equipe que a última mudança
quebrou o software.
12. Processo IC
1. Verifique se o build ainda está rodando. Em caso positivo aguarde o término. Se
falhar, trabalhe com a equipe para fazê-lo passar antes de dar o check-in.
2. Quando tiver terminado e os testes tiverem passados, atualize o código no seu
ambiente de trabalho
3. Rode o script de build e testes na sua máquina para ter certeza que tudo está
funcional no seu ambiente de trabalho, ou alterantivamente use sua ferramente de
IC pessoal.
13. Processo IC
4. Se o seu build local passar, check seu código para o controle de versão.
5. Espere a ferramente de IC executar o build com suas mudanças
6. Se falhar, conserte o problema imediatamente no seu ambiente de trabalho e
volte ao passo 3.
7. Se o build passar, alegre-se e mova para a próxima tarefa.
14. Pré-requisitos para IC
• Check-in no trunk regularmente.
– As alterações serão menores, menos provável de
quebrar o build.
– Significa que há uma versão do SW funcional
recente a ser revertida se você fizer algum erro.
– Ajuda a equipe a ser mais disciplinada com seus
refactorings.
– Garantir que mudanças que alteram muitos
arquivos são menos prováveis de dar conflito com
o trabalho de outros da equipe.
15. Pré-requisitos para IC
1. Check-in no trunk regularmente.
– Permite o desenvolvedor explorar mais
alternativas, experimentando ideias e as
descartando, revertendo a versão para a anterior.
– Força a pausas regulares para esticar os músculos
ajudando a evitar a síndrome do carpo.
– E se algo de catastrófico acontecer, ninguém
perde um grande trabalho.
16. Pré-requisitos para IC
• O check-in deve ser feito no trunk, pois não é
aconselhável trabalhar com branches.
• É impossível fazer IC usando branches, porque
por definição, se estiver trabalhando em
branches seu código não está sendo integrado
com o de outros desenvolvedores.
17. Pré-requisitos para IC
2. Criar uma suite de testes automatizados
– É essencial ter um nível de testes automatizados
para fornecer confiança de que seu software está
funcionando.
• Testes unitários
• Testes de componente
• Testes de aceitação
18. Pré-requisitos para IC
• Testes Unitários
– Testa partes pequenas e isoladas da aplicação
(método, função, ou interação entre alguns deles).
– Não se conecta o banco de dados, arquivos de
sistema ou a sua rede.
– Podem ser executados sem que a aplicação esteja
num ambiente semelhante ao de produção.
– Devem rodar rapidamente, toda a suíte em mais
ou menos 10 minutos.
19. Pré-requisitos para IC
• Testes de Componente
– Testa o comportamento de vários componentes
da aplicação.
– Podem ser executados sem que a aplicação esteja
num ambiente semelhante ao de produção.
– Conceta-se ao banco de dados, arquivos de
sistema ou a sua rede.
– Tipicamente demoram a ser executado.
20. Pré-requisitos para IC
• Testes de Aceitação
– Testa se a aplicação atende aos critérios definidos
pelo negócio para aceitação, incluindo
funcionalidade e também características como:
capacidade, disponibilidade, segurança, etc.
– Preferencialmente executados num ambiente que
simule o de produção.
21. Pré-requisitos para IC
3. Mantenha o build e o processo de teste
unitário curto. 10 minutos é o tempo limite
– Equipe deixará de fazer esse processo na sua
área de trabalho e teremos mais builds
quebrados.
– IC vai levar também tanto tempo que multiplos
commits irão ocorrer e não será possível detectar
qual check-in quebrou.
– Equipe fará check-in com menos frequência.
22. Pré-requisitos para IC
4. Administre sua área de trabalho
– Cada membro da equipe deve ser capaz de rodar
o build, executar os testes automatizados e fazer o
deploy da aplicação em um ambiente sobre o seu
controle.
23. Usando Software de IC
• Operações Básicas
– Executar um simples worflow em intervalos
regulares
– Prover uma forma visual de analisar os resultados
• Chamando a atenção
– Enviar o status do build mais recente para outro
dispositivo.
• Indicadores com lâmpadas, som, falando nome do
desenvolvedor que quebrou o build…
24. Boas Práticas
1. Não dar check-in em um build quebrado.
2. Sempre executar localmente os testes antes
de commitar.
3. Esperar os testes serem executados antes de
mover adiante.
4. Nunca ir para casa se um build quebrar.
25. Práticas Essenciais
5. Sempre estar preparado para reverter a uma
versão anterior.
6. Estabelecer um timebox antes de reverter.
7. Não “comentem” os testes que falharam.
8. Assuma a responsabilidade de todos os
testes que quebrarem pelo resultado de uma
mudança sua.
9. TDD.
26. Estratégia de Testes
• Testar é uma atividade que deve
– Envolver toda a equipe
– Ser feita continuamente desde o início do projeto.
• Construir qualidade significa escrever testes
automatizados em diversos níveis e executá-
los como parte do pipeline de deployment.
• Testes manuais também são essenciais para
construir a qualidade do software.
27. Estratégia de Testes
• Testers colaboram com desenvolvedores e
usuários para escrever os testes
automatizados.
• Os testes devem ser escritos antes de ser
iniciado o desenvolvimento de uma história
28. Tipos de Testes
Business facing
Automated Manual
Support Programming Showcases
Functional acceptance
Usability testing
Critique Project
test
Exploratory testing
Unit tests Nonfunctional
Integration tests acceptance tests
System tests (capacity, security,…)
Automated Manual/Automated
Technology Facing
Brian Marick
29. Suporte a Tecnologia e
Desenvolvimento
• Responsabilidade exclusiva
dos desenvolvedores
– Unitários
Support Programming
– Integração / Componente
– Deployment / Sistema
Unit tests
Integration tests
System tests
Automated
Technology Facing
30. Teste de Integração
• Se refere a testes que garantem que cada
parte independente da aplicação funciona
corretamente com serviços dos quais
dependam.
• Podem ser escritos como são os testes de
aceitação
31. Teste de Integração
• Devem ser executados em dois contextos:
1. Interfaceando com os sistemas externos dos quais
dependem ou com replicas controladas pelo
provedor
2. Interfaceando com equipamentos de testes
desenvolvidos como parte do código base.
32. Suporte ao Negócio e
Desenvolvimento
Business facing
Automated
• Responde as perguntas:
Support Programming
Functional acceptance
test
– Como eu sei que está done?
(para desenvolvedor)
– O done é o que eu realmente
queria?
(para usuário)
• Preparando o teste
– Dado [] quando[], então[]
33. Negócio e Desenvolvimento
Business facing
Automated
• Preparando o teste
Support Programming
Functional acceptance
test
– Dado [1] quando[2], então[3]
1. Importantes características
do estado do sistema.
2. O usuário executa algumas
ações específicas.
3. Importantes características
do novo estado do sistema.
34. Processo – Teste Aceitação
• No início de cada iteração reunir
cliente, analistas e testers para levantar o
cenário de maior prioridade a ser testado.
• Usar ferramentas para escrever em linguagem
natural os testes e que permitam depois criar
o código para fazer os testes serem
executados. Exemplos:
– Cucumber / Jbehave / Concordion / Twist
35. Processo – Teste Aceitação
• Refatoração no código de teste implica em
atualização da especificação do teste.
• Usar uma linguagem específica do domínio
(DSL) para testar, isso permite que os critérios
de aceitação entrem em DSL também.
36. Processo – Teste Aceitação
• Testers e desenvolvedores se reunem antes do
início do desenvolvimento da história para
discutir os testes de aceitação.
– Isso permite aos desenvolvedores terem uma boa
visão da história e entenderem qual o cenário mais
importante.
– Reduz o ciclo de feedback entre desenvolvedores e
testers que pode acabar acontecendo ao final do
desenvolvimento.
– Ajuda a reduzir tanto funcionalidades não
implementadas, quanto o número de bugs.
37. Suporte ao Negócio e Projeto
Business facing
Manual
• Não apenas valida se a
Showcases
aplicação atende a Usability testing
Critique Project
especificação, mas se a Exploratory testing
especificação está correta.
• Desenvolvimento de software
é um processo iterativo.
38. Suporte ao Negócio e Projeto
Business facing
Manual
• Showcases
– Equipe ágeis com produto após Showcases
iteração. Usability testing
Critique Project
• Exploratory Exploratory testing
– Controla a criação dos testes
enquanto sendo executados e usa os
resultados são usados para criar
novos testes automatizados
• Usability
– Descobre quão fácil é para o usuário
alcançar seus objetivos com o SW.
39. O que testar? Novo Projeto
• Iniciar escrevendo testes de aceitação
automatizados. Para isso:
– Escolher uma plataforma e uma ferramenta de
teste
– Set up o build automático
– Trabalhar em histórias que sigam os princípios
INVEST
(Independent, Negotiable, Valuable, Estimable, Sm
all, and Testable)
40. O que testar? Novo Projeto
• Processo
– Cliente, analistas e testers definem os critérios de
aceitação
– Testers trabalham com os desenvolvedores para
automatizar os testes de aceitação baseado nos
critérios definidos
– Desenvolvedores codificam o comportamento
para atender os critérios de aceitação
– Se os testes falharem, prioridade em acertar o
código.
41. O que testar? Projeto em
Andamento
• Começar pelo caso de uso mais comum,
importante e de maior valor da aplicação.
– Conversa com o cliente para identificar onde o
valor do negócio está centrado.
– Automatizar o fluxo básico que cobre esse cenário
de alto-valor.
– Em adição, maximizar o número de ações que
esses testes cobrem.
42. Referência:
• Dave Farley
• Jez Humble
Sobre os autores…
- Nãoháinteresseemtentarexecutar a aplicação antes de tudoestar pronto.
- Para dar tempo a equipe de fazer merge, integrarostrabalhos e tornar a aplicaçãofuncionalparaos testes de aceitação.
- A todoinstante, significa, todavezquealguémcomitarqualquermudança no controlador de versão.- Com a integraçãocontínuaseu software é comprovadoquefunciona a cada nova mudança.
Controle de VersãoRepositório de tudo do projeto: código, testes, scripts de BD, build, scripts de deployments e o quemais for precisopara: criar, instalar, rodar e testar a aplicação.Build AutomáticoDeve ser possívelrodar o build de forma automática do ambiente de integraçãocontínua, de forma quepossa ser auditadoquandoalgodererrado.
Parececontrovérsia, uma fez quetemos IDEs sofisticadasparafazeresseprocesso, mashárazõespara a IC,quesão: