Páginas

Mostrando postagens com marcador IntegraçãoContínua. Mostrar todas as postagens
Mostrando postagens com marcador IntegraçãoContínua. Mostrar todas as postagens

01 dezembro 2008

TDC 2008: Integração Contínua

Saudações!

Gostaria de disponibilizar a minha apresentação, realizada no TDC 2008 Floripa.




Uma pequena transcrição da palestra:
  1. Vamos falar de Integração contínua e os benefícios da automatização de build
  2. Eu? Eu sou o victor! Um pouco sobre mim...
  3. Agenda da apresentação
  4. Tudo começa com as origens: tradicionalmente, o momento de integração era a realização de um grande passo no projeto - juntar tudo - e obviamente que, na teoria, a vida é sempre bela!
  5. Minha percepção desse modelo, inclusive ensinado nas universidades por essas bandas: O Mais puro conto de fadas! Com direito a vestido esvuaçante, sapatinho de cristal e castelo ao fundo.
  6. Como em todo conto de fadas, acreditamos em uma série de premissas, e a principal delas é: nossos clientes estão dispostos a esperar por resultados apenas no longo prazo. Qualidade nunca é importante o suficiente (afinal, se houver tempo, pode cortar os testes).
  7. Mas a realidade é sombria, e extremamente dura com akelas que entram no mercado de trabalho: riscos sempre são subestimados, retrabalho em um Pattern, atrasos uma constante
  8. Precisamos nos preparar para um mundo novo, onde Clientes não podem e não querem esperar por software. E para isso, precisamos eliminar desde as primeiras fases de um projeto riscos com integração de software. É necessário também estar preparado para realizar mudanças rápidas, e responder às interpéries e baixas do mercado. E por último, e conseguirmos reduzir custos de produção, com certeza estaremos mais preparados.
  9. Se conseguíssemos reunir: Velocidade para atendimento de requisições de um cliente, Qualidade para evitar que decisões de hoje não alterem as decisões de amanha, além de recolher informações para a tomada de decisão, chegaremos a:
  10. Valor de Negócio. Perceptível pelo cliente: respostas rápidas às mudanças, alinhamento com as necessidades do negócio e satisfação
  11. Trocando em miúdos, é necessário criar um Botão Virtual, que nos possibilite entregar, rapidamente, valor ao cliente.
  12. Isto é integração contínua
  13. Representação Grafica do processo
  14. Citando as principais etapas do processo: Construção, Testes, Inspeção e Feedback
  15. Construção: normalmente confundido com o próprio termo de Integração Continua. Representa a automatização da construção do sistema, utilizando normalmente uma ferramenta de script (ant ou maven)... (por causa desse slide, o motivo do primeiro slide - essa a automatização em si - integrando todas as ferramentas citadas nessa apresentação)
  16. Pausa para uma reflexão: Esqueca TODA esta apresentação se você não utiliza controle de versões... não caia nesse erro: CONTROLE DE VERSÕES É PRIMORDIAL!!! Saia da idade da pedra! Páre de guardar HD's antigos ou código fonte zipado
  17. Testes: Sim, devem existir! É irresponsabilidade profissional não existir testes unitários automatizados para cada linha de teste! Neste ambiente, não fala-se apenas de testes unitários: aceitação, performance, integração, carga... IC significa mitigar riscos criando um ambiente de testes para garantir que sua base de código é confiável
  18. Pra não ficar por menos, algumas ferramentas!
  19. Inspeção: Tradicionalmente existe um problema em criar equipes independentes de qualidade/teste e desenvolvimento. Imagine o seguinte exemplo - você está lah no bem bom com a patroa e um cara do lado te dizendo "Não cara, não é assim, mais pro lado... isso não estava no roteiro, vc não pode colocar esta perna aí, é para o outro lado...". Para resolver este problema, podemos nos valer de anos de estudo de autores e desenvolvedores e buscar formas de mensurar qualidade de código através de métricas conhecidas, e através de ferramentas
  20. Mais ferramentas: Você se acha bom desenvolvedor? Então execute o CPD no seu código, e depois conversamos! Com estas ferramentas, a própria aceitação dos desenvolvedores será influenciada: não é o zé mané da qualidade falando, é uma ferramenta... normalmente a impressão é melhor...
  21. Imagine aplicar os conceitos de Business Intelligence para software? Cria-se assim a Software Itelligence, tomada de decisão através de dados concretos, acompanhados desde o início do ciclo de vida do produto, para que se possa tomar decisões a respeito do software utilizando cobertura de código, comportamento de testes, avaliação de duplicidade de código, avisos do compilador... muito mais acertivo que os achismos de especialistas...
  22. Como reunir tudo isso?? ora! ferramentas de feedback... segue uma pequena lista...
  23. Referencias
  24. Obrigado!! Obrigado pela oportunidade
  25. Dúvidas...

E então, você foi na apresentação e gostou??? Faça um comentário! Preciso do feedback para poder melhorar...

O evento foi muito bacana! Alta qualidade, pessoas interessantes e muita diversão!


Obrigado Globalcode e VOffice pela oportunidade! Ao final do evento ainda rolou um Papo de Boteco... coisalinda de Deus!!


[]s!!

26 novembro 2008

The Developer's Conference 2008 - aí vou eu!

Saudações!
Informações de última hora: O Bocão (vulgo Henrique Oliveira) me convidou para falar um pouco sobre Integração Contínua no evento deste final de semana aqui na ilha... e claro, eu topei!

Site Oficial: The Deveoper's Conference - uma realização Globalcode & VOffice

Vou tentar passar a mesma idéia que a apresentação feita no GuJavaSC deste ano, focando bastante no conceito por trás de todo o processo de integração contínua, e apresentando algumas ferramentas. Será uma apresentação rápida, e portanto, nada de muito blablabla ou piadinha... direto ao ponto...

Mais informações na Programação do Evento (sim, eu sei, meu nome não aparece ali... espero que atualizem logo...). A grade do evento está bastante interessante, vale a pena conferir!

[]s

17 junho 2008

Integração Contínua em Java at GUjSC

Yeah!!
Bem, após transtornos com a queda do servidor do SlideShare, consigo finalmente disponibilizar a apresentação de hoje!

Realizada no Auditório do EPS, acredito que perto de 20 pessoas compareceram...

Bem, não sou eu que deve postar as impressões da apresentação: se algum de vocês me viu falando, comente!

Gostei bastante da receptividade e dos comentários durante o coffee break (habib's!!!! adoro esfiha...)

Segue abaixo a apresentação:


[embed]Link da apresentação[embed]





Sobre a apresentação do Andrik: muito bacana!!! Pow, deu muita curiosidade de ver o tal Gant funcionando em nosso ambiente de IC lah na Audaces. Parabéns pela apresentação...


Obrigado ao GUjSC pelo convite... e sabe como é, derrubou na área é pênalt e se precisar, cola em mim que é só sucesso!!!

[]s

Projetinho exemplo: Integração Contínua

Saudações!

Como vcs devem saber, hoje tenho uma apresentação sobre Integração Contínua no auditório do EPS às 18:40...

Como forma de ilustrar a minha apresentação, vou disponibilizar um arquivo contendo um projetinho de exemplo - feito no eclipse, óbvio - e que junta ant+junit+mocks+javadoc+findbugs+dbunit+sqlite para apresentar como é possível iniciar um projeto já pensando em qualidade de software.

É um projeto beeeeeem simples, apenas com uma tela de login e uma listagem qualquer... o foco da aplicação é comprovar o conceito que vou descrever hoje... espero vocês por lá!

Download do Arquivo: userAdminIC.tgz

[]s
Victor

12 junho 2008

Evento GUJavaSC


Saudações!
Este blog até que está dando resultado!
Depois de falar a respeito e inclusive publicar uma matéria sobre, me convidaram para falar de Integração Contínua!

Bem, se você quer me ouvir falar que é possível ter software com qualidade, redução de riscos e como você nunca sonhou, venha me ver!

Tudo bem, você pode sair decepcionado, afinal, eu não vou resolver todos os seus problemas... mas uma palestra não serve para isso!
Para resolver esta situação, estarei disponível para conversar e tomar uma cerva depois do evento - sabe como é, sem bebida, nada acontece!

Encontre informações sobre ferramentas e maneiras de trabalhar com seu software que possibilitarão a saúde e bem estar da sua empresa!

Mais informações: Encontro GuJavaSc

29 janeiro 2008

Mitos Ágeis





Certa vez ouvi um palestrante dizer a seguinte frase: "Para os desenvolvedores, XP é uma opção extremamente sexy". E engraçado como tal afirmação é verdadeira. Explicar para alguém que trabalha em um projeto de software é visivelmente mais fácil do que um patrocinador, ou diretor de empresa.

Como uma forma de dar início a um projeto Ágil, tenta-se adaptar as práticas mais apelativas: Testes automatizados, desenvolvimento interativo e pair programming. Mesmo que os benefícios de tais práticas sejam evidentes, é comum que elas sejam mal interpretadas. Isto porque a aparente facilidade que "automatização de testes" ou "programação em dupla" transmite, é completamente diferente da realidade.

Aplicar testes em projetos de software pode ser um processo muito doloroso, por desafiar os principais hábitos dos programadores e trazer uma aparente queda na produtividade. Principalmente por isso, no momento em que você optar em seguir para o "Mundo Ágil", é muito importante utilizar as práticas em sua essência, ganhando a experiência necessária para seguir na criação de um modelo sustentável de desenvolvimento de sofware. É preciso experimentar os reais benefícios das práticas, ganhando confiança para mudanças mais críticas em sua empresa.

Mais uma vez, Ross Pettit apresenta sua visão no site Agile Journal de como a interpretação errada de práticas pode levar a sérios problemas no desenvolvimento, ou ainda causar a impressão errada à equipe e diretoria.

Mito #1: Nós escrevemos testes unitários, mas não importa se eles passam ou não...
Não existe prática com os benefícios mais evidentes que automatizar os testes de software e integrá-los num ambiente de build automático. Entretanto, poucas pessoas se lembram de que é necessário manter os testes criados. Isto é, os desenvolvedores escrevem inúmeros testes automatizados mas não existe a preocupação em manter todos os testes funcionando no momento do build. Assim, a falha de um teste não se torna um "chamado para os desenvolvedores". Esta característica pode ser reflexo de:

  • Pressão para que os desenvolvedores mostrem "código finalizado"

  • Desenvolvedores não sentem responsabilidade pelos testes que eles não escreveram

  • Testes unitário não são desenvolvidos como uma especificação executável, apenas como informação (talvez cumprindo a requisição por documentação)



Desenvolvimento Ágil não é sobre aparências, mas sobre fatos. Esta falsa impressão de qualidade, com a existência de inúmeros testes unitários que não fucionam, deve ser combatida. Sem o comprometimento em manter o conjunto de testes sempre funcionando, todo este código gerado não passará de lixo. Isto mesmo: lixo

Todo o controle de riscos existente em uma equipe Ágil estará perdido. Uma vez que os testes não garantem que o código está funcionando, qualquer problema/bug/nova funcionalidade adicionada não poderá ser analisada com confiança.

(...)
Leia o documento completo

[]s

15 outubro 2007

Integração Contínua



Termo muito importante no mundo Ágil... eu disse muito? Eu quis dizer MUITO!
Sua intenção é ser a panacéia para os males relacionados a builds e gerações de versão para software, além de pode se tornar uma ferramenta bastante importante para tomada de decisão por parte da área gerencial da equipe... a idéia é simples:
um único botão é responsável por disparar uma série de ações que culminam com a contrução do seu sistema... assim, simples... que tal?
A este mesmo procedimento de construção podem ser adicionadas rotinas como:
  • Execução de testes automatizados
  • Geração de versões internacionalizadas de seu software
  • Disponibilizar a versão atual em desenvolvimento para o cliente
  • Criação de relatórios de código como:
  • Cobertura de testes
  • Inspeção de padrões de codificação
  • Estatísticas de acoplamento

Todo o processo segue a arquitetura descrita na imagem abaixo:


O cenário acima pode ser descrito como: (Fonte: Continuous Integration)
  1. O desenvolvedor envia o código para o controle de versão (SVN, CVS, etc). Enquanto isso a máquina de integração (servidor de Integração Contínua) está verificando o repositório buscando por modificações
  2. Logo após um commit ser efetuado, o servidor ao verificar que alguma mudança ocorreu no repositório inicia o processo de build baixando os arquivos do Servidor de Controle de Versão. Assim, o script de build é executado, testes são realizados, relatórios gerados, e todo o projeto é integrado.
  3. O Servidor de Integração envia por e-mail ou outros dispositivos o feedback sobre build para usuários específicos do projeto
  4. O servidor volta ao estado de Poll buscando por mudanças no repositório
Um comportamento importantíssimo: Esta arquitetura força a equipe a manter sempre em funcionamento o código fonte que existir no repositório, adicionando mais controle a possíveis problemas de implementação ou integração.

Encontrei um site comparativo sobre ferramentas de build contínuo: Continuous Integration Matrix. Vale muito a pena dar uma lida. Autalmente utilizando o luntbuild, sem grandes problemas... bastante eficiente a ferramenta.
No livro, algumas outras ferramentas são citadas:
  • Doxygen: Gera diagramas de classes e relacionamento automaticamente para uma infinidade de linguagem. Ferramenta muito poderosa!!
  • X10: Utilizado para controlar qualquer mecanismo que utilize radio frequencia. Ideal para colocar um sirene ao lado com servidor de build para que todos saibam que algo de errado foi enviado ao repositório
  • Sourcemonitor: Geração de métricas sobre desenvolvimento
  • Selenium: Automatize testes de aceitação. Ferramenta show demais!
  • Checkstyle: Ferramenta de inspeção de código para Java

Um exemplo prático pode ser encontrado no site da Improveit

É isso... =)