I Objetivos do Release Management:

Ter uma visão abrangente e holistica das mudanças em um serviço de TI afim de garantir
que todos os aspectos de um release, técnicos e não técnicos sejam considerados
conjuntamente.

Por que Release Management?

• Gerenciar grandes e/ou críticas roll-out (extensões/ modificações/ produções) de
hardware
• Gerenciar as principais roll-out (extensões/modificações/produções) de software
• Tratar em formato de pacote ou de lote conjuntos de mudanças relacionadas
• Controlar a liberação de Cis autorizadas no ambiente

II Escopo do Release Management:

• Planejamento e políticas de release
• Design, construção e configuração do Release.
• Aprovação do Release
• Planejamento de modificação/extensão
• Testes extensivos para critérios de aprovação predefinidos
• Anunciar a liberação do Release para implementação
• Comunicação, preparação e treinamento
• Auditar o software e o hardware antes e após a implementação de mudanças
• Instalação de novo hardware ou upgrade
• Armazenamento de software controlado tanto nos sistemas centralisados como
nos sistemas distribuídos
• Liberação, distribuição e instalação de software

III Conceitos Básicos

• Release Policy - Um documento de política para Release que deve ser produzido
para esclarecer os papéis e responsabilidades para o Release Management. Deve
haver um documento por organização ou um conjunto de diretrizes com detalhes
específicos para cada serviço suportado
• Definitive Software Library (DSL) – onde todas as versões autorizadas de
softwares são armazenadas e protegidas.
• Definitive Hardware Store (DHS) –Uma area reservada para a armazenagem
segura do hardware de reserva
• Release: uma coleção de mudanças autorizadas em um serviço de TI
• Release Unit: o pedaço da infraestrutura de TI que normalmente é
liberada/alterada de forma conjunta
• Roll-out: entrega, instalação e autorização de um conjunto integrado de novos CI
ou mudanças em partes lógicas ou físicas de uma organização
• CMDB
• Tipos of Release
o Delta Inclui somente aqueles CI que de fato mudaram desde o ultimo
release
o Full – Todos os components do Release são construídos, testados,
distribuídos e implementados juntos ( tenham mudado ou não )
 o Package – Releases individuais dos tipos Delta e/ou Full são agrupados
para formar um pacote
• Build Management
o Componentes de Software e Hardware para o release devem ser montados
de uma forma controlada e reprodutível.
o Build Management é responsabilidade do Release management a partir do
ambiente de testes controlado.
o Planos de Back out devem ser delineados e testados como parte do
release.
• Testing – Antes do roll-out de um Release, ele deve passar por testes rigorosos e
pela aceitação do usuário incluindo functional testing, operational testing,
performance testing and integration testing
• Back-Out plans – Um plano de back-out deve ser produzido e documentado com
descrição das ações a serem tomadas para restauração dos services em caso de
falha parcial ou total. A produção de planos de back-out para cada mudança é
responsabilidade do Change Management, mas o Release Management tem um
papel em assegurar que o plano de back-out para cada mudança dentro de um
Release trabalhe em conjunto para criar um plano de back-out do Release
• Obs: Sem Change and Configuration Management o Release Mangement não é
controlável

IV Benefícios e possíveis problemas

Problemas
• Resistência do STAFF
• “Burla” dos procedimentos
• Aceitação e proprietários mal definidos
• Falhas no entendimento da construção de releases
• Relutância para retorno de um release falho.
Benefícios
• Aperfeiçoamento da qualidade de serviços
• Habilidades de lidar com grandes volumes de mudanças
• Garantias que o HW e o SW em produção são de qualidade
• Melhores expectativas para o staff de negócios e de serviços

V Planejamento e Implementação
O Planejamento do Release Management deve incluir:
• Políticas e procedimentos de Release
• Papéis e responsabilidades de todo o Staff do Release
• Responsabilidades do staff central do Release Management
• Ferramentas para suporte de Release de hardware e software ( e.g. software
distribution )
• Equipe/staff do Release Management
• Treinamento
• Diretrizes para programação de eventos em uma organização e a produção de
uma agenda geral de release para eventos previsíveis.
• Documentos modelos para auxiliar no planejamento de um release específico
• O gerenciamento e uso efetivo de ambientes de construção, teste, produção para
um Release bem sucedido..
 • Garantias que os mecanismos de release corretos estão disponíveis.
Os procedimentos devem ser documentados para:
• designing, building e rolling out um Release
• Release e distribuição de software, incluindo o controle e manutenção da DSL
• Compra, instalação, deslocamento e controle de software e hardware que sejam
releavantes para o Release Management
• O gerenciamento e uso de qualquer ferramenta de suporte e instalações
• Rastreio, revisão, gerenciamento de risco, e priorização de problemas para o
Release Management.

VI Atividades
• Obtenção de consenso sobre o conteúdo de um Release
• Acordos sobre questões de tempo e localização geográfica, unidades de negócio e
clientes
• produção de uma agenda para release de alto nível
• condução de vistorias do site para avaliar o hardware e software existente e em
uso
• planejamento dos níveis de recursos.
• Acordos sobre papéis e responsabilidades
• Obtenção de cotações detalhadas e negociações com os fornecedores para novos
hardware, software ou serviços da instalação
• Produção de planos de back-out.
• Desenvolvimento de planos de qualidade para os Release
• Planejamento de aceitação e grupos de suporte ao cliente

Entrada para o planejamento de Release inclui:

• Ciclo de vida do projeto
• Outros serviços relacionados
• RFCs autorizadas
• Política de Release
• Uma visão geral das necessidades do negócio
• Restrições e dependências
• CAB
• Modelos
A saída do planejamento do Release inclui o plano para um particular Release, e planos
de alto nível para teste e critérios de aceitação para o Release.

Entradas para o Design, construção e configuração incluem:

• Definição do Release
• Plano do Release
A saída para o Design, build e configure inclui:
• Instruções detalhadas para montagem e construção do Release, incluindo a exata
sequencia de operações.
• Ordens de compra, licenças, garantias para os softwares e hardwares de terceiros.
• Scripts de instalação automática e planos de teste associados.
• Copias master da mídia de instalação e das instruções para serem armazenadas
na DSL
 • Procedimentos de back-out.
Entradas para o Release acceptance compreendem
• Um ambiente de teste controlado configurado para replicar as versões
correntemente em produção das aplicações com a documentação da configuração
de testes
• Definições e planos de Release
• Planos de teste e critérios de aceitação do Release.
• Copias da mídia e das instruções de instalação
• Planos de teste para os scripts de instalação
• Procedimentos documentados de back-out
O resultado final da atividade de aceite deve ser uma sinalização efetiva da completude e
correição de todo Release. Pode incluir:
• Procedimentos de instalação testados.
• Componentes de Release testados
• Procedimentos de back-out testados
• Problemas conhecidos que serão jogados na produção
• Resultados dos testes
• Documentação de suporte
• Instruções de operação e administração
• Planos de contingência e back-out.
• Uma agenda de treinamento para o Service Management, staff de suporte e
clientes
• Documentos de teste de aceitação para todas as partes relevantes
• Autorização para implementação do Release (feita pelo Change Management).
Entradas para o Distribuição e Instalação são:
• Planos de rollout detalhados
• Procedimentos de instalação testados
• Componentes do Release testados
• Procedimentos de back-out testados
A saída da Distribuição e Instalação deve compreender:
• Um serviço de TI atualizado, com a documentação de usuário e suporte
documentada.
• Registros do CMDB atualizados para refletir os novos componentes
• CI descontinuados/ desinstalados
• Qualquer erro conhecido no sistema em produção introduzido como parte do novo
Release

VI Controle do Processo
Alguns “key performance indicators” (KPIs) devem ser monitorados para avaliar a
efetividade do processo Release Management. Deve-se considerar escolher métricas que
mostrem indicações, dentre outras:
• Releases implementados construídos e implementados conforme agendados, e
dentro dos recursos orçamentários
• Baixa incidência de Releases que tiveram de ser desfeitos por erros
• Baixa incidência de falhas de construção
• Gerenciamento seguro e preciso da DSL
 • Inexistência de software na DSL que não tenha passado pelo controle de
qualidade e nenhuma evidência de retrabalho em nenhum software que tenha sido
retirado da DSL ???
• Crescimento da DSL coerente com a demanda por espaço além de manutenção
precisa e adequada.
• Conformidade com todas as restrições legais aos softwares adquiridos.
• Distribuição correta dos Releases para todos os sites remotos
• Implementação dos Releases em todos os sites conforme programação.
• Inexistência de retorno não autorizado de versão em qualquer site.
• Inexistência de uso não autorizado de software em qualquer site.
• Inexistência de pagamento de licença ou manutenção de softwares que não sejam
de fato utilizados.
• Inexistência de desperdício de por duplicação de esforços de construção.
• Registros adequados de todas as atividades de construção, distribuição e
implementação no CMDB
• Ações de seguimento realizadas em todas as atividades de Release e todas ações
corretivas e de melhoramento tomadas.
• A conformidade de toda a composição do Release com a efetivamente planejada.
• O número de Releases principais e secundários por período.
• O número de problemas no ambiente de produção que podem ser atribuídos aos
novos Releases classificados por causa.
• O número de objetos novos, mudados e excluídos por novos Releases.
• O número de Releases completados no tempo devido/acordado.

VII Recomendações para RM bem sucedida

O melhor conselho é usar os princípios do Release Management na implementação do

próprio Release Management. Isto é, tornar todos os procedimentos do Release
Managemet controlados e mantidos pelo Change Management e pelo Configuration
Management bem como realizar modificações sempre dentro de “Releases”
planejados.com o acompanhamento de treinamento e documentação de suporte.
• Garantir que o código fonte para manutenção do software entregue no ambiente
de produção tenha um estrito controle de versões.
• Usar implantações piloto
• Usar detecção automática de necessidades de atualização.
• Automação da distribuição e implementação de softwares em workstations.
• Possuir ambientes de teste apropriados e representativos que efetivamente
dupliquem tão precisamente quanto possível o ambiente de produção.