Minha palestra na QConSP 2015

Palestra no QConSP
429

No dia 27 de março tive a honra e o prazer de palestrar pela primeira vez na QCon. Minha palestra foi sobre DevOps e Continuous Delivery, com o título “nada” sugestivo de “Quebrando preconceitos: Continuous Delivery na plataforma Microsoft”:

Práticas como Continuous Delivery e DevOps ganham espaço cada vez maior na atual busca pela redução de custos e entregas mais eficientes. Mas é comum ouvir relatos de vivências e projetos pequenos, ou empresas que já nasceram com essas práticas presentes em seu dia a dia.

Nessa palestra você irá entrar em contato com aplicações reais de Continuous Delivery em ambientes corporativos de diversos tamanhos e realidades. Verá a maneira que ferramentas como Microsoft Foundation Server e System Center foram utilizadas para reduzir erros de implantação e melhorar o ciclo de coleta de feedback dos usuários – ajudando as equipes a buscarem não só a entrega como a melhoria contínua.

Continue lendo “Minha palestra na QConSP 2015”

O que o System Center tem a ver com TFS e ALM?

image Quando se fala de ALM na Plataforma Microsoft, geralmente o primeiro que vem à cabeça é “TFS”. Mas ultimamente há um outro nome que vem surgindo com uma frequência cada vez maior nas rodas de discussão sobre ALM: System Center.

Mas afinal, o que é que o tal System Center tem a ver com ALM?

Continue lendo “O que o System Center tem a ver com TFS e ALM?”

Entre teste automatizado e implantação automatizada, fico com a implantação

"I pity da fool" - Mr. T“Como assim”, você pode estar pensando, “o Igor não testa o que ele desenvolve?!”

Calma, pequeno padawan. Vou explicar melhor o que eu quis dizer…

Primeiro, a pergunta obrigatória: você usa controle de versão nos seus projetos? Hoje em dia é cada vez mais difícil encontrar alguém que responda “não” a essa pergunta. Aliás, essa é normalmente uma das primeiras coisas que se faz durante o setup de um novo projeto: preparar o controle de versão e já fazer o check-in / commit inicial do seu projeto – antes mesmo de se escrever a primeira linha de código.

Até aqui, tudo bem. Mas e agora? O que fazer depois de configurar o controle de versão?

A resposta depende, naturalmente, de para quem você está perguntando:

  1. Se você perguntar para um adepto do Extreme Go-Horse (ou uma de suas variações), a resposta provavelmente seria “agora é só sair codando!”
  2. Por outro lado, um adepto de ATDD/BDD/TDD diria algo como “hora do Red-Green-Refactor!”

Agora, se perguntar para mim, eu direi: “hora de configurar os builds de CI e CD.”

CI? CD?!

Sim, Continuous Integration (Integração Contínua) e Continuous Deployment (Implantação Contínua). Antes mesmo dos meus testes, configuro meus builds e meu processo de implantação. Só depois é que começo a fazer algum código.

Parece exagero falar de build e deployment antes do software, não? Só que, por conta disso, muitos times deixam para se preocupar com o deployment apenas ao fim do projeto. E, invariavelmente, sofrem um bocado até conseguirem fazer funcionar. E esses times, com um processo essencialmente manual, estão ficando numa situação cada vez mais complicada. Não raro, encontro clientes que às vezes levam horas e mais horas para conseguir publicar alguma coisa em produção! Não seria melhor pensarmos nisso mais cedo para evitar problemas?

Se você ainda não se convenceu, dê uma lida no trecho abaixo do Scrum Guide:

The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of “Done” product at the end of each Sprint.

O trecho em negrito é a chave de onde quero chegar. Ao final de cada sprint, o time de desenvolvimento deve entregar um incremento do produto (do software que está sendo desenvolvido) que seja potencialmente liberável. Em outras palavras, nosso software deve estar num estado em que ele possa, eventualmente, ser colocado em produção. Liberar ou não esse incremento de software para os usuários não deve ser pautado pelo estado do software (“não funciona em produção!”) mas apenas por uma decisão de negócios do Product Owner, que pode ver valor naquele incremento que acabou de ser apresentado. Se o time não exercita o processo de implantação ao longo da sprint, como pode ter certeza de que sua entrega é potentially releasable? E se seu processo de implantação não é automatizado, como pode garantir que ele será reproduzível e consistente?

Mas para o produto ser potencialmente liberável ele também não precisa estar testado? Claro que sim. Mas de uma maneira ou de outra, esse é um problema que a maioria dos times já resolve hoje.

Não quero dizer com isso que testes automatizados não são importantes. Pelo contrário! Lembre-se, apenas, que seus testes automatizados se beneficiam de um processo de build e implantação automatizados. Se começarmos por aí, à medida que os testes forem sendo criados nossos ambientes já estarão prontos para sua execução.

Desde que adotei essa prática – build e implantação configurados logo no início do projeto – tenho levado isso tão a sério que até mesmo coisas que aparentemente não seriam “automatizáveis” entram no balaio. Afinal, automatizar implantação de ASP.NET MVC com WebDeploy não tem absolutamente dificuldade nenhuma. Agora, concorda comigo que coisas não-triviais como pacotes do SQL Server Integration Services, justamente por serem não-triviais, são as que mais se beneficiam de uma implantação automatizada?

E você, o que acha? Dê sua opinião nos comentários!

Um abraço,
Igor