Apresentação de Victor Hugo Germano
Uma pequena transcrição da palestra:
- Vamos falar de Integração contínua e os benefícios da automatização de build
- Eu? Eu sou o victor! Um pouco sobre mim...
- Agenda da apresentação
- 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!
- 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.
- 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).
- 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
- 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.
- 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:
- Valor de Negócio. Perceptível pelo cliente: respostas rápidas às mudanças, alinhamento com as necessidades do negócio e satisfação
- Trocando em miúdos, é necessário criar um Botão Virtual, que nos possibilite entregar, rapidamente, valor ao cliente.
- Isto é integração contínua
- Representação Grafica do processo
- Citando as principais etapas do processo: Construção, Testes, Inspeção e Feedback
- 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)
- 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
- 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
- Pra não ficar por menos, algumas ferramentas!
- 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
- 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...
- Imagine aplicar os conceitos de Business Intelligence para software? Cria-se assim aSoftware 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...
- Como reunir tudo isso?? ora! ferramentas de feedback... segue uma pequena lista...
- Referencias
- Obrigado!!
- Obrigado pela oportunidade
- Dúvidas...
mas cadê os slides da apresentação??
ResponderExcluir