Este é um post disponível para assinantes MVPEste post também está disponível para assinantes da .net Magazine DIGITAL ou para quem possui Créditos DevMedia. Clique aqui para saber mais!
dê seu feedback
post favorito
Integração Contínua - Artigo .net Magazine 85
Este artigo trata de integração contínua, um termo cunhado por Kent Beck em seu livro sobre Extreme Programming, que define uma prática aplicada na indústria há muito tempo.
.net Magazine 85
[Artigo já está disponível no Leitor Digital DevMedia®. Clique aqui para acessá-lo]
> Clique aqui para ler todos os artigos da .net Magazine 85
[Artigo já está disponível no Leitor Digital DevMedia®. Clique aqui para acessá-lo]
> Clique aqui para ler todos os artigos da .net Magazine 85
Integração Contínua
Práticas para facilitar um modelo de trabalho mais fluido
Em um projeto de software, desenvolvedores trabalham gerando código-fonte e outros artefatos que compõem um sistema maior. Cada desenvolvedor realiza um conjunto de tarefas que normalmente têm relação com as tarefas que outros desenvolvedores estão realizando. Apesar de um software ser um sistema determinístico, o resultado da relação entre cada um dos componentes de um programa pode ser imprevisível.
Sabendo isso, fica claro o quão complicado pode ser trabalhar num software em equipe. Quanto maior a equipe, maior é o desafio. Em um projeto de grande porte, o processo de integração do trabalho de pessoas em várias equipes pode levar dias, semanas ou até meses.
Quanto mais tempo um desenvolvedor ou equipe trabalha sem integrar seu trabalho com o de seus colegas, mais difícil será essa integração quando acontecer. Nesse ponto entra a integração contínua, que visa diminuir esse problema, ao tentar realizar essa integração com a maior frequência possível. Nem sempre essa é uma tarefa fácil.
O termo “Integração Contínua” foi documentado pela primeira vez como um dos 12 princípios da Extreme Programming. Desde então, muito tem se falado sobre ele nos mais diversos contextos. Isso acontece porque a prática deste princípio permeia quase todos os processos do desenvolvimento de software, alimentando ou recebendo feedback de outras práticas.
Nota do DevMan
XP é Extreme Programming, uma metodologia ágil de desenvolvimento de software. Ela é baseada em uma série de princípios que se complementam, por exemplo, pair programming, TDD, iterações curtas etc. Foi descrita por Kent Back, em seu livro sobre o assunto. Desde então, XP tornou-se uma das metodologias ágeis mais famosas. Apesar de relativamente nova, seus princípios vêm sendo discutidos há muito tempo na indústria e na comunidade científica.
Muitos desenvolvedores argumentam que aplicar integração contínua se revela muito custoso no processo de desenvolvimento e que, para ter sucesso, muitas mudanças precisam ser feitas. De fato, muitas vezes isso é verdade. Mas aplicar a integração contínua, assim como o TDD, não é o motivo de tal dificuldade, mas sim a negligência de outras boas práticas complementares.
A integração contínua não é só uma prática, mas um princípio. Não é possível implantar integração contínua por si só. Ela deve ser alcançada através da implantação de outras práticas. Várias delas serão discutidas neste artigo.
Um ciclo de integração sustentável
É comum acreditar que a integração contínua acontece num servidor de build. Entretanto, a maior parte das práticas deve acontecer no dia-a-dia do desenvolvedor. E para que tudo isso funcione, deve existir um ciclo comum que defina como integrar o código.
Deve existir um repositório comum, acessado por todos os membros da equipe, que contenha todo o código já integrado até certo momento da vida de um software. Esse repositório central é chamado de “mainline”. Existem muitas estratégias sobre como gerenciar a mainline e as várias versões que ela armazena. Isso será discutido mais à frente.
"
ATENÇÃO! A exibição deste artigo foi interrompida.
Este é um post disponível para assinantes MVP
Práticas para facilitar um modelo de trabalho mais fluido
Em um projeto de software, desenvolvedores trabalham gerando código-fonte e outros artefatos que compõem um sistema maior. Cada desenvolvedor realiza um conjunto de tarefas que normalmente têm relação com as tarefas que outros desenvolvedores estão realizando. Apesar de um software ser um sistema determinístico, o resultado da relação entre cada um dos componentes de um programa pode ser imprevisível.
Sabendo isso, fica claro o quão complicado pode ser trabalhar num software em equipe. Quanto maior a equipe, maior é o desafio. Em um projeto de grande porte, o processo de integração do trabalho de pessoas em várias equipes pode levar dias, semanas ou até meses.
Quanto mais tempo um desenvolvedor ou equipe trabalha sem integrar seu trabalho com o de seus colegas, mais difícil será essa integração quando acontecer. Nesse ponto entra a integração contínua, que visa diminuir esse problema, ao tentar realizar essa integração com a maior frequência possível. Nem sempre essa é uma tarefa fácil.
O termo “Integração Contínua” foi documentado pela primeira vez como um dos 12 princípios da Extreme Programming. Desde então, muito tem se falado sobre ele nos mais diversos contextos. Isso acontece porque a prática deste princípio permeia quase todos os processos do desenvolvimento de software, alimentando ou recebendo feedback de outras práticas.
Nota do DevMan
XP é Extreme Programming, uma metodologia ágil de desenvolvimento de software. Ela é baseada em uma série de princípios que se complementam, por exemplo, pair programming, TDD, iterações curtas etc. Foi descrita por Kent Back, em seu livro sobre o assunto. Desde então, XP tornou-se uma das metodologias ágeis mais famosas. Apesar de relativamente nova, seus princípios vêm sendo discutidos há muito tempo na indústria e na comunidade científica.
Muitos desenvolvedores argumentam que aplicar integração contínua se revela muito custoso no processo de desenvolvimento e que, para ter sucesso, muitas mudanças precisam ser feitas. De fato, muitas vezes isso é verdade. Mas aplicar a integração contínua, assim como o TDD, não é o motivo de tal dificuldade, mas sim a negligência de outras boas práticas complementares.
A integração contínua não é só uma prática, mas um princípio. Não é possível implantar integração contínua por si só. Ela deve ser alcançada através da implantação de outras práticas. Várias delas serão discutidas neste artigo.
Um ciclo de integração sustentável
É comum acreditar que a integração contínua acontece num servidor de build. Entretanto, a maior parte das práticas deve acontecer no dia-a-dia do desenvolvedor. E para que tudo isso funcione, deve existir um ciclo comum que defina como integrar o código.
Deve existir um repositório comum, acessado por todos os membros da equipe, que contenha todo o código já integrado até certo momento da vida de um software. Esse repositório central é chamado de “mainline”. Existem muitas estratégias sobre como gerenciar a mainline e as várias versões que ela armazena. Isso será discutido mais à frente.
"
ATENÇÃO! A exibição deste artigo foi interrompida.
Este é um post disponível para assinantes MVPEste post também está disponível para assinantes da .net Magazine DIGITAL ou para quem possui Créditos DevMedia. Clique aqui para saber mais!
Você está em:
canal .net
Publicidade
Juan Lopes
Space do autor
Arquiteto de soluções pela Living Consultoria. Iniciou a carreira desenvolvendo aplicações biométricas em C++ e Java. Programa principalmente em C# desde 2007, mas desenvolve também em Ruby e Python. É entusiasta da comunidade Microsoft e participa de projetos open source.
Space do autor
1
0
