Integração Contínua?

Integração contínua uma prática essencial na engenharia de software atual, e sem ela, não teríamos como garantir qualidade diante da complexidade dos modelos atuais.

Quando falamos de integração contínua, temos que entender que essa prática tem como fundamento o modelo de equipe de desenvolvimento software onde os desenvolvedores fazem "updates" diários em suas estações de trabalho logo ao iniciarem suas atividades, e gerentes de projetos e líderes técnicos, verificarem os logs dos builds do dia anterior. Caso se demore para fazer "updates" ou ninguêm se importe com builds quebrados, integração contínua não faz se faz presente em sua melhor característica: "Capturar rapidamente bugs e também corrigí-los rapidamente".

Temos que entender também, que a partir do uso desse modelo de desenvolvimento ágil com updates diários, surgiu a necessidade de ferramentas de automatização desses builds. Assim surgiram os servidores de integração contínua. Exemplos como Apache Continuum, Bamboo, Hudson, TeamCity, CruiseControl, Selenium, CCTray,CCMenu, Xvfb, e outros.

Outra característica importante a ser explicitada é que servidores de integração contínua estão desacoplados de estratégias de build. Existem várias API's de build no mercado como Maven, Ant, MS-builder e outras.

Cada builder tem um grupo de estratégias de versionamento, componentização, testes mais apropriadas a determinadas necessidades de projetos. Hoje, tenho trabalhado com os builders Maven, Ant, e Ms-build; e cada projeto tem sua estratégia de versionamento.

Os build's diários que basicamente fazem compilação, testes e montagens; estão nos ajudando também a executar de forma automatizada atividades como atualização de ambientes (desenvolvimento, suporte e testes), geração de mídias de instalação, atualização de update sites entre outras.

Quase tudo pode-se automatizar nesses servidores de integração contínua e principalmente trabalhar de forma integrada com ferramentas de bug tracking como por exemplo Jira.

Outro pilar importante em todo esse processo de integração contínua, são as ferramentas de controle de fontes. Saber utilizar ferramentas fontes é essencial pois suas estratégias básicas devem representar os planos de produto.

Então planejar produto de forma clara é o insumo principal do uso dessa ferramenta. Para equipe de produto, isso não significa ter que saber tudo sobre linhas base de fontes, marcações e apavorantes merges.

Com esse plano de produto os integradores podem planejar e controlar melhor as linhas bases de fontes de seus projetos e como representá-lo corretamente diante desse ciclo de vida do produto, definido no plano de produto.

Falta de planejamento, tanto de equipe de produto como de equipe de integradores, significa dores de cabeça na hora dos merges.

Em seguida estarei escrevendo um pouco mais sobre estratégias de versionamento dependendo do builder escolhido no projeto.

Felicidades e t+;

Um 2009 cheio de colheitas

Aos amigos e colegas.

Final de ano... Época aonde as esperanças se renovam... Época aonde refletimos sobre o ano que passou e tentamos influenciar nosso futuro.

Durante 2008, muitos investimentos, de tempo, de esforço, de dedicação. Plantamos sementes de realização, de amor, de felicidade, de esperança...

Algumas frutificaram durante 2008. Temos que continuar a cuidar de nossa plantação, para que em 2009, possamos colher muitos frutos....

Um final de ano cheio de paz, harmonia e amor entre todos seus familiares, e um ano novo repleto de colheitas.

São os votos do Fábio Dippold.

Reuso de Software

Reutilização. No contexto de desenvolvimento de software, esta é a palavra-chave para aumento de produtividade, qualidade e redução de custos. Quanto menos linhas de código são reescritas – fato que geralmente acontece por falta de planejamento e organização de conhecimento –, mais software novo pode ser criado. O aumento de qualidade se dá com a utilização deste código já bem documentado e testado.
O ponto chave do sucesso dessas organizações é que elas possuem a coragem que falta em outras, para “perder” parte do seu staff, momentaneamente, "pensando e fazendo, exclusivamente" reuso de software e depois, se deleitar dos benefícios obtidos pela decisão corajosa.
O reuso de software é o uso de software existente para o desenvolvimento de novo software.
No reuso de software duas decisões estão envolvidas. A primeira é se devemos, ou não, adquirir software para reusar. Sistemas operacionais devem ser comprados, bibliotecas de códigos devem ser desenvolvidas, ou compradas, arquiteturas de domínio específico para famílias de produtos devem ser produzidas.Se o software a ser reusado já é possuído como resultado de outra atividade, esta decisão é desnecessária.A segunda decisão é se devemos, ou não, reusar software em instâncias particulares.

A questão é: o desenvolvedor deve escrever uma rotina, ou deve buscá-la na Internet? Justamente pelo fato de que o processo de reuso de software envolve encontrar software, entender como reusá-lo, e talvez, modificá-lo antes de ser de fato reusado, pode ser mais atrativo para redesenvolver.

Algumas vezes estas decisões são simples.Muitas formas de reuso de software não são comumente denominadas de “reuso”; elas são práticas padrões já que não há alternativa real.No entanto, algumas decisões são menos simples, ou diretas, e requerem análise apropriada antes delas serem tomadas.
Mas como?

Neste sentido, um modelo de adoção de reuso (ou seja, uma estratégia) ajuda a organização a entender como o reuso irá mudar o modo como ela faz negócios, e como ela deve planejar para esta mudança. Um modelo de adoção de reuso é um guia para o processo de melhoria. Ele sugere área onde a capacidade pode ser medida de modo sistemático em uma organização num dado ponto do tempo.

As técnicas são:

• Adoção de reuso no processo de desenvolvimento software
• Engenharia de domínio
• Componentização
• Frameworks
  
• Linhas de Produtos
• Utilizar padrões de projeto (Design Patterns)

Comunicação eficiente

A maioria dos projetos é uma salada de personagens e interesses. Alguns apóiam o projeto, outros o rejeitam. Alguns entendem que a metodologia pode trazer produtividade e controle, enquanto outros a consideram burocracia desnecessária. Há ainda aqueles que terão vários benefícios com o produto do projeto, e outros que serão afetados negativamente.

Neste contexto, a comunicação é um fator essencial para obter melhores resultados e prosseguir com o projeto sem maiores tropeços.

O Gerente de Projeto deve ter objetividade em sua comunicação. O fato é que nem sempre a informação que ele precisa chegará de forma direta e clara. Para isto, sugiro o seguinte:

1) Faça perguntas difíceis. É muito confortável fazer uma reunião na qual não há questionamentos… mas também totalmente inútil. O bom Gerente de Projeto sabe fazer as perguntas difíceis, que realmente trazem à tona a situação das atividades, expõem riscos e tiram a equipe da zona de conforto. A sensação falsa de controle é um dos maiores problemas que o Gerente pode encontrar.

2) Não aceite respostas incompletas. Não é difícil perceber quando você está sendo enrolado. Insista até obter informações claras (com as perguntas difíceis) e mostre que não está para brincadeiras.

3) Formalize o necessário. Ninguém gosta de usar seu tempo escrevendo e-mails e relatórios, mas estes são necessários. É responsabilidade do Gerente de Projeto definir um Plano de Comunicação que permita o mínimo possível de formalidade sem perder o registro das informações importantes do projeto. Lembre-se que a informação bem documentada aumenta a responsabilidade dos envolvidos.

4) Saiba quem é quem. A análise dos stakeholders é uma ferramenta importante para preparar sua comunicação. Quando você sabe quem se encaixa em cada um dos perfis que descrevi no primeiro parágrafo deste artigo, conseguirá adaptar sua comunicação para obter o melhor de cada um.

5) Dê seguimento. Em inglês existe o termo “head fake”, que é aquela situação na qual se discute algo em uma reunião, todos concordam balançando a cabeça, mas depois da reunião é como se nada tivesse acontecido. Acho que todos sabem do que estou falando. Quando o Gerente de Projeto dá seguimento estrito a todas as decisões e atividades do projeto, a equipe entenderá que terá que ser responsável por suas ações e atitudes.

6) Dê o Exemplo. Mesmo que não tenha autoridade formal sobre a equipe (acontece em muitas empresas), o Gerente de Projeto deve assumir uma posição de liderança em relação às boas práticas em projetos. A velha frase “Em casa de ferreiro o espeto é de pau” não se aplica nesta situação. Ao mostrar um nível de controle e produtividade avançados, o Gerente de Projeto mostrará à equipe os benefícios de seguir a metodologia e se comunicar abertamente.

Para finalizar, uma recomendação geral: especialmente no Brasil, ainda há o costume de não dizer exatamente o que pensamos, seja por medo da reação, seja para não ferir os sentimentos do outro ou até porque é mais fácil evitar qualquer tipo de conflito (mesmo o conflito construtivo). Mesmo que isto tenha uma base cultural, temos que adquirir gradualmente o costume da comunicação aberta e objetiva (nos negócios!). Os benefícios serão para todos os envolvidos na comunicação.

Texto capturado do site: http://ogerente.com.br

Commited to open source

Uma frase muito comum no mundo dos negócios entre os grandes
“players” do mercado de software (IBM, Oracle, Sun e outros) em relação do software livre é: “commited to open source”. Em outras palavras, as empresas desenvolvedoras estão aderindo ao modelo “open source” com uma presença cada vez mais relevante, para oferecer mais opções, flexibilidade e um baixo custo para computação para seus usuários finais.
O Gartner prevê que “até 2012, 80% de todos os softwares
comerciais irão incluir elementos tecnológicos de software aberto. Muitos dispositivos de software aberto são maduros e estáveis, permitindo redução nos custos e retorno do investimento.”
Para desenvolver essa oferta junto a seus produtos, é necessário um significativo investimento em desenvolvimento, testes, otimizações e suporte a a essas tecnologias “open source” escolhidas como por exemplo: JBoss, Apache, Eclipse e outros.

Um vídeo que todos deveriam ver...

Design Patterns

Na curta, porém rapidamente evolutiva história das ciências da computação e da engenharia de software, variaram muito as técnicas, métodos, processos, meios e recursos utilizados. Os projetos fracassavam com freqüência porque os desenvolvedores não conseguiam comunicar um ao outro bons projetos de software, arquiteturas e práticas de programação. Não faz muitos anos, estruturas de dados, fluxogramas e técnicas modulares de programação dominavam o cenário. Então, o paradigma de orientação a objetos iniciou sua trajetória. No contexto do desenvolvimento de software orientado a objetos, os padrões de projeto (…) tornaram-se um dos tópicos mais “quentes” na área de engenharia de software nos últimos anos. O simples uso da OO não garante que obtenhamos sistemas confiáveis, robustos, extensíveis e reutilizáveis. O foco das metodologias de desenvolvimento está na solução em si (o que e como) e não em suas justificativas (porque).

“Um Pattern descreve um problema que se repete várias vezes em um determinado meio, e em seguida descreve o núcleo da sua solução, de modo que esta solução possa ser usada milhares e milhares de vezes” [Christopher Alexander]. Sistematicamente nomeia, motiva e explica um projeto genérico, que endereça um problema de projeto recorrente em sistemas orientados a objetos.

As principais vantagens de utilizarmos padrões são:

• Capturam o conhecimento e a experiência de especialistas em projeto de software, pois difícil compartilhar a experiência entre experts e novatos
• Especificam abstrações que estão acima do nível de classes ou objetos isolados ou de componentes [Gamma et al 1995].
• Definem um vocabulário comum para a discussão de problemas e soluções de projeto [Gamma et al 1995].
• Facilitam a documentação e manutenção da arquitetura do software [Buschmann et al 1996].
• Auxiliam o projeto de arquiteturas mais complexas.
  

Reusabilidade real não se obtém de técnicas de “cut & paste” nem do simples reaproveitamento de módulos de software. E melhora do uso não se obtem reusando o mesmo template milhares de vezes e sim entendendo a tarefa do usuário e como a funcionalidade se encaixa no processo.

Este texto foi compilado a partir de várias fontes publicadas na internet.