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 problemasProblemas

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çãoO 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 ProcessoAlguns “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.