The Developers Conference 2012

sexta-feira, 8 de junho de 2012


Este ano, vamos marcar presença novamente no evento The Developers Conference 2012
 O evento TDC, é o maior evento de profissionais de TI do Brasil! Mais de 30 trilhas sobre diversas especialidades e  tendências em gestão e tecnologia.



A novidade, é que este ano sou um dos coordenadores das trilhas Arquitetura e Agile
Para a trilha de Arquitetura, estamos buscando criar uma trilha com palestras de alto nível e mais agnóstica. De forma que profissionais de qualquer plataforma possam tirar o máximo de proveito.

Para a trilha Agile, o tema deste ano é "Agile no Mundo Real", seguindo esta linha, estamos trazendo palestras e profissionais para mostrar o que realmente tem acontecido no mercado de agilidade, quais as ferramentas para resolução de problemas utilizados em um projeto de Gestão de Mudança para Agilidade e temas atuais.

Se você quer ser um palestrante, submeta sua proposta no Call4Papers, mas corra, que é o prazo de submissões é até domingo. :)

Nos vemos lá! Diversão garantida!

Estilos de Arquitetura e Separação de Responsabilidades para um Design Ágil

quarta-feira, 1 de fevereiro de 2012

Com a grande demanda de profissionais por parte das empresas, muitos deles acabam sendo contratados sem ter o devido conhecimento sobre boas práticas de desenvolvimento de software, infraestrutura de desenvolvimento, protocolos de comunicação, sistemas gerenciadores de banco de dados e muitas vezes até conhecimento básico sobre sistemas operacionais.

Além disso, dentro das empresas existe uma demanda cada vez maior por projetos de software de alta complexidade, com prazos de entrega na maioria das vezes fora da realidade. O que faz com que muitos projetos sejam entregues sem testes, com falhas de implementação, qualidade duvidosa e muitas vezes sem atender ao negócio do cliente.

Como consequência, após implantado, o sistema passa a apresentar sérios problemas como degradação da performance, perda de dados, cálculos incorretos, entre outros problemas, trazendo grandes prejuízos à empresa e fazendo com que os usuários percam a confiança no sistema e por fim os próprios desenvolvedores.

Direcionado para este cenário, o presente artigo visa demonstrar boas práticas de desenvolvimento de software e explicar os princípios fundamentais para se criar um bom design. Veremos também a aplicação de alguns padrões de projeto pouco difundidos, mas que são de extrema importância no dia a dia do desenvolvedor.

Estilos de Arquitetura

Quando vamos planejar o desenvolvimento de um software, geralmente um dos primeiros itens que o arquiteto de software começa a analisar é qual o melhor estilo de arquitetura que se aplica ao
contexto do projeto. Neste ponto ele leva em consideração diversos fatores, como os requisitos do software, custo, infraestrutura e conhecimento técnico da equipe.

Entender o estilo arquitetural adotado para o desenvolvimento traz diversos benefícios para os desenvolvedores e para a empresa como um todo, entre eles: fornecer uma linguagem comum entre os desenvolvedores e os demais envolvidos no projeto.

Por exemplo, quando o estilo de arquitetura é SOA, os desenvolvedores podem até conversar com pessoas de outras áreas, que não possuem conhecimento técnico (como detalhes da linguagem de programação, servidores de aplicação, etc.), sobre o método envolvido na automação dos processos de negócio, que as mesmas entenderão sobre o que é um serviço, governança e, dependendo do usuário, até termos mais específicos, como escalabilidade.

A Tabela 1 apresenta um resumo dos principais estilos de arquitetura.

Estilo de Arquitetura
Descrição
Client-Server Também conhecida como arquitetura de duas camadas. Este tipo de arquitetura descreve a interação entre um ou mais clientes e um servidor, através de uma conexão de rede. A aplicação mais comum para esse tipo de arquitetura é um Banco de Dados no lado do servidor com a lógica da aplicação representada em Stored Procedures, e o lado do Cliente representado por aplicações conhecidas como Fat-Clients (Clientes Pesados), que muitas vezes contêm a lógica de negócio embutida no front-end. Como exemplo, podemos citar aplicações desenvolvidas com Delphi, Visual Basic, Oracle Forms, entre outros.
Arquitetura baseada em Componentes Quando utilizamos uma arquitetura baseada em componentes, decompomos o design da aplicação em componentes lógicos com um fraco acoplamento, de forma que cada um deles seja individual e reutilizável, com uma localização transparente e interface de comunicação bem definida. Uma das grandes vantagens desse tipo de arquitetura é que ela promove a reusabilidade dos componentes e facilita a manutenção da aplicação.
Domain Driven Design De acordo com o próprio criador, Eric Evans, DDD não é uma tecnologia e nem uma metodologia. DDD é um estilo de arquitetura orientado a objetos, focado em modelar o domínio do negócio e a lógica do domínio com o uso de técnicas, práticas e padrões de projeto.
Arquitetura em Camadas Esse é o estilo de arquitetura mais conhecido e mais utilizado para o desenvolvimento de aplicações. Ele permite a separação dos módulos do sistema em camadas (layers) diferentes. As principais vantagens desse estilo são a facilidade de manutenção, o aumento da extensibilidade, reusabilidade e escalabilidade.
3-Tiers/N-Tiers Esse estilo segrega as funcionalidades em segmentos separados de maneira similar ao estilo da arquitetura em camadas, mas com cada segmento alocado em camadas físicas (tiers) separadas, conforme veremos em detalhes no tópico “Arquitetura Distribuída”.
 Ele é ideal quando o projeto demanda escalabilidade. Para isso, as camadas lógicas (layers) da aplicação são alocadas em máquinas diferentes.
 Geralmente, ao mapear as camadas lógicas (layers) para as físicas (tiers), podemos criar um cluster ou um farm na mesma camada física para aumentar a performance e a confiabilidade da aplicação.
Arquitetura Orientada a Serviços(SOA) SOA já deixou de ser apenas uma palavra no meio de TI para se tornar um modelo consagrado adotado em muitas empresas. Uma arquitetura orientada a serviços nada mais é do que uma aplicação que expõe e consome as funcionalidades do sistema como serviços por meio de contratos e mensagens.
 Algumas das características de uma Arquitetura Orientada a Serviços são: a independência da Plataforma, comunicação baseada em serviços entre os componentes de software, integração de múltiplas funcionalidades em um único componente de interface do usuário e a exposição dos serviços por meio de repositórios ou catálogos.
Arquitetura Orientada a Objetos Ao aplicar esse estilo, o sistema é dividido em objetos individuais, reutilizáveis e autossuficientes. Cada objeto contém os dados e o comportamento pelos quais é responsável. Uma arquitetura orientada a objetos geralmente busca espelhar objetos do mundo real de modo a tornar simples a modelagem da aplicação.
Tabela 1. Estilos de Arquitetura.

Cluster: É um conjunto de computadores interligados que trabalham em conjunto como se fosse um único computador. Estes computadores são utilizados para suportar aplicações que têm necessidade de alta disponibilidade e alta capacidade de processamento.
Farm: Um Servidor Farm, também conhecido como Data Center, é um conjunto de servidores mantido (geralmente) por uma empresa para atender as necessidades computacionais da corporação, como o processamento de grandes volumes de informação, atender aos sistemas corporativos e prover servidores de contingência no caso de um problema no computador principal.
Repositório: Um Repositório é um local onde todos os clientes de um domínio específico publicam seus serviços, de maneira que todos os usuários passam a conhecer os serviços disponíveis e como acessá-los.
Para tanto, um repositório deve ter uma interface bem definida para publicação dos serviços, funções para localização, controle e maneira uniforme de acesso.

Uma vez que o estilo de arquitetura é definido, o passo seguinte é definir como as funcionalidades do sistema serão divididas, de forma a manter em conjunto os componentes relacionados (alta
coesão), e fazer com que estes possuam o mínimo de conhecimento sobre os outros componentes (baixo acoplamento). Para alcançar o baixo acoplamento e uma alta coesão é importante entender o conceito de Separação de Responsabilidades.


Separação de Responsabilidades (Separation of Concerns)

O termo Separação de Responsabilidades foi criado pelo pai do algoritmo de caminho mínimo, o cientista Edsger W. Dijkstra em 1974, e tem como objetivo dividir a aplicação em funcionalidade distintas com a menor similaridade possível entre elas. Para aplicar com sucesso este princípio, o mais importante é minimizar os pontos de interação para obter alta coesão e baixo acoplamento entre os componentes do sistema. Para tanto, é recomendado, primeiro dividir suas responsabilidades e organizá-las em elementos bem definidos, sem repetição de código ou de funcionalidade.

O tipo de separação de conceito mais difundido é o da separação horizontal, onde dividimos a aplicação em camadas lógicas de funcionalidades, como por exemplo, o protocolo TCP/IP (modelo OSI), que é separado pelas camadas de aplicação, transporte, rede, enlace e física. Neste modelo, cada camada tem sua própria responsabilidade e não precisa conhecer as camadas adjacentes. Voltando ao nosso mundo, em uma aplicação Java EE, as camadas mais conhecidas são a de Apresentação, Serviço, Domínio e Infraestrutura, como ilustra a Figura 1.


Figura 1. Separação Horizontal de Conceitos (Camadas lógicas de uma aplicação).

Podemos também aplicar o tipo de separação vertical, onde dividimos a aplicação em módulos ou funcionalidades que são relacionadas a um subsistema ou grupo de operações dentro de um sistema.
Veja um exemplo na Figura 2.

Figura 2. Separação Vertical de Conceitos.

Separar as funcionalidades de uma aplicação em módulos deixa claro as responsabilidades e dependências de cada funcionalidade, o que ajuda na execução dos testes e na manutenção do
software. Na Figura 2 fazemos um agrupamento por módulos; neste caso a separação foi feita pelos módulos de RH, Contábil e Marketing.

Além disso, podemos utilizar o conceito de separação vertical em conjunto com o conceito de separação horizontal. Veja um exemplo na Figura 3.

Figura 3. Aplicação da Separação de Conceitos Vertical e Horizontal.

Um papel importante da separação de conceitos é o da separação de comportamento, que envolve a divisão dos processos do sistema em unidades lógicas de código reutilizáveis e gerenciáveis. Ao organizar o comportamento, alcançamos os seguintes benefícios:
  • Eliminamos a duplicação de funcionalidades;
  • Minimizamos as dependências externas;
  • Maximizamos o potencial para reuso;
  • Restringimos o escopo do trabalho para os limites de cada módulo.
Como vimos, é importante entender a separação de conceitos pois ao modelarmos uma aplicação devemos ter conhecimento das responsabilidades de cada um de seus componentes. Além disso, devemos ter uma ideia de como será feita esta separação e como será feita a distribuição destes componentes na arquitetura disponível pelo cliente.

Para tanto, é preciso levar em consideração outros fatores, como infraestrutura e recursos disponíveis, conforme veremos a seguir, no próximo artigo da série.

Referências

Excelente artigo sobre separação de responsabilidades
http://www.aspiringcraftsman.com/2008/01/art-of-separation-of-concerns/

Biografia de Edsger Dijkstra.
http://pt.wikipedia.org/wiki/Edsger_Dijkstra

Guia de Arquitetura de Aplicações da Microsoft.
http://www.codeplex.com/AppArchGuide

Continuous Delivery, DevOps e Innovation Games na UFSCar

quinta-feira, 19 de janeiro de 2012

Ano passado, tive a oportunidade de palestrar em eventos importantes como o TDC 2011 em São Paulo, organizado pela Globalcode e no aniversário de 10 anos do evento É Dia de Java, realizado na Faculdade Federal de São Carlos (UFSCar), organizado pelo SOUJava.

Ainda no TDC, participei do painel "O que vem depois do Agile?" com nomes bem conhecidos pela comunidade Ágil. Publiquei um post recentemente sobre o Painel e uma palestra sobre DataGrid e NoSQL com JBoss Infinispan, que em breve publicarei aqui.


O evento É Dia de Java 2011 foi muito especial, primeiro porque foi a celebração de 10 anos do evento, e também porque pude reencontrar grandes amigos como André FonsecaVinícius Senger da Globalcode, Fabio Velloso e Bruno Souza do SOUJava e ter a satisfação de conhecer o grande Daniel Wildt.

O evento foi bem bacana, na sexta feira o dia foi reservado para a realizacao de Workshops praticos, no meu caso, fiz um workshop de Innovation Games, uma aborgagem lúdica inovadora criada por Luke Hohmann, para auxílio na criação de produtos, condução de retrospectivas e análise de problemas.

Realizei com a turma, jogos como Product Box, Remember the Future, Speed Boat e como plus (não é um Innovation Game), fizemos uma retrospectiva utilizando a técnica dos 06 Chapéus do Pensamento.

Abaixo uma das Product Box criada por um dos grupos.


No dia seguinte, foram várias palestras, sem falar que o evento estava lotado.


Minha palestra foi sobre Continuous Delivery e DevOps, o feedback foi muito bom, e várias pessoas solicitaram os slides. Sendo assim, aqui está.
Parabéns as pessoas que organizaram e participaram do evento na UFSCar e a Globalcode pelo excelente TDC. Esse ano se Deus quiser tem mais.

* Crédito ao pessoal da OCTO por alguns dos slides sobre Integração Contínua.

Diversão Garantida!!!

Continuous Delivery: Case de Sucesso com tecnologias .NET - Deploy em 7000 máquinas com apenas 3 cliques

segunda-feira, 16 de janeiro de 2012


Em um recente artigo, Maxence Modelin discute de maneira bem detalhada, como a OCTO Technology, criou um fluxo de implantação (Deployment Pipeline), onde com apenas 3 cliques, o deploy de um serviço Windows é feito em 7000 máquinas, de um fornecedor de serviços de hosting, localizado na França.

 A solução descrita, cujo foco envolve o deploy de um serviço Windows, desenvolvido em C#, que se comunica via FTPS com um servidor Java.

Uma caracteristica importante da solução, é o uso de uma plataforma de Integração Contínua baseado em ferramentas open-source, bem populares na comunidade Java, ao invés do uso do Team Foundation Server fornecido pela Microsoft.

Entre as tecnologias utilizadas para Integração Contínua, podemos destacar Jenkins como Servidor de Integração Contínua, Maven para gestão do projeto e Nexus para a gestão do repositório.

Para administração do farm de servidores, foi utilizado o software OCS Inventory. Um aplicativo web, responsável por centralizar todas as informações pelos Agentes OCS instalado em cada um servidores do farm. Que por sua vez, através das informações recebidas, efetua o deploy dos pacotes necessários nos servidores, sem a necessidade de uma ação do usuário.

Para monitoração do ambiente, foi utilizado Zabbix.

A cadeia de entrega contínua, se resume a apenas 3 cliques, onde o primeiro deles, começa com a operação de commit no SVN, que inicia o processo de integração contínua orquestrado pelo Jenkins. Que após efetuar o checkout do projeto, executa o script do Maven, que efetua o build, executa os testes, e por fim, armazena os artefatos gerados no Nexus.

O segundo clique, é para criação do pacote OCS, onde um profissional de operações (ops), executa um script shell, que extrai o artifato do Nexus e disponibiliza o pacote pronto para deploy no banco de dados do OCS.

Para o terceiro clique, no contexto da empresa, este último passo é considerado um passo funcional, e não existe razão de ser automático. Quem decide quais máquinas irão receber os pacotes, são os profissionais de operações, através do OCS. Os desenvolvedores tem o mesmo acesso, porém, para fazer o deploy em ambiente de testes.

Para assegurar que tudo ocorreu corretamente, operações utiliza duas ferramentas para feedback, que são o próprio OCS e Zabbix, e um usuário fake. Este usuário fake, é responsável por efetuar o download dos pacotes nas máquinas destino, e verificar se tudo ocorreu conforme o esperado.

A figura a seguir, descreve os softwares e ações realizadas durante o fluxo de implantação.



Um dos fatores imprescendíveis para o sucesso da Implantação Contínua, foi a abordagem DevOps dada ao projeto. Esta abordagem abriu a oportunidade para um compartilhamento das necessidades e visão entre os times de Desenvolvimento e Operações.

Pois com a responsabilidade do deployment a cargo do time de desenvolvimento, ao invés do time de operações, talvez eles nunca teriam a real noção do trabalho realizado.

E você, tem alguma estória de sucesso sobre implementações de Continuous Delivery e DevOps? Comente, discuta, colabore!

Nota: O artigo que o texto destaca é um pouco antigo, mas como esse post era para ser uma notícia na InfoQ Brasil no ano passado, mas como não foi aprovado então resolvi publicar aqui. Espero que curtam! Pois o case foi bem interessante, por se tratar de um case de Continuous Delivery para um aplicativo .NET, utilizando ferramentas open source Java.


Jez Humble on Continuous Delivery and DevOps

sexta-feira, 13 de janeiro de 2012


In the last year, during the period i have been in France, attending Université du SI, one of the best conferences i've participate in whole life (sponsored by OCTO Technology), i had the privilege of being invited to participate in a very interesting course with Jez Humble,  about Continuous Delivery for DevOps.
After the course, i could make an interview for InfoQ Brazil, but for obvious reasons we translated it to Brazilian Portuguese. And now, here goes the original version. Enjoy!

You wrote a best seller, called Continuous Delivery, What is it all about?

It's about all the stuff that is normally considered somewhat peripheral to software development - configuration, build and deployment management, automated testing, continuous integration, infrastructure and database management. However the discovery that many of us made while working on large agile projects was that this stuff is essential if you want to be able to reliably, repeatably release high quality software.

Actually many of the ideas in the book aren't new. It's really a call to arms to focus on the engineering practices that were always at the heart of agile methodologies, but that somehow got sidelined in many places over the last ten years. Of course several tools like Puppet, Chef, Git and DbDeploy have emerged that didn't exist ten years ago that make much of this stuff much more tractable.

It turns out that the engineering practices - particularly automation of build, test, deployment, and database and infrastructure management - and collaboration between development, testing and operations - are really essential to be able to get high quality software delivered fast. And that, in turn, is central to the ability of organizations to innovate and get new features out of the door quickly and reliably.

What practices do you think are more important?

For developers, you need to start with continuous integration. That doesn't mean installing a CI server and pointing it at your feature branches - it means making sure everyone merges regularly into mainline (and yes, that applies to Git too). In order for CI to be useful, you need automated tests, in particular at the unit and acceptance level. Having a comprehensive, maintainable set of unit tests is almost impossible without doing TDD. Creating maintainable acceptance tests requires close collaboration between developers and testers. Finally, you need to validate every build to ensure it's production ready, which means having the ability to spin up production-like testing environments on demand and run realistic loads against your system. This requires automated provisioning of environments and infrastructure, and automated deployment of your system, including any database changes. All of this needs to be implemented within the context of the deployment pipeline.

These kinds of changes need to be made incrementally, by finding out where the constraints are in your delivery process and removing them one by one. That in turn requires close collaboration between developers, testers and the operations department. More on that later.

We have seen, that some people make some confusion about the term Continuous Delivery, can you explain to us, what's the difference between Continuous Delivery and Continuous Deployment?

Continuous delivery means you can release on demand. I should be able to release the latest good build at the press of a button without having to worry that it's going to break. But when you release is a business decision. Continuous deployment means you actually go ahead and release every good build. Obviously that only really applies in the context of websites or software-as-a-service. But if you can't actually do continuous deployment and release every good build for some reason - say you're working on a user-installed product - you should at the very least be putting every good build into a production-like environment and running realistic acceptance and performance tests against it so that there are no surprises when you come to release it. You can do that on embedded systems, products, pretty much anything that involves software.

Organizations that could in principle do continuous deployment really should aim to. One of the key benefits is organizational. Continuous deployment makes developers care much more about the quality and reliability of what they're doing because if they can push a button to make their changes go live, it connects them with what's going on in production. And it makes the business focus much less on stuffing features into a release when they know they can create some small feature, have it in production in a couple of days' time, and get real feedback on whether it's valuable and whether more effort should be put into it. It is a complete paradigm shift in the way organizations work and they become much more responsive to their customers. Eric Ries writes more about this in his forthcoming book, The Lean Startup

Can you explain to us, the term DevOps, and what that means?

DevOps is kind of an anti-movement, by which I mean it has resisted attempts to pin it down. But fundamentally it's about putting a strong focus on collaboration between everybody involved in software delivery - in particular, developers, testers and operations - and sharing knowledge and techniques between them. Infrastructure-as-code is one example of knowledge sharing - the application of agile techniques such as refactoring and test-driven development to evolving your infrastructure. DevOps is essential to achieve continuous delivery.

Part of the reason people in the movement have resisted (for example) creating a manifesto is to prevent vendors (in particular tool vendors) from appropriating it and trying to own it. Often people are guilty of reaching for tools (even within the movement - myself included) when actually it's the attitude and mindset that makes you successful. That's not to say the tools aren't important - they are. Tools that can't be managed in an automated fashion through an API are especially unpopular within the community.

How do you implement DevOps?

One really good way to start is to get representatives from every part of the organization involved in delivery - development, testing, infrastructure, operations, product management - to get together regularly and have retrospectives to reflect on how to incrementally improve things. In many organizations, you never see people from every department in a meeting together. It just doesn't happen.

Another way to get going is for everyone involved in delivering software celebrate successful releases together. Really implementing DevOps is about change that works up from the people on the ground - it's hard to mandate it. That's one of the reasons senior management has a hard time with it. But it's also the secret sauce - incremental, bottom-up change is usually the most effective and long-lasting.

What skills related to Infrastructure a modern developer should have? And why it is important? Does it make sense, for companies that are not in the cloud?

I think the key element is that infrastructure provisioning and management has to be automated. It should be possible to plug a new server (or workstation) in - power and network - and bring it into the correct state, configure it, and deploy to it in a fully automated fashion. You can do that whether or not you're in the cloud. In fact ThoughtWorks recently did some consulting to automate hardware provisioning and management for one of the cloud vendors. Under the hood, "the cloud" of course runs on real hardware and the same principles apply.


For great companies, that has already an Operation Department, what a developer can do to decrease this gap between devs and ops?

First of all, get to know your operations department. Make friends with them. Invite them along to your retrospectives and showcases. Learn the tools they use. Help them build new ones. Read books like Release It! that talk about how to create production-ready software. Check out the screens they have up that show off production metrics. Get the same screens put up in development rooms (LCD panels are cheap these days). Ask to help out when releases happen. Get involved.


Can you talk about your job at ThoughtWorks?

I'm working on a number of things. On the one hand I am doing a lot of travelling at the moment, going to conferences and talking to our customers. I'm also doing some research and writing, including working on a series of interviews to create some videos about continuous delivery. Finally I'm doing some consulting work to make sure I keep my feet on the ground and stay in touch with the latest developments in the space, and of course to pay my way.

------------------------------------------------

Jez Humble is a Principal at ThoughtWorks Studios, and author of Continuous Delivery, published in Martin Fowler’s Signature Series (Addison Wesley, 2010). He has worked with a variety of platforms and technologies, consulting for non-profits, telecoms, financial services, and online retail companies. His focus is on helping organisations deliver valuable, high-quality software frequently and reliably through implementing effective engineering practices.


[Painel TDC2011] O que vem depois do Agile?

segunda-feira, 9 de janeiro de 2012

No ano passado, tive o privilégio de participar do TDC 2011, um evento super massa concebido pela Globalcode,  que contou com o o apoio de grandes nomese empresas da Indústria de Software.
Participei de um painel bem bacana, mediado pelos meus amigos Felipe Rodrigues da Crafters, e Victor Hugo Germano.
O tema da discussão foi O que vem depois do Agile?
Segue a descrição oficial.

A adoção da agilidade tem crescido muito no mercado brasileiro e cada vez mais grandes empresas tem aderido ao seu uso. Isso aumenta sua visibilidade, mas também vai exigindo adaptações nem sempre fáceis ou bem recebidas pela comunidade.
A grande pergunta que surge é: Qual é o próximo passo? O que vem depois do Agile?
Abaixo segue o vídeo do painel





TDC2011 SP - Painel (O que vem depois do Agile) - Domingo, 10 de Julho from Globalcode on Vimeo.