“Release Management can be a complex topic, so any attempt to cover it in a single article would be a mistake.”por Mike Drupeau e Sudesh Oudi (“Release Management: Where to Start”, artigo). Portanto, começando por esta frase quero já passar a ideia de que estamos a falar de um tema bastante complexo que pode ser abordado de várias formas. Considerando que este é o primeiro artigo, vou começar por explicar os conceitos mais gerais do Release Management e depois passar para alguns exemplos práticos que têm por vezes sido a minha ‘dor’ no dia-a-dia.

Antes de mais, porquê Release Management? Bem, penso que é um tema cuja relevância dada tem sido parca. Podem existir várias razões para tal (e.g., calendário de projecto reduzido, equipa com vertente meramente técnica, equipa de projecto com pouca experiência, …), no entanto quando os problemas começam a surgir as equipas começam a focar-se no tema, sendo que o tempo gasto a posteriori na implementação de um processo de Release Management pode ser bastante elevado.

Release Management é todo o processo de planeamento, build, testes e deploy. O ciclo de vida associado encontra-se representado abaixo.

Para que o ciclo de vida acima referenciado seja cumprido/seguido, existem algumas regras que podem ser seguidas, pelo que passo a enumerá-las:

• Programadores;
  • Não trabalhar em ficheiros fora do sistema de gestão de versões (caso contrário deixa de existir qualquer controlo sobre o trabalho que se está a desenvolver);
  • Manter sempre o código sincronizado (não pretendemos estar a trabalhar sobre versões de código erradas) – regra simples? … Acreditem que nem sempre se encontra implícita nos projectos, infelizmente;
  • Check-insregulares – em projectos com configuração de ‘exclusive check-out’ impede que outros programadores fiquem à espera;
• Gestor de Releases;
  • Definir regras de desenvolvimento e branching desde o início do projecto;
  • Garantir a existência de uma mainline – sempre que um branch é deployed deverá ser incluído na mainline para que os novos desenvolvimentos sejam efectuados sobre a nova mainline;
  • Garantir a correcta execução do processo de build;
  • Orientações de Branching;
    • Apenas criar um branch quando é necessário;
      • Mais branches àMais builds, mais propagações de alterações, mais merges;
    • Criar um branch tarde mas não muito tarde (aka, branch late but not too late), i.e., incluir no branch o máximo das alterações já presentes na mainline, mas não deverá por isso ficar pendente outro desenvolvimento;
  • Orientações de Build;
    • Ferramenta de build igual – garantir que os builds são iguais;
    • Efectuar build regularmente – e.g., uma vez por dia;
    • Manter os logs e os outputs de build – e.g., para identificação de eventuais falhas.

Pela minha experiência profissional, as regras para Release Management são diferentes consoante a complexidade dos projectos, sendo que quanto maior o projecto se torna mais regras terão de existir (aumenta o esforço gasto em Release Management, mas diminui-se o risco de cada passagem). Isto porque num projecto que se prolonga no tempo, tipicamente o número de novas features vai aumentando, sendo que nem sempre o seu desenvolvimento é seguido de aprovação e passagem ao ambiente de Produção; podem sempre surgir outras novas features que têm uma prioridade mais alta e cuja aprovação é prioritária.

Abaixo segue uma representação de um projecto cujo ciclo de deploy é sequencial (i.e., N pacotes Qualificação à1 pacote PRD).

Quando assim é não existem grandes problemas de deployment. Em termos profissionais o que se verifica é algo bastante diferente que pode, por isso, levar à existência de um processo de Release Management mais controlado e, por vezes, mais dispendioso. Segue abaixo a representação de um problema típico de gestão de versões.

Acima encontra-se representado um problema típico dos projectos de IT, que é a diferença de versões nos diferentes ambientes por alteração de prioridades por parte dos Sponsors dos projectos. Neste caso, para o ambiente de Produção não deverá passar a feature NF2, pelo que o pacote a preparar para Produção não a deverá incluir, podendo por isso surgir alguns problemas (caso o processo de Release Management não esteja bem definido) – e.g., SQL patches com código comentado (colunas que não deverão ser incluídas na passagem a PRD), Frontend patches com código comentado (textBoxes que apesar de existirem em QUA ainda não foi dada a aprovação para passar a PRD).

O exemplo acima indicado vem sublinhar a extrema importância de uma política de Release Management bem definida. Esta importância denota-se mais em projectos onde existem várias releases ao longo do tempo de vida do mesmo (e.g., produto).

Espero com este artigo chamar a vossa atenção para a importância do Release Management e fazê-los pensar em algumas formas de o implementar nos vossos projectos caso tenham alguns dos problemas espelhados no artigo, o qual foi apenas um pequena amostra do mundo que é o Release Management.

Até um próximo artigo …